The following reply was made to PR protocol/1454; it has been noted by GNATS.
From: Dean Gaudet <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Subject: Re: protocol/1454: Apache doesn't always understand requests with
the absoluteURI in them (fwd)
Date: Sat, 22 Nov 1997 14:08:40 -0800 (PST)
---------- Forwarded message ----------
Date: 22 Nov 1997 11:40:00 -0000
From: Alexei Kosut <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED],
Subject: Re: protocol/1454: Apache doesn't always understand requests with the
absoluteURI in them
The following reply was made to PR protocol/1454; it has been noted by GNATS.
From: Alexei Kosut <[EMAIL PROTECTED]>
To: Anand Kumria <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: protocol/1454: Apache doesn't always understand requests with the
absoluteURI in them
Date: Sat, 22 Nov 1997 03:38:38 -0800 (PST)
On Sat, 22 Nov 1997, Anand Kumria wrote:
> However this processing strategy is contrary to Section 5.2 which states:
>
>
> 1. If Request-URI is an absoluteURI, the host is part of the
> Request-URI. Any Host header field value in the request MUST be
> ignored.
>
> 2. If the Request-URI is not an absoluteURI, and the request
> includes a Host header field, the host is determined by the Host
> header field value.
>
> 3. If the host as determined by rule 1 or 2 is not a valid host on
> the server, the response MUST be a 400 (Bad Request) error
> message.
I refer you to section 14.23:
"All Internet-based HTTP/1.1 servers
MUST respond with a 400 status code to any HTTP/1.1 request message
which lacks a Host header field."
These two quotes are regerring to different things. Section 5.2, which you
quoted, *assumes* that the Host: header is present, and simply dictates
the precedence of the full URI's host vs. the Host: header. The 400
response mentioned refers to what happens if the named host does not match
one the server is configured for. Section 14.23 and 5.1.2 are what
dictate the server's behavior in the case we are discussing.
The fact is, all HTTP/1.1 requests must contain a Host: header (section
5.1.2), regardless of the type of URI used. And Apache is certainly
allowed to behave critically when faced with an uncompliant
implementation. The fact that the spec in fact requires this behavior
simply makes this more evident.
> Essentially the canocial form of a request is
>
> <method> <aboluteURI> <version>
>
> however HTTP/1.1 server must ALSO understand:
>
> <method> <pathURI> <versioN>
> Host: <host>
>
> which can easily be canonicalised.
Nope. That's incorrect. HTTP/1.1 does not allow the use of full URIs in
origin server requests, only proxy requests. Servers are required to
*accept* them for origin requests, to allow for that possibility in future
versions of HTTP. And all HTTP/1.1 requests must contain a Host: header,
regardless of whether they are origin or proxy.
> Additionally you have not addressed the second half of my bug report -
> where I show that an absoluteURI AND a host header works. The Host:
> header should have no impact, it is implied by the absolute URI.
Of course it works. It has to, if Apache is to be compliant with HTTP/1.1.
And the Host: header does not have any impact. Try it yourself; Apache
ignores its content. However, in order to be a valid HTTP/1.1 request, it
has to contain that header. Apache is required to reject it with a 400
response if it does not.
-- Alexei Kosut <[EMAIL PROTECTED]> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
