Re: Comments on draft HTTP/1.1 spec, v3

> > ambiguity on application of request header semantics.
> > Suppose a request contains an error.  Should all semantics
> > of all correct headers in the request be applied?  For
> > example, consider
> > 
> >   HEAD /index.html HTTP/1.1
> >   Host: 128.122.238.94:9999
> >   Connection: close
> >   TE: chunked
> >   If-Modified_since: foo
> > 
> > "foo" is an invalid value for If-Modified, and therefore the
> > one and only correct response to this message will be 400.
> 
> Actually, no.  The most recent draft,
> draft-ietf-http-v11-spec-rev-03.txt (and earlier ones, too), is quite
> clear on this.  In 14.25 If-Modified-Since the spec. says, "If the
> request would normally result in anything other than a 200 (OK) status,
> or if the passed If-Modified-Since date is invalid, the response is
> exactly the same as for a normal GET."  Your example is the "invalid
> date" case.

The use of If-Modified-Since is an unfortunate example since its handling in the 
case of an error is explicitly stated in the draft.  The question is more general:  
if a request is sent and one of its headers contains an error resulting in a 400 
Bad Request status code, should the remaining, valid headers be parsed and 
treated as usual?  That is, to consider an example similar to that above, 
consider a request:

GET /index.html HTTP/1.1
TE: chunked
Connection: close

This is a bad request due to the lack of the Host header field.  Should the 
server respond with chunked data and then close the connection?  That is, 
should the semantics of the valid headers apply?

> > Should the response, containing a 400 bad request error,
> > return the error chunked and then close the connection?  In
> 
> TE is a request header that provides advice from the client to the
> server.  I think you meant Transfer-Encoding: chunked.

No, he meant TE.  The client sent TE to request chunked transfer encoding, 
but the request itself was bad.  Should the server nonetheless send the error 
body in a chunked format (and then close the connection, as per the 
Connection: close header)?  You say yes, but we had trouble determining this 
from the current draft standard.


Adam Donahue


mailto:adam@cyber-guru.com

Received on Thursday, 30 April 1998 20:29:50 UTC