#104 closed design (invalid)
Header field type defaulting
Reported by: | mnot@… | Owned by: | |
---|---|---|---|
Priority: | later | Milestone: | unassigned |
Component: | non-specific | Severity: | Active WG Document |
Keywords: | Cc: |
Description
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.
Change History (6)
comment:1 Changed 15 years ago by fielding@…
comment:2 Changed 14 years ago by mnot@…
- Priority set to low
comment:3 Changed 12 years ago by 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.
comment:4 Changed 12 years ago by fielding@…
comment:5 Changed 12 years ago by mnot@…
- Resolution set to invalid
- Severity set to Active WG Document
- Status changed from new to closed
comment:6 Changed 11 years ago by julian.reschke@…
- Summary changed from Header type defaulting to Header field type defaulting
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.