Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of If-Unmodified-Since with unknown modified dates #326

Closed
evert opened this issue Mar 7, 2020 · 2 comments · Fixed by #348
Closed

Handling of If-Unmodified-Since with unknown modified dates #326

evert opened this issue Mar 7, 2020 · 2 comments · Fixed by #348

Comments

@evert
Copy link

evert commented Mar 7, 2020

I'm working on a new implementation of conditionals, and I'm a little confused about If-Unmodified-Since.

What should a server do if a client passed an If-Unmodified-Since header, but the target resource does not know its own modification date?

My intuition is that without a Last-Modified header, we should assume that the request is always fresh, and given that If-Unmodified-Since is used to protect against the 'lost update' problem, we should default to returning 412 if the last modification date could not be determined.

I don't think the current draft covers this case, but perhaps I've missed something.

@mnot mnot added the semantics label Mar 20, 2020
@mnot
Copy link
Member

mnot commented Mar 20, 2020

It's a fair question.

I think we should explicitly state that an origin server can ignore this header if the resource does not have a concept of modification time.

Furthermore, I suspect that I-U-S should change this requirement:

An origin server that receives an If-Unmodified-Since header field must evaluate the condition prior to performing the method (Section 8.2.1).

to something like:

An origin server that receives an If-Unmodified-Since header field must evaluate the condition (Section 8.2.1) prior to performing an unsafe method (Section 7.2.1).

@mnot
Copy link
Member

mnot commented Apr 27, 2020

Hm. In Evaluation, we say:

Likewise, a server &MUST; ignore the conditional request header fields
defined by this specification when received with a request method that does
not involve the selection or modification of a
<x:ref>selected representation</x:ref>, such as CONNECT, OPTIONS, or TRACE.

It seems like we need to reference that if we're placing requirements around methods later on.

(now #358)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants