Haxx ad

curl's project page on


cURL > Mailing List > Monthly Index > Single Mail

curl-tracker mailing list Archives

[ curl-Bugs-1703444 ] -L documentation does not reflect actual behaviour

From: <>
Date: Thu, 19 Apr 2007 01:26:32 -0700

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:

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:

              (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:

 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
 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
Logged In: YES 
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:
Received on 2007-04-19

These mail archives are generated by hypermail.

donate! Page updated November 12, 2010.
web site info

File upload with ASP.NET