On Thu, 23 Aug 2001, Roth, Kevin P. wrote:

> I tested out the -G option (appreciate the quick implementation).

Credits and glory should be thrown at SM for that! ;-)

> It appears it works fine if I actually allow it to do a "GET", but if I
> try to get back the headers only (a "HEAD" request, or -I) I get this
> output:
>
> > curl -v -I "http://testweb/test.asp" -d 1=2 -G
> You can only select one HTTP request!
>
> If I change -I to -i, it works fine.
>
> I know a "HEAD" isn't a "GET", but both follow the idea that all form
> fields, if any, should go into the URL. So I think this SHOULD work, and
> therefore that this is probably a bug. I have NOT read the RFC lately
> though, so it may be technically incorrect; however if that's the case,
> then at least the error message could be a little better.

Uh. I believe I can take the credit for that one! ;-O

I think you're right. Using -I -d and -G all in one line builds a URL and
make HEAD on it. Let's think of -G as "build a URL from the passed data,
default to GET", so -d -G makes a GET, while -d -G -I makes a HEAD.

It's all just a matter of how the client works with the inputs, it doesn't
affect anything put in any RFC we follow. (AFAIK)

> Issue two: if I do this:
>
> > curl -v -i "http://testweb/test.asp?a=b" -d 1=2 -G -o t.txt
> * Connected to testweb (xx.x.xx.xxx)
> > GET /test.asp?a=b?1=2 HTTP/1.1

Right. There should be a check for an existing question mark first, and if
one is present there should be an ampersand added as a separator.

src/main.c 1.91 was just committed, it seems to deal with both your described
cases.

Thanks for your detailed report!

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/