Opened 12 years ago

Closed 8 years ago

#79 closed design (fixed)

Content-* vs. PUT

Reported by: mnot@… Owned by: fielding@…
Priority: normal Milestone: 13
Component: p2-semantics Severity: Active WG Document
Keywords: Cc:

Description

RFC 2616, section.9.6, the description of PUT states:

"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."

That language sounds as if a server that ignores Content-Language (as opposed to storing it with the entity) MUST reject PUT requests that come with a Content-Language header. Is this really intended? Does anybody implement that?

Change History (9)

comment:1 Changed 12 years ago by mnot@…

  • Component set to auth
  • Milestone set to unassigned

comment:2 Changed 12 years ago by mnot@…

  • Component changed from auth to semantics

comment:3 Changed 10 years ago by mnot@…

comment:4 Changed 10 years ago by mnot@…

  • Owner set to fielding@…
  • Priority set to normal
  • Severity set to Active WG Document

Roy to kick off discussion. Rough proposal:

1) remove this requirement, and 2) ban partial PUTs

comment:5 Changed 9 years ago by mnot@…

See #102.

comment:6 Changed 8 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.

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

comment:7 Changed 8 years ago by fielding@…

  • Milestone changed from unassigned to 13
  • Resolution set to incorporated
  • Status changed from new to closed

comment:8 Changed 8 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:9 Changed 8 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.