Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Wed, 10 Oct 2012 10:01:04 +0000 (UTC)
From: "Jon Moore (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <2066611599.19121.1349863264341.JavaMail.jiratomcat@arcas>
In-Reply-To: <134640548.17433.1349827323113.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (HTTPCLIENT-1248) LaxRedirectStrategy converts
 POST to GET and throws away body
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jon Moore commented on HTTPCLIENT-1248:
---------------------------------------

@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