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

Ticket #406 (closed design: fixed)

Opened 2 years ago

Last modified 21 months ago

304 without validator

Reported by: mnot@pobox.com Owned by: mnot@pobox.com
Priority: normal Milestone: 22
Component: p6-cache Severity: In WG Last Call
Keywords: Cc:
Origin: http://www.w3.org/mid/emba9537fd-77af-45fd-91b1-e42423af960e@bombed


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 <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1374/draft-ietf-httpbis/latest/p6-cache.xml#L1096>. Roy, what was your thinking here?

Change History

comment:1 Changed 2 years ago by fielding@gbiv.com

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 2 years ago by mnot@pobox.com

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 2 years ago by mnot@pobox.com

  • Owner changed from draft-ietf-httpbis-p6-cache@tools.ietf.org to mnot@pobox.com

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

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 2 years ago by fielding@gbiv.com

From [2093]:

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

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

[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 2 years ago by fielding@gbiv.com

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 2 years ago by mnot@pobox.com

From [2100]:

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

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

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

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

  • Milestone changed from unassigned to 22

comment:11 Changed 21 months ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:12 Changed 21 months ago by mnot@pobox.com

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