Re: Comments on draft HTTP/1.1 spec, v3

Adam M. Donahue wrote:
> [...]
> 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?

TE is a bad example, too, for two reasons.  First, in your example,
"identity" would still be allowed, and "chunked" is always allowed.  To
suppress "identity", if that's what you meant to convey, you would say
"TE: identity;q=0".  Second, it's my opinion that "identity" should
always be allowed.  But that's another discussion.

> 
> > > 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

Well, TE doesn't work that way, exactly.  But let's focus on...

> 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.

Yes, I overlooked what is a reasonable question, namely, must the
server, in returning the error, honor "Connection: close"?  And, in
general, must the server's error responses be consistent with all the
headers (and, for that matter, the method)?

Mumble.  I think the answer is yes.  Or at least the server should do
its best.  Sometimes the headers could be contradictory, in which case
the server has to do its best to honor them.

That leads me to my own question:  If there's an error on a HEAD
request, should the server return an entity, or just the headers. 
(Apparently the latter.)  Example:

HEAD / HTTP/1.1
<CRLF>

There's no Host header, so the server responds "400 Bad Request".  With,
or without, entity?

Dave Kristol

Received on Friday, 1 May 1998 08:57:23 UTC