#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:
- 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.
- 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)
Change History (10)
comment:1 Changed 15 years ago by mnot@…
- Component set to auth
- Milestone set to unassigned
comment:2 Changed 15 years ago by mnot@…
- Component changed from auth to payload
comment:3 Changed 15 years ago by julian.reschke@…
- Milestone changed from unassigned to 04
- Owner set to julian.reschke@…
comment:4 Changed 14 years ago by julian.reschke@…
- Milestone changed from 04 to unassigned
comment:5 Changed 14 years ago by mnot@…
depends on #79
comment:6 Changed 14 years ago by julian.reschke@…
- Milestone changed from unassigned to 07
comment:7 Changed 14 years ago by julian.reschke@…
comment:8 Changed 14 years ago by mnot@…
- Resolution set to fixed
- Severity set to Active WG Document
- Status changed from new to closed
comment:9 Changed 13 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.
Proposal: just drop "PUT and POST".