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:26 -0800 (PST)
---------- Forwarded message ----------
Date: 22 Nov 1997 14:10:01 -0000
From: Anand Kumria <[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: Anand Kumria <[EMAIL PROTECTED]>
To: Alexei Kosut <[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 23:56:09 +1100 (EST)
On Sat, 22 Nov 1997, Alexei Kosut wrote:
> 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.
Perhaps; but I believe the processing strategy should be:
1. Is it an absoluteURI? Yes? Cool, we ignore a Host: header, if *any*
("Any host header field value in the request MUST be ignored.") and use
what was specified in the absoluteURI.
2. Hmm, must have been a pathURI. Is there a host header? Yes, everything
is okay.
3. Hmm: either no Host: header on previous requests or the host that was
specified isn't valid (as far as we are converned). Error 400, ogo away.
I think this makes Apache more robust ("Be liberal in what you receive, be
conservative in what you send"). However it is hard to argue the point
properly without seeing an accept grammar for HTTP/1.1, but the Apache
team seems fortunate enough to have one of the document authors (R.
Fielding) on your team, perhaps he can provide more insights.
> 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.
As I have tried to explain above the rules for processing requests don't
consider the absence of the Host: header until rule 3. Apache is rejecting
the document too early in its request parsing process.
>
> > 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.
The processing rules in section 5.2 don't consider the absence of the
Host: header until rule 3. You can regard the absence of a host header as
host which is invalid.
>
> > 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.
I think you are rejecting the request too early on - rule 3 is the last
thing in the request process.
Anand.
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
