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

Ticket #304 (closed editorial: incorporated)

Opened 4 years ago

Last modified 4 years ago

If-Range should be listed when dicussing contexts where L-M can be considered strong

Reported by: julian.reschke@gmx.de Owned by: ylafon@w3.org
Priority: normal Milestone: 16
Component: p4-conditional Severity: Active WG Document
Keywords: Cc:
Origin: http:///www.w3.org/mid/FFF1050961D037449853E9383C50E957622D40D7@TK5EX14MBXC203.redmond.corp.microsoft.com


Raised by Matthew Cox:

Part 5 section 5.3 If-Range has the following text in the case that the response has no etag and only Last-Modified.

If a client wishes to perform a sub-range retrieval on a value for which it has only a Last-Modified time and no opaque validator, it MAY do this only if the Last-Modified time is strong in the sense described in Section 2.1.2 of [Part4].

Section 2.1.2 in Part 4 has this text:

o The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header field, because the client has a cache entry for the associated representation, and

o That cache entry includes a Date value, which gives the time when the origin server sent the original response, and

o The presented Last-Modified time is at least 60 seconds before the Date value.

This seems to exclude If-Range which is strange since the If-Range text pointed to this section. Is it possible to add If-Range to the text in the first bullet point, or make the text more generic such that it doesn't exclude other methods that use the Last-Modified time?

Change History

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

  • Owner changed from draft-ietf-httpbis-p4-conditional@tools.ietf.org to ylafon@w3.org

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

From [1339]:

If-Range should be listed when dicussing contexts where L-M can be considered strong (see #304)

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

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

comment:4 Changed 4 years ago by fielding@gbiv.com

From [1374]:

Clarify what should happen when a response is incomplete. Disentangle the requirements surrounding conditional range requests, strong validators, and recombining partial content to remove redundant redundancy. Separate handling of 304 responses into a separate section on cache freshening.

Add definitions for "cache entry" and "cache key". Improve introductions for caching and cache operation.

These changes should all be editorial, hopefully. Tangentially related to #101 and #304.

Note: See TracTickets for help on using tickets.