Re: cURL behavior on 303 does not seem to be what is documented/advertised?
Date: Fri, 18 Jan 2013 08:40:52 +0100 (CET)
On Thu, 17 Jan 2013, Yves Arrouye wrote:
> Thanks. The man page on -X is unclear: it does not mention that -X is
> "sticky" across redirections. Maybe that could be improved.
Everything can be improved. Did you really read this documentation first and
then yet beleived -X POST was what you needed?
I'll readily admit that I am not the perfect teacher or document writer. I
gladly receive patches and improvements for docs as well!
> The verbose message saying using GET right before POSTing could also be
> slightly conditional so it says the right thing :)
Perhaps. You need to keep in mind that -X only modifies the method string in
the request, and libcurl has several more behaviors associated to what action
it takes. So when libcurl decides it'll make a GET it will act accordingly,
and even if you change that to a "POST" in the reqeuest there are several
other internal code paths that still will act as GET. (It might become clearer
if you instead use -X GLORBIFLUX and then read the verbose output.)
IMHO, you should instead report the flawed command line examples and tell them
to stop abusing -X...
>> You should instead get the host name from the struct member that is (later)
>> used to create the host header.
> Are you talking about the conn->host structure? I started there, but if
> there is a custom Host header, I need to use that. So I'd rather let curl do
> all the work it wants to do in determining what that header should look like
> (using the custom one, using the URL data, properly brace-quoting IPv6
> addresses etc.) and then use that. Is there a reason not to (maybe it's
Some thoughts from me:
1 - a custom Host: is not a good way to "test drive" HTTP services anyway so
while that as a long time the only way you could do that with (lib)curl
and we promoted that way you can just go back to your redirect case to
see a custom host header immediately breaks. The better way to test and
the way I prefer to promote is...
2 - --resolve is a much better and cleaner way to allow a user to "fake" a
server to be somewhere else. It allows things like HTTP redirects,
HTTP cookies, HTTPS certificates and your authentication to work easier
and with less internal hacks.
3 - before we introduced (2) we had roughly the same need you do but for
cookies so you'll find the sort of custom "host:" header extraction logic
in the lib/http.c:Curl_http() function. If (2) for some reason isn't
enough for you (and if so, I want it properly motivated), I would suggest
that generalizing this code is the way forward. If we would've had the
--resolve approach in place before, then this cookie host code wouldn't
have been introduced!
-- / daniel.haxx.se
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2013-01-18