Opened 10 years ago

Closed 9 years ago

#406 closed design (fixed)

304 without validator

Reported by: mnot@… Owned by: mnot@…
Priority: normal Milestone: 22
Component: p6-cache Severity: In WG Last Call
Keywords: Cc:


in 4.2.1,

"If the new response does not include any form of validator, there is only one stored response, and that stored response also lacks a validator, then that stored response is selected."

But how can a server logically reply with 304 without a validator?

A server can only reply with 304 if the request was conditional. For a request to be conditional, there must be a validator supplied with the request. But in this case the stored response had no validator. So where did the validator come from?

Does this mean that it's compliant behaviour to make a conditional request with data that wasn't in the stored response? E.g. have a cache invent an If-Modified-Since based on something else (e.g. Date)? Presumably a cache can't invent an ETag where there was none. Also, 4.2 para 2 states the If-Modified-Since comes from Last-Modified and doesn't imply it can come from elsewhere.

My initial reaction is to consider a 304 without validator to be a server bug.


This text was introduced by Roy in <>. Roy, what was your thinking here?

Change History (12)

comment:1 Changed 10 years ago by fielding@…

Hmm, looks like a bug. I was trying to cover all the cases, including those wherein the 304 is in response to a validator requested by an upstream cache (i.e., the cache in question here is not the one that decided to send a conditional request). The cache that sent the conditional request should map it to the stored response for which the conditional was requested. Maybe we need to split that into two lists.

comment:2 Changed 10 years ago by mnot@…

Not sure I understand. If the local (not upstream) cache misses and goes forward, it doesn't have a fresh response to use; if the origin decides to send a response without any validator, how can the local cache select a response? Shouldn't it just forward the 304?

What would the nature of the two lists be?

comment:3 Changed 10 years ago by mnot@…

  • Owner changed from draft-ietf-httpbis-p6-cache@… to mnot@…

comment:4 Changed 9 years ago by fielding@…

Actually, that wasn't the case I was looking for ...

It is not required that a server send a validator in a 304 response. In fact, the 304 definition doesn't even include Last-Modified in the headers to send.

Regardless, a client can make an If-Modified-Since conditional request based on any timestamp, including its own clock or the value of the Date header field of the cached response, and the origin server can respond to that request with a 304 if it knows that the representation has not been modified since that time on its own clock, even if it never sends LM or ETAG in 200 responses. MOMspider made requests like that.

Do we need to explain why, or can this be closed as wontfix?

I just noticed that my change to target requirements in 304 has changed a requirement on caches to a requirement on recipients ... I will fix that.

comment:5 Changed 9 years ago by fielding@…

From [2093]:

delegate cache requirements from 304 to p6; related to #406

comment:6 Changed 9 years ago by mnot@…

[2093] looks OK. In the text just above that edit:

If a 200 (OK) response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, Expires, or Vary, then the sender must generate those same header fields in a 304 response.

I think should be something like:

If a 200 (OK) response to the same request would have included any of the header fields [...], the server generating the 304 response MUST send those same header fields in it.

(because not all senders in the chain will be generating them)

Regarding the case where a response doesn't have a validator -- I think we should mention it, because I've seen it cause bugs in the past (it's surprising to server-side folks, who assume they'll never see a IMS if they don't send a LM, but last I checked Safari does this).

I see that p4's definition already alludes to this in a note. It might be worth spelling out in prose above the notes, e.g.,

Typically, the value of the Last-Modified header received in a previous response is used to generate the value of an If-Modified-Since header. However, clients can generate them even when Last-Modified is not available.

In p6, I think we need to clarify that the list of options there is first-match-wins, and very briefly motivate the last bullet.

I'll take the p6 changes, you do p4?

comment:7 Changed 9 years ago by fielding@…

From [2099]:

(editorial) Explain the other purpose of If-Modified-Since and why its value might not be from a Last-Modified date; addresses #406

comment:8 Changed 9 years ago by mnot@…

From [2100]:

Clarify rules for 304 updates, motivate last point; addresses #406

comment:9 Changed 9 years ago by mnot@…

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

comment:10 Changed 9 years ago by mnot@…

  • Milestone changed from unassigned to 22

comment:11 Changed 9 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:12 Changed 9 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.