Opened 13 years ago

Closed 13 years ago

Last modified 10 years ago

#103 closed design (fixed)

Content-*

Reported by: mnot@… Owned by: julian.reschke@…
Priority: Milestone: unassigned
Component: p2-semantics Severity:
Keywords: Cc:

Description

What does Content-* mean? Does it mean all headers prefixed with "Content-", or just those headers prefixed by "Content-" that are defined in RFC 2616?

Attachments (2)

132.diff​ (983 bytes) - added by julian.reschke@… 13 years ago.
proposed change for part 2
i103.diff​ (978 bytes) - added by julian.reschke@… 13 years ago.
proposed change for part 2.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 13 years ago by fielding@…

It means all header fields that strat with the prefix "Content-", regardless of where they were defined.

comment:2 Changed 13 years ago by julian.reschke@…

  • Owner set to julian.reschke@…
  • Status changed from new to assigned

Changed 13 years ago by julian.reschke@…

proposed change for part 2

Changed 13 years ago by julian.reschke@…

proposed change for part 2.

comment:3 Changed 13 years ago by julian.reschke@…

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in [333]:

Resolve #103: explain shorthand notation "Content-*" (closes #103).

comment:4 Changed 10 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

Note: See TracTickets for help on using tickets.