Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#304 closed editorial (incorporated)

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

Reported by: julian.reschke@… Owned by: ylafon@…
Priority: normal Milestone: 16
Component: p4-conditional Severity: Active WG Document
Keywords: Cc:


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 (4)

comment:1 Changed 11 years ago by julian.reschke@…

  • Owner changed from draft-ietf-httpbis-p4-conditional@… to ylafon@…

comment:2 Changed 11 years ago by julian.reschke@…

From [1339]:

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

comment:3 Changed 11 years ago by julian.reschke@…

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

comment:4 Changed 11 years ago by fielding@…

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.