Opened 7 years ago

Closed 6 years ago

#350 closed design (fixed)

Optionality of Conditional Request Support

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

Description

Is p4 optional or not (for servers, clients, etc.)? I think it is, and so it should be explicitly marked as such.

E.g.,

  • 2.2.1 Generation - "Origin servers SHOULD send Last-Modified..." -- is this really a SHOULD, or should we just encourage them to? If p4 is optional, I don't think we can impose this as a SHOULD.
  • 2.3.1 Generation - "Origin servers SHOULD send ETag..." -- is this really a SHOULD, or should we just encourage them to? If p4 is optional, I don't think we can impose this as a SHOULD.
  • 2.4 Rules... - there are many requirements for servers and clients here; I think they need to be downgraded if p4 is indeed optional.

Change History (17)

comment:1 Changed 7 years ago by mnot@…

  • Milestone changed from unassigned to 20

Proposal: in Entity Tag Generation, add:

Origin servers that include ETags in responses for a resource MUST honour the If-Match precondition [ref] when sending a successful response to any subsequent unsafe requests, and ought to support it for subsequent safe requests.

... and likewise for Last-Modified / If-Unmodified-Since.

The one thing this doesn't catch is:

If-None-Match: *

because a client can send that to indicate that it only wants to PUT something (for example) when there's nothing already there (theoretically, If-Match: * is like this too).

This is a bit awkward; without this caveat, we could make p4 a self-contained optional extension (since LM and ETags are both defined here too).

Therefore, we should document this requirement in PUT's definition, and advise new methods to document whether they require it too.

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

I wouldn't want to hard-wire this to PUT... There are other methods for which this is desirable as well.

comment:3 Changed 7 years ago by mnot@…

Yes, but it's the only one that we define where it's a consideration.

Does make sense to add this to Considerations for New Methods...

comment:4 Changed 7 years ago by fielding@…

These are new requirements. Keep in mind that most servers send entity tags for the sole purpose of If-None-Match.

comment:5 Changed 7 years ago by mnot@…

Right, but a server that successfully handles a PUT on a resource that it previously generated an ETag for needs to handle the If-Match... if they don't handle PUT (e.g.,) they don't have to worry about this.

comment:6 Changed 7 years ago by fielding@…

I think it is a good idea, but they don't NEED to handle If-Match. HTTP doesn't require that lost updates be avoided. People can (and do) use optimistic concurrency and automatic revisions instead.

comment:7 Changed 7 years ago by mnot@…

SHOULD?

comment:8 Changed 7 years ago by fielding@…

What problem are we trying to solve? A resource that does not implement If-Match will not be able to protect against lost updates, but if the purpose of the resource is to show the latest state regardless of intervening edits then it doesn't want to protect against lost updates. Think anarchistic whiteboards during a social collaboration study.

comment:9 Changed 7 years ago by mnot@…

Um, right now we say (regarding If-Match):

Origin servers must not perform the requested method if the condition is not met; instead they must respond with the 412 (Precondition Failed) status code.

That requirement goes back at least to 2616.

All I'm trying to do is make that requirement obvious to people who it's placed upon; hiding it in the definition of If-Match doesn't do a lot of good to people who just look at ETags.

So, actually SHOULD doesn't work, as that contradicts the very clear MUST NOT we already have. This needs to be a MUST.

Regarding your whiteboard service -- use a GET-only resource to reflect latest state; or refuse the request if it has a conflicting if-match (tell them not to use if-match; sort of an anti-428).

comment:10 Changed 7 years ago by mnot@…

  • Milestone changed from 20 to unassigned

comment:11 Changed 7 years ago by fielding@…

Okay, looking back at 2068 and 2616, it seems that If-Match was designed for a MUST on the server if the server generates an entity-tag. I'll figure out a way to state that in p4.

comment:12 Changed 7 years ago by mnot@…

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

comment:13 Changed 6 years ago by fielding@…

From [2128]:

Define time of evaluation along with precedence; remove more duplicate and conflicting requirements revealed by the addition of 428 (Precondition Required); reduce requirements targeting entity-tag to facts; clarify that servers only need to send validators on successful retrieval responses; addresses #350 and #427

comment:14 Changed 6 years ago by fielding@…

From [2129]:

reduce requirements targeting entity-tag to facts; addresses #350

comment:15 Changed 6 years ago by fielding@…

  • Milestone changed from unassigned to 22
  • Resolution set to incorporated
  • Status changed from new to closed

The preconditions are apparently all required to implement, with If-Modified-Since being the only one containing a SHOULD (for sending 304). I have clarified with a MUST on evaluating.

comment:16 Changed 6 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:17 Changed 6 years ago by mnot@…

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