> >
>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?

No. But once you pointed me towards not using -X, I looked at -X again.
I'll be happy to improve the doc myself, by the way.

> [...] --resolve [...]

I don't think that --resolve is the right thing here. The reason the
Internet-Draft asks for the Host header is simply to support virtualized
hosts. The HTTP MAC is computed to authorize a request made to the virtual
host (not the physical host that hosts the virtual one if there are
virtual hosts), and that is indicated by the Host header which is required
in HTTP 1.1. So I truly believe that Host *exactly as sent by curl* is the
right thing to get to generate that HTTP MAC.

YA

---
Learn about GPT services and architectures on Confluence.
<http://confluence/display/GPT/GPT+Architecture>
On 1/17/13 11:40 PM, "Daniel Stenberg" <daniel_at_haxx.se> wrote:
>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