SHOULD send the Last-Modified value in non-subrange cache
validation requests (using If-Modified-Since) if only a Last-
Modified value has been provided by the origin server.
MAY send the Last-Modified value in subrange cache validation
requests (using If-Unmodified-Since) if only a Last-Modified value
has been provided by an HTTP/1.0 origin server. The user agent
SHOULD provide a way to disable this, in case of difficulty.
I'm failing to come up with an explanation for why it's important to specifically call out the HTTP/1.0 origin server in the latter case. What's special about an HTTP/1.1 origin server that only provided a Last-Modified value and subrange cache validation requests that makes the MAY inapplicable? (What's the actual expected behavior for that situation?)
There exists a bit of rot here. First, this reflects the original implementation of If-Unmodified-Since being applicable to GET and caches, which conflicts with the (new) last sentence of 13.1.4.
The If-Unmodified-Since header field can be ignored by caches and intermediaries because it is not applicable to a stored response.
Second, this function (subrange conditional GET requests) is why If-Range was introduced late in the HTTP/1.1 design, and the above text predates that field (which is why it doesn't say If-Range instead).
Third, the text is obsolete because nobody cares about byte range consistency in subrange requests to HTTP/1.0 origin servers, because that was a theoretical concern in early 1996 and there are no longer any HTTP/1.0 origin servers that implement Range, nor would we care if people occasionally got funky spliced content in HTTP/1.0 responses just because more than one modification was made within the same timestamp.
This was part of #914
There exists a bit of rot here. First, this reflects the original implementation of If-Unmodified-Since being applicable to GET and caches, which conflicts with the (new) last sentence of 13.1.4.
Second, this function (subrange conditional GET requests) is why If-Range was introduced late in the HTTP/1.1 design, and the above text predates that field (which is why it doesn't say If-Range instead).
Third, the text is obsolete because nobody cares about byte range consistency in subrange requests to HTTP/1.0 origin servers, because that was a theoretical concern in early 1996 and there are no longer any HTTP/1.0 origin servers that implement Range, nor would we care if people occasionally got funky spliced content in HTTP/1.0 responses just because more than one modification was made within the same timestamp.