[
https://issues.apache.org/jira/browse/HTTPCLIENT-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729727#action_12729727
]
Ben Perkins commented on HTTPCLIENT-860:
----------------------------------------
Oleg,
I agree that the meaning of having something "confirmed by the user" is
somewhat ambiguous in the context of a programmatic client. I believe in this
context, the programmer is as close to a "user" as you are going to get. With
your patch to DefaultRedirectHandler you're honoring the spec by not
redirecting PUT/POST without some explicit signal that it's desired. To me
either an HttpParam requesting it or the replacement of the RedirectHandler
should qualify as confirmation, though it seems you don't agree.
But even if you do not agree, the existing capacity of replacing a
RedirectHandler can cause redirects to be done for PUT/POST requests. And if
they are enabled in that manner, the behavior for DefaultRequestDirector
(mapping the PUT/POST to GET) is explicitly against the spec for all status
codes except for 303. From my RFC excerpt above:
Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request.
So, while your patch makes the default behavior of the client more RFC
compliant, it leaves it non-compliant if the user specifies a custom-redirect
handler to enable extended redirect functionality. What is the advantage of
not preserving the PUT/POST method in those situations when it takes you
farther from the spec?
I guess all I'm really asking for on top of what you've already done is to
change the behavior of your new HttpRedirect class to preserved the original
request's method for all cases except for 303's.
I appreciate your patience with all these questions and hope we can arrive at
something mutually satisfactory.
Thanks again.
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
