I'm thinking I must be smoking something, but:
When I use wget, it is always emitting HTTP/1.0 requests, which is actually a
lie.
For example:
write(3, "GET /pics/button_forum.png HTTP/1.0\r\n
User-Agent: Wget/1.10.2\r\n
Accept: */*\r\n
Host: kpic1\r\n
Connection: Keep-Alive\r\n
\r\n
", 114) =
On Tue, 1 May 2007, Greg Lindahl wrote:
Host: kpic1 is a HTTP/1.1 feature. So this is non-sensical.
Some pre-1.1 servers have required this header, I don't see how the 1.0 spec
forbids it and by using it you can utilize name-based virtual hosting so I
disagree with your conclusion.
Greg Lindahl <[EMAIL PROTECTED]> writes:
> Host: kpic1 is a HTTP/1.1 feature. So this is non-sensical.
The `Host' header was widely used with HTTP/1.0, which is how it
entered the HTTP/1.1 spec.
For other reasons, Wget should really upgrade to using HTTP/1.1.
On Wed, May 2, 2007 9:16 am, Daniel Stenberg wrote:
>> Host: kpic1 is a HTTP/1.1 feature. So this is non-sensical.
>
> Some pre-1.1 servers have required this header, I don't see how the 1.0
> spec
> forbids it and by using it you can utilize name-based virtual hosting so I
> disagree with your co
As a concrete example where wget's HTTP/1.0 header causes an issue,
I'm evaluating a Juniper DX web cache, and it is sending a different
response to wget than to a browser, thanks to the HTTP/1.0 query. (When
I sent the original email I hadn't confirmed this was true, it is.)
I think this is actua
Graham Leggett wrote:
> On Wed, May 2, 2007 9:16 am, Daniel Stenberg wrote:
>
> >> Host: kpic1 is a HTTP/1.1 feature. So this is non-sensical.
> >
> > Some pre-1.1 servers have required this header, I don't see how the 1.0
> > spec
> > forbids it and by using it you can utilize name-based virtual
