Re: Unknown and misplaced headers as entity headers

Brian Smith wrote:
> The specification repeatedly says that "unrecognized header fields are treated as
> entity-header fields": [Part 1, section 4.5], [Part 2, section 4], [Part 2, section 6], [Part 3, section 4.1]. However, it also says that unrecognized header fields MAY be treated as response and/or request headers. 

Yes. As in, for example, 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-02.html#rfc.section.4.p.3>:

"...Unrecognized header fields are treated as entity-header fields.".

> The BNF for extension-header is "extension-header = message-header".
> 
> Here are several issues:
> 
> * In practice, applications cannot usefully classify an unrecognized header, and they definitely do not treat them as entity headers. Declaring them to be entity headers adds confusion with no benefit.

I agree that we have a conflict between what RFC2616 says, and what many 
(most?) servers do. However I'm not sure there's a simple way to fix this.

> * The BNF for extension-header matches all other header types. That means that when a client includes a response-header in a request, or a server includes a request-header in a response, the header is to be treated as an entity header. That doesn't make any sense. 

The BNF for extension header, given in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-02.html#rfc.section.4.2>:

   message-header = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *( field-content | LWS )
   field-content  = <field content>
                    ; the OCTETs making up the field-value
                    ; and consisting of either *TEXT or combinations
                    ; of token, separators, and quoted-string

just defines the allowable syntax. We probably could state in prose that 
the value must be distinct from all other header names defined in the 
spec(s). Would that help?

> PROPOSAL:
> 
> * Remove the statements that say that unrecognized header fields are treated as entity-header fields.

I'd like to see this opened as a separate issue.

> * Move the extension-header definition to Part 1, and replace the ABNF for Request, Response, and trailer-part:
> 
>   Request       = Request-Line            ; Section 5.1
>                   *(( general-header      ; Section 4.5
>                     | request-header      ; [Part2], Section 4
>                     | entity-header       ; [Part3], Section 4.1
>                     | extension-header) CRLF)
>                   CRLF
>                   [ message-body ]        ; Section 4.3

I'm not sure how this is an improvement.

Right now we are stating that a header in a requets is either a 
general-header, a request-header, or an entity-header. That distinction 
is lost if we allow an additional "unclassified" type.

If what you're looking for is the BNF to allow new, for instance, 
general header fields, we should extend the BNF for general-header.

> ...
> As I mentioned before, I would also like to see some way of using the Accept-* headers in a "415 Unsupported Media Type" response, so that the server can indicate which media types, languages, encodings, etc. it would be willing to accept. After reviewing the charter, it seems like this would be out of scope for httpbis. If so, httpbis should at least leave the door open for it (that is, do not preclude the use of request-headers as response-headers).
> 
> - Brian

BR, Julian

Received on Wednesday, 27 February 2008 11:06:29 UTC