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

Ticket #80 (closed design: fixed)

Opened 7 years ago

Last modified 4 years ago

Content-Location isn't special

Reported by: mnot@pobox.com Owned by: julian.reschke@gmx.de
Priority: Milestone: 07
Component: p3-payload Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/46AF60B0.7000104@gmx.de

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

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

Change History

comment:1 Changed 7 years ago by mnot@pobox.com

  • Component set to auth
  • Milestone set to unassigned

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

  • Component changed from auth to payload

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

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

Proposal: just drop "PUT and POST".

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

  • Milestone changed from 04 to unassigned

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

depends on #79

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

  • Milestone changed from unassigned to 07

Changed 5 years ago by julian.reschke@gmx.de

proposed change for part 3.

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

From [577]:

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

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

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

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

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.