* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #104 (closed design: invalid)

Opened 7 years ago

Last modified 2 years ago

Header field type defaulting

Reported by: mnot@pobox.com Owned by:
Priority: later Milestone: unassigned
Component: non-specific Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/000d01c878e2$fb911330$6401a8c0@T60

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

comment:1 Changed 6 years ago by fielding@gbiv.com

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.

comment:2 Changed 5 years ago by mnot@pobox.com

  • Priority set to low

comment:3 Changed 4 years ago by fielding@gbiv.com

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

comment:4 Changed 4 years ago by fielding@gbiv.com

From [1163]:

Remove header field classifications.

Addresses #224 and #104

comment:5 Changed 4 years ago by mnot@pobox.com

  • Status changed from new to closed
  • Resolution set to invalid
  • Severity set to Active WG Document

comment:6 Changed 2 years ago by julian.reschke@gmx.de

  • Summary changed from Header type defaulting to Header field type defaulting
Note: See TracTickets for help on using tickets.