Thanks to visit codestin.com
Credit goes to github.com

Skip to content

BrowserKit: 301 redirect forwards POST requests #20924

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jlamur opened this issue Dec 14, 2016 · 4 comments
Closed

BrowserKit: 301 redirect forwards POST requests #20924

jlamur opened this issue Dec 14, 2016 · 4 comments

Comments

@jlamur
Copy link
Contributor

jlamur commented Dec 14, 2016

Q A
RFC? yes
Symfony version master

As far as I understand, RFC 7231 §6.4.2 states that 301 HTTP Code should forward POST requests to the Location URI.

But, it also states that:

For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.

This is the behavior implemented in almost all user agents (Chrome, Firefox, IE, curl, as far as I tested).

However, the BrowserKit is not implemented this way. It forwards the request to the Location URI with the same method as the source one.

The source code related is here: src/Symfony/Component/BrowserKit/Client.php#L477.

As it can break some websites when crawling them, do you think it has to be changed ? Is there a way to force the browser kit to not forward the POST request ?

@xabbuh
Copy link
Member

xabbuh commented Dec 15, 2016

To me this looks like it was overlooked when the behaviour for 302 and 303 status codes was implemented. On the other hand, changing this behaviour now could be seen as a BC break. Maybe it should be configurable whether or not the request method will be switched to GET (we could then also deprecate not turning that option on).

@jlamur
Copy link
Contributor Author

jlamur commented Dec 18, 2016

@xabbuh I never contributed to the Symfony projet, I don't know how it works. Can I submit a PR?

If yes, what behavior should be implemented? I guess the one without the BC break, so a configurable option + depreciation of not turning that option on, in one PR ?
Should it target all branches or not ?

@xabbuh
Copy link
Member

xabbuh commented Jan 16, 2017

@jlamur Sorry for not responding earlier. New features and deprecations should always target the master branch.

@jakzal
Copy link
Contributor

jakzal commented Feb 8, 2017

re #8895

fabpot added a commit that referenced this issue Mar 14, 2017
This PR was merged into the 3.3-dev branch.

Discussion
----------

301 status code must drop request method to GET.

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | yes
| BC breaks?    | yes
| Tests pass?   | yes
| Fixed tickets | #20924
| License       | MIT

[RFC 7231 §6.4.2](https://tools.ietf.org/html/rfc7231#section-6.4.2) states that 301 HTTP Code should forward POST requests to the Location URI.

But, it also states that:

> For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.

This is the behavior implemented in almost all user agents.
However the `BrowserKit` did forward the method to the subsequent request.

This PR make the `BrowserKit` change the request method from POST to GET when the response status code is 301.

Commits
-------

abda966 301 status code must drop request method to GET.
@fabpot fabpot closed this as completed Mar 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants