hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-860) DefaultRequestDirector converts redirects of PUT/POST to GET for status codes 301, 302, 307
Date Sat, 11 Jul 2009 14:48:14 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729991#action_12729991

Oleg Kalnichevski commented on HTTPCLIENT-860:


I am afraid we will have to agree to disagree here. Anything short of a UI dialog popping
up would not constitute a 'user confirmation' in my opinion.

> 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

But then one can argue that allowing redirects of PUT/POST without user confirmation would
be equally wrong. 

There are enough extension points in HttpClient that can be (ab)used to implement non-standard
behaviours in direct violation of the spec, so RedirectHandler is in no way different.

I'll commit the patch as is. You are welcome to open a feature request for a more flexible
redirect handling API, which we can address in the course of 4.1 development.


> DefaultRequestDirector converts redirects of PUT/POST to GET for status codes 301, 302,
> -------------------------------------------------------------------------------------------
>                 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_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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message