hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Moore (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HTTPCLIENT-1248) LaxRedirectStrategy converts POST to GET and throws away body
Date Wed, 10 Oct 2012 10:07:03 GMT

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

Jon Moore edited comment on HTTPCLIENT-1248 at 10/10/12 10:06 AM:
------------------------------------------------------------------

@Justus: This is actually compliant HTTP/1.1 behavor, at least for a 302, and matches what
most browsers do. See:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3

      "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."

RFC 2616 obsoletes RFC 2068. The HTTP-WG has been working on a rewrite of the HTTP/1.1 spec
("httpbis") that is meant to clarify (not change) RFC2616. The section on redirects there
reads:

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-20#page-28

      "Note: In HTTP/1.0, only the status codes 301 (Moved Permanently)
      and 302 (Found) were defined for the first type of redirect, and
      the second type did not exist at all ([RFC1945], Section 9.3).
      However it turned out that web forms using POST expected redirects
      to change the operation for the subsequent request to retrieval
      (GET).  To address this use case, HTTP/1.1 introduced the second
      type of redirect with the status code 303 (See Other) ([RFC2068],
      Section 10.3.4).  As user agents did not change their behavior to
      maintain backwards compatibility, the first revision of HTTP/1.1
      added yet another status code, 307 (Temporary Redirect), for which
      the backwards compatibility problems did not apply ([RFC2616],
      Section 10.3.8).  Over 10 years later, most user agents still do
      method rewriting for status codes 301 and 302, therefore this
      specification makes that behavior conformant in case the original
      request was POST."

On the other hand, if this behavior is happening on a 307 Temporary Redirect, then I'd agree
this is a bug:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.8

"If the 307 status code is received in response to a request other than GET or HEAD, the user
agent MUST NOT automatically redirect the request unless it can be confirmed by the user,
since this might change the conditions under which the request was issued."

Are you seeing this behavior on a 302 or a 307?

                
      was (Author: jonm):
    @Justus: This is actually compliant HTTP/1.1 behavor. See:

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-20#page-28

      "Note: In HTTP/1.0, only the status codes 301 (Moved Permanently)
      and 302 (Found) were defined for the first type of redirect, and
      the second type did not exist at all ([RFC1945], Section 9.3).
      However it turned out that web forms using POST expected redirects
      to change the operation for the subsequent request to retrieval
      (GET).  To address this use case, HTTP/1.1 introduced the second
      type of redirect with the status code 303 (See Other) ([RFC2068],
      Section 10.3.4).  As user agents did not change their behavior to
      maintain backwards compatibility, the first revision of HTTP/1.1
      added yet another status code, 307 (Temporary Redirect), for which
      the backwards compatibility problems did not apply ([RFC2616],
      Section 10.3.8).  Over 10 years later, most user agents still do
      method rewriting for status codes 301 and 302, therefore this
      specification makes that behavior conformant in case the original
      request was POST."

                  
> LaxRedirectStrategy converts POST to GET and throws away body
> -------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1248
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1248
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>    Affects Versions: 4.2.1
>            Reporter: Justus Pendleton
>
> The LaxRedirectStrategy extends the DefaultRedirectStrategy. The DefaultAsyncRequestDirector
calls _redirectStrategy.isRedirected()_ and LaxRedirectStrategy will return *true* on a POST.
Then the director calls _redirectStrategy.getRedirect()_. The LaxRedirectStrategy doesn't
implement this method so the one in the DefaultRedirectStrategy is called:
> {code}
>         if (method.equalsIgnoreCase(HttpHead.METHOD_NAME)) {
>             return new HttpHead(uri);
>         } else {
>             return new HttpGet(uri);
>         }
> {code}
> This turns the POST into a GET on redirect. IMHO the LaxRedirectStrategy should be
> {code}
>     public HttpUriRequest getRedirect(
>             final HttpRequest request,
>             final HttpResponse response,
>             final HttpContext context) throws ProtocolException {
>         URI uri = getLocationURI(request, response, context);
>         String method = request.getRequestLine().getMethod();
>         if (method.equalsIgnoreCase(HttpHead.METHOD_NAME)) {
>             return new HttpHead(uri);
>         else if (method.equalsIgnoreCase(HttpPost.METHOD_NAME)) {
>             return new HttpPost(uri);
>         } else if (method.equalsIgnoreCase(HttpGet.METHOD_NAME)) {
>             return new HttpGet(uri);
>         } else {
>             throw new IllegalStateException("Redirect called on un-redirectable http
method: " + method);
>     }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message