Header field type defaulting

[mnot@…]

Currently, unknown headers are treated as entity headers;

...Unrecognized header fields are treated as entity-header fields. (various places)

Often, however, extension headers are not entity headers, and are not treated as such by implementations.

[fielding@…]

That is merely stating where they end up in the ABNF and how they should be interpreted when received in a PUT by a recipient that does not recognize the header field.

Obviously, it would have been better for each of the field types to be distinguished syntactically, but MIME does not do that and so HTTP/1.x can't either.

If we change the spec to say that all unrecognized header fields should simply be ignored (forwarded downstream but never saved), then a lot of these strange handling requirements can be removed. My guess is that "must ignore" behavior is more consistent with current implementations than what is specified in 2616.

[fielding@…]

From [1158]:

Replaced the general prohibition on unrecognized Content-* header fields with a specific prohibition of Content-Range (the only field for which it is an actual problem) and a general requirement regarding checking for consistency. Unfortunately, this required rewriting the entire section on PUT to get rid of the misconceptions about storing resources and reflect how PUT is actually implemented in practice.

Addresses #79, #102, #103, #104, #112, #180, #231, and #267

[fielding@…]

From [1163]:

Remove header field classifications.

Addresses #224 and #104