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

Ticket #110 (closed design: fixed)

Opened 6 years ago

Last modified 4 years ago

Clarify rules for determining what entities a response carries

Reported by: mnot@pobox.com Owned by: fielding@gbiv.com
Priority: urgent Milestone: unassigned
Component: non-specific Severity: Active WG Document
Keywords: Cc:
Origin: #69

Description

A response can carry a representation/entity of the resource identified by the request-uri, but it can also carry an entity associated with a different resource, as per the Content-Location header, or it may even carry an "anonymous" representation that isn't associated with a URI (a.k.a. a "status message").

The rules for determining this should be clarified in the specification.

Depends on #69 to some degree. See also #22.

Attachments

110.diff (3.8 KB) - added by julian.reschke@gmx.de 5 years ago.
Proposed parial patch for Part 2

Change History

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

  • Priority set to blocked

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

  • Owner set to fielding@gbiv.com
  • Priority changed from blocked to urgent
  • Severity set to Active WG Document

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

Above approach discussed at Stockholm WG meeting; general agreement that it's roughly the right approach. Waiting for more refined proposals (possibly including new terminology).

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

Proposed parial patch for Part 2

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

From [695]:

Clarify rules for determining what entities a response carries (see #110 #196)

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

  • Status changed from new to closed
  • Resolution set to fixed

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

From [716]:

In description of C-L, add a reference to Part 2 where it defines client processing (see #110)

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

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

From [1079]:

fix typo ('target' -> 'target resource') (see #110)

Note: See TracTickets for help on using tickets.