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

Ticket #350 (closed design: fixed)

Opened 3 years ago

Last modified 18 months ago

Optionality of Conditional Request Support

Reported by: mnot@pobox.com Owned by: fielding@gbiv.com
Priority: normal Milestone: 22
Component: p4-conditional Severity: In WG Last Call
Keywords: Cc:
Origin: http://www.w3.org/mid/A773CD55-8438-4ED6-9926-F34922E5217F@mnot.net

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

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

  • 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 2 years ago by julian.reschke@gmx.de

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

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

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

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

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

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

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

SHOULD?

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

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

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

  • Milestone changed from 20 to unassigned

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

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 23 months ago by mnot@pobox.com

  • Owner changed from draft-ietf-httpbis-p4-conditional@tools.ietf.org to fielding@gbiv.com

comment:13 Changed 21 months ago by fielding@gbiv.com

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 21 months ago by fielding@gbiv.com

From [2129]:

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

comment:15 Changed 21 months ago by fielding@gbiv.com

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

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 18 months ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:17 Changed 18 months ago by mnot@pobox.com

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