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

Ticket #102 (closed design: wontfix)

Opened 7 years ago

Last modified 4 years ago

Understanding Content-* on non-PUT requests

Reported by: mnot@pobox.com Owned by: fielding@gbiv.com
Priority: normal Milestone: 13
Component: p2-semantics Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/001501c870b6$d2a078f0$6501a8c0@T60

Description

RFC2616 Section 9.6 (PUT) places the following requirement on PUT recipients:

The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

Does this advice apply to other request methods than PUT? E.g., POST? Should it apply to all requests with bodies?

Change History

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

The notion of Content- being a special prefix comes from MIME, where it is the required prefix for metadata that describes a MIME part. This paragraph should have merely described the purpose of Content- header fields and state what the recipient should do with unrecognized header fields.

The original design was that such metadata should be stored as entity headers and regurgitated as such. However, that is only true when no transformations are done for the PUT. At most, this should only warn implementations that all of the metadata needs to be understood or discarded whenever changes are made to the corresponding data.

Content-Range, in particular, should not be allowed on requests.

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

  • Priority set to normal
  • Severity set to Active WG Document
  • Milestone changed from unassigned to 11

Proposal:

  • remove the requirement text
  • add explanatory (non-requirement) text that warns implementations that all of the metadata needs to be understood or discarded whenever changes are made to the corresponding data.

comment:3 Changed 4 years ago by julian.reschke@gmx.de

  • Milestone changed from 11 to 12

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

  • Owner set to fielding@gbiv.com

Also closes #79.

Roy, do you want to put in text specifically about Content-Range on requests, as per above, or is it good enough to just remove the text and add implementation advice?

comment:5 Changed 4 years ago by julian.reschke@gmx.de

  • Milestone changed from 12 to 13

comment:6 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:7 Changed 4 years ago by fielding@gbiv.com

  • Status changed from new to closed
  • Resolution set to wontfix

This ticket is about non-PUT requests. As far as I know, the only reason for the original prohibition was its applicability to PUT, namely because the PUT semantics called on the origin server to save the representation (including metadata) and that metadata might include Content-Range. None of the other methods has that semantic, so this issue can be closed.

Note: See TracTickets for help on using tickets.