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

Ticket #167 (closed design: fixed)

Opened 5 years ago

Last modified 4 years ago

Content-Location on 304 responses

Reported by: mnot@pobox.com Owned by: mnot@pobox.com
Priority: normal Milestone: unassigned
Component: p6-cache Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/4A1C2426.6010205@qbik.com

Description

p6 section 2.2 para 5 says

If the server responds with 304 (Not Modified) and includes an entity tag or Content-Location that indicates the entity to be used

I.e., a Content-Location can be used in a 304 response to identify the cached response to use.

Is this implemented anywhere, and is it an appropriate use of C-L? If not (on either count), should we just remove this language?

Attachments

167.diff (1.6 KB) - added by julian.reschke@gmx.de 5 years ago.
Proposed patch for part 6.

Change History

comment:1 Changed 5 years ago by henrik@henriknordstrom.net

Just stumbled across this text myself, and I seriously doubt anyone implements Content-Location based selection. I vote to remove Content-Location from there.

My reasoning: Unlike ETag (If-None-Match) there is no means for Content-Location to be used as a validator in the forwarded request. So unless the negotiated resource have ETag assigned to all variants then this method of asking the server which other response matches this request can not be applied in a straight manner. And if ETag is provided then it MUST be present in the 304 response, making the use of Content-Location mostly redundant for finding the matching cached response.

The way to apply this selection process based on Content-Location (without ETag) is to use "If-None-Match: *" without any If-Modified-Since condition, and then retransmit the request without the condition if there is no matching cached response matching the received 304 response.

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

  • Owner set to mnot@pobox.com
  • Priority set to normal

Not very useful; proposal is to remove content-location as a variant identifier for purposes of caching. Not widely implemented.

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

Proposed patch for part 6.

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

From [691]:

remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to use (see #167)

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

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

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