Re: Rev81: COMMENT: 5.2 The Resource Identified by a Request

Jim,
	Reading section 5.2 and 5.3, I had a similar question about
the interaction of the receipt of an absoluteURI and the lack of a
HOST header.  The first bullet in 5.2 can be read to imply that an
origin server which receives a Request-URI which is an absoluteURI and
no HOST header should return the resource named in the
Request-URI. This reading is possible because the first bullet states
that any HOST header MUST be ignored when the Request-URI is an
absoluteURI.  Section 14.23 states, however, that any HTTP/1.1 request
without a HOST header must get a 400 status code in the response.
 
Either we need to put an "unless the Request-URI is an absoluteUri"
into 14.23, or we need to add something to section 5.2 which makes it
clear that there must be a host header for the origin server to
ignore, even if the Request-URI is an absoluteURI.  

				regards,
					Ted Hardie 
 


> 
> Actually, there is a more serious problem with Roy's rewrite of 5.1 and 5.2
> section in the current document (04a) that I missed when vetting his changes
> (and mostly improvements).
> 
> The requirement that all servers check that the host part is supplied
> one way or the other only is required to servers supporting multiple
> hosts in the current text.  This requirement should be stronger; that
> all servers check and generate errors if host information is not
> present one way or the other.  Otherwise we won't necessarily get the
> desired effect of detecting buggy 1.1 clients until 1.1 servers are
> deployed, likely much after when clients are shipped.  This would
> result in the scenario of none of the host requirements being
> effective to solve the problem they were intended to solve.
> 
> So Bullet #3 in 5.2 should be pulled out and put at the end of the first 
> paragraph of section 5.2.
> 
> I think this fixes your problem as well.
> 				- Jim
> 
>

Received on Friday, 31 May 1996 11:09:04 UTC