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
belowŠ)?
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
Etiquette: http://curl.haxx.se/mail/etiquette.html
