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
Received on 2013-01-18