[
https://issues.apache.org/jira/browse/HTTPCLIENT-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729689#action_12729689
]
Ben Perkins commented on HTTPCLIENT-860:
----------------------------------------
Oleg,
I'd hate to get you lynched by a mob of angry users. :) First off, I think
your patch does bring the client's behavior closer in line with a literal
reading of the spec. And I agree with you that it's easy to supply a custom
RedirectHandler so I'm not terribly concerned with the "strict" behavior of the
patched DefaultRedirectHandler.
But if I'm reading your patch correctly, it does still present me with one
major problem. Even if I replace the RedirectHandler with one that allows
redirects of PUT/POST (effectively giving "confirmation" as required by the
spec), the DefaultRequestDirector will still ignore the specification and
convert the PUT/POST method to a GET when it performs the redirect.
Can we please get DefaultRequestDirector changed to honor the original request
method (presuming the RedirectHandler allows the redirect at all), except in
the case of status code 303 which explicitly mandates conversion to a GET?
Thanks!
- Ben
> DefaultRequestDirector converts redirects of PUT/POST to GET for status codes
> 301, 302, 307
> -------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-860
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-860
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0 Beta 2
> Reporter: Ben Perkins
> Fix For: 4.0 Final
>
> Attachments: HTTPCLIENT-860.patch
>
>
> The DefaultRequestDirector treats redirect requests created by all redirect
> status codes (HttpStatus.SC_MOVED_TEMPORARILY: ,
> HttpStatus.SC_MOVED_PERMANENTLY, HttpStatus.SC_SEE_OTHER,
> HttpStatus.SC_TEMPORARY_REDIRECT) the same, converting PUT/POST methods to
> GET. The HttpClient Tutorial even documents this as being in accordance with
> the specification, but I don't believe that's true.
> Per the RFC (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html),
> conversion of PUT/POST to GET is appropriate only for 303 (See Other). The
> others do not suggest this behavior. In fact, the following notes attached
> to them call it out as incorrect.
> 301 (Moved Permanently) has this note:
> Note: When automatically redirecting a POST request after
> receiving a 301 status code, some existing HTTP/1.0 user agents
> will erroneously change it into a GET request.
> And 302 (Found) say this:
> Note: RFC 1945 and RFC 2068 specify that the client is not allowed
> to change the method on the redirected request. However, most
> existing user agent implementations treat 302 as if it were a 303
> response, performing a GET on the Location field-value regardless
> of the original request method. The status codes 303 and 307 have
> been added for servers that wish to make unambiguously clear which
> kind of reaction is expected of the client.
> The currently implemented behavior is causing problems with interacting with
> Central Authentication Service protected resources, among other things.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
