Opened 9 years ago

Closed 8 years ago

Last modified 6 years ago

#80 closed design (fixed)

Content-Location isn't special

Reported by: mnot@… Owned by: julian.reschke@…
Priority: Milestone: 07
Component: p3-payload Severity: Active WG Document
Keywords: Cc:

Description

RFC2616 Section 14.14, The definition of Content-Location ends with:

"The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases."

This was added in RFC2616 (does not appear in RFC2068).

I have no problem allowing servers to ignore it. However:

  1. It seems that the meaning of Content-Location is universal for messages that carry an entity; I'm not sure what's the point in claiming that meaning does not apply to PUT or POST.
  2. Also: every time a limited set of methods is mentioned somewhere it feels like problematic spec writing. What makes PUT or POST so special in comparison to other methods? Maybe that they are the only methods in RFC2616 that carry request entity bodies? In which case the statement should be rephrased accordingly...

Attachments (1)

80.diff (3.3 KB) - added by julian.reschke@… 8 years ago.
proposed change for part 3.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 9 years ago by mnot@…

  • Component set to auth
  • Milestone set to unassigned

comment:2 Changed 9 years ago by mnot@…

  • Component changed from auth to payload

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

  • Milestone changed from unassigned to 04
  • Owner set to julian.reschke@…

Proposal: just drop "PUT and POST".

comment:4 Changed 8 years ago by julian.reschke@…

  • Milestone changed from 04 to unassigned

comment:5 Changed 8 years ago by mnot@…

depends on #79

comment:6 Changed 8 years ago by julian.reschke@…

  • Milestone changed from unassigned to 07

Changed 8 years ago by julian.reschke@…

proposed change for part 3.

comment:7 Changed 8 years ago by julian.reschke@…

From [577]:

PUT and POST requests are not special with respect to Content-Location (related to #80)

comment:8 Changed 8 years ago by mnot@…

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

comment:9 Changed 6 years ago by fielding@…

From [856]:

Addresses #69: Clarify "Requested Variant" Addresses #109: Clarify entity / representation / variant terminology

Replaced entity with payload and variant with representation. Cleaned up description of 204 status code (related to ticket #22) Rewrote section on Content-Location and refer to def in RFC2557.

Addresses #110: Clarify rules for determining what entities a response carries

Detail the rules for Content-Location and remove the cross-ref.

Addresses #167: Content-Location on 304 responses

Removed sentence in C-Loc that refers to using C-Loc to select a

variant from cache (an already removed "feature")

Addresses #136: confusing req. language for Content-Location

Removed the confusing paragraph because HTTP does not know anything about variants behind the resource interface and thus cannot make this an interop requirement. In any case, it only existed to support the already removed cache feature that nobody implemented.

Addresses #80: Content-Location isn't special

Clarifies that C-Loc is representation metadata and what (not) to do with it if received on a request.

Note: See TracTickets for help on using tickets.