Opened 15 years ago
Closed 12 years ago
#69 closed design (fixed)
Clarify "Requested Variant"
Reported by: | mnot@… | Owned by: | |
---|---|---|---|
Priority: | urgent | Milestone: | 11 |
Component: | non-specific | Severity: | Active WG Document |
Keywords: | Cc: |
Description
The spec uses the term "requested variant" in several places (10.2.2 201 Created, 10.2.5 204 No Content, 14.19 ETag, 14.25 If-Modified-Since, 14.28 If-Unmodified-Since). It's quite clear what it means in the context of HEAD/GET, somewhat clear for PUT, but not clear at all for other methods.
We really need to clarify this, potentially choosing a different term.
Change History (14)
comment:1 Changed 15 years ago by mnot@…
- Component set to auth
comment:2 Changed 15 years ago by mnot@…
- Component changed from auth to messaging
comment:3 Changed 15 years ago by mnot@…
- Milestone set to unassigned
comment:4 Changed 15 years ago by mnot@…
- Component changed from messaging to non-specific
comment:5 Changed 15 years ago by mnot@…
Dependency on #109.
Part of resolving this ticket will involve removing the "requested variant" phrase from parts of the spec where its use isn't required, as part of other rewrites.
comment:6 Changed 14 years ago by mnot@…
related to #22
comment:7 Changed 14 years ago by mnot@…
- Priority set to normal
Reminder: may need to revise definition of GET semantics for 200 response (p2 3.2.1) as a result of this issue's resolution.
comment:8 Changed 14 years ago by mnot@…
- Priority changed from normal to urgent
comment:9 Changed 14 years ago by mnot@…
Basic plan is to rewrite on a case-by-case basis.
comment:10 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.
comment:11 Changed 13 years ago by fielding@…
comment:12 Changed 13 years ago by fielding@…
- Milestone changed from unassigned to 11
- Resolution set to incorporated
- Severity set to Active WG Document
- Status changed from new to closed
Replaced with either representation, resource, or "the representation that would have been transferred in a 200 response to a GET request on the same resource", as appropriate.
comment:13 Changed 12 years ago by mnot@…
- Resolution incorporated deleted
- Status changed from closed to reopened
comment:14 Changed 12 years ago by mnot@…
- Resolution set to fixed
- Status changed from reopened to closed
From http://www.w3.org/mid/F2154EEA-1B28-4C8F-BB64-D3AD29D0F9F9@gbiv.com