Re: Comments on draft HTTP/1.1 spec, v3

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

Hmm.  I should have used another encoding I guess.  I see what you're saying.

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

Yes, this is exactly what I'm asking.

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

We were having the same problem deciding for sure how to handle the above 
cases. 

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

I think the spec is somewhat clear about this.  In section 10.4:

    Except when responding to a HEAD request, the server SHOULD include an 
entity containing an explanation of the error situation, and whether it is a 
temporary or permanent condition.

I'd gather from the above that the HEAD example you specify would not return 
an entity body.

Adam

mailto:adam@cyber-guru.com

Received on Friday, 1 May 1998 10:05:33 UTC