Content-Location isn't special

[mnot@…]

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

[julian.reschke@…]

Proposal: just drop "PUT and POST".

[mnot@…]

depends on #79

[julian.reschke@…]

proposed change for part 3.

[julian.reschke@…]

From [577]:

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

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