Bugs item #1703444, was opened at 2007-04-19 10:19
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1703444&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: documentation
Group: None
Status: Open
Resolution: None
>Priority: 3
Private: No
Submitted By: Morten Barklund (barklund)
Assigned to: Daniel Stenberg (bagder)
Summary: -L documentation does not reflect actual behaviour

Initial Comment:
When curl'ing a URL with a --data content and the URL returns a location header along with a 3xx response code, the new URL is curl'ed without the --data but with all other headers intact.

This follows the specification of the rfc, but it is not reflected in the man-page, which states:

       -L/--location
              (HTTP/HTTPS) If the server reports that
              the requested page has moved to a different
              location (indicated with a Location: header
              and a 3XX response code) this option
              will make curl redo the request on the
              new place. If used together with
              -i/--include or -I/--head, headers from all
              requested pages will be shown. When
              authentication is used, curl only sends
              its credentials to the initial host. If a
              redirect takes curl to a different host, it
              won't be able to intercept the
              user+password. See also --location-trusted
              on how to change this. You can limit the
              amount of redirects to follow by using the
              --max-redirs option.

It should somehow be reflected, that if first request is POST, second (and consecutive) request(s) will be GET-requests without the body of the first.

Example is a simple PHP-page like:

 <?php
 header("Location: ".$_SERVER['REQUEST_URI']);
 header("X-method: ".$_SERVER['REQUEST_METHOD']);
 header("X-post-body: ".file_get_contents("php://input"));
 ?>

When invoked like:

  curl -i --data 'test=boing' --max-redirs 1 -L http://host/path/method_test.php

Response is correctly:

 HTTP/1.1 302 Found
 Location: /path/method_test.php
 X-method: POST
 X-post-body: test=boing
 Content-Length: 0
 Content-Type: text/html; charset=ISO-8859-1

 HTTP/1.1 302 Found
 Location: /path/method_test.php
 X-method: GET
 X-post-body:
 Content-Length: 0
 Content-Type: text/html; charset=ISO-8859-1

 curl: (47) Maximum (1) redirects followed

(irrelevant headers stripped)

Thanks for a great tool anyways :)

-- 
Morten Barklund
----------------------------------------------------------------------
>Comment By: Daniel Stenberg (bagder)
Date: 2007-04-19 10:26
Message:
Logged In: YES 
user_id=1110
Originator: NO
(lib)curl does not unconditionally switch from POST to GET. It depends
entirely on the response code. In your case you got a 302 back, and I feel
it appropriate to quote this (somewhat large) comment below from the source
code regarding the behavior you see. The quote originates from RFC2616. But
anyway, if you can think if a way to explain this in the -L documentation
section, please help me out...
    /* (From 10.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.                           
      
                                                                          
      
    (From 10.3.4)                                                         
      
                                                                          
      
    Note: Many pre-HTTP/1.1 user agents do not understand the 303         
      
    status. When interoperability with such clients is a concern, the     
      
    302 status code may be used instead, since most user agents react     
      
    to a 302 response as described here for 303.                          
      
  
----------------------------------------------------------------------
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1703444&group_id=976