- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 5 Jul 2012 13:00:03 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Roy Fielding <fielding@gbiv.com>, "Julian F. Reschke" <julian.reschke@gmx.de>
On 25/06/2012, at 1:48 PM, Mark Nottingham wrote: >> >> 3. Precondition Header Fields >> >> This section defines the syntax and semantics of HTTP/1.1 header >> fields for applying preconditions on requests. <new>If an origin server >> supplies a Validator for a resources, the origin server MUST support the >> corresponding conditionals.</new> > > That looks reasonable, but I think it'd be clearer if this were stated in the sections that define the validators. E.g., in <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p4-conditional.html#entity.tag.generation>, add: > > """ > Origin servers that generate ETags for a resource MUST support the If-Match precondition [ref] on all subsequent unsafe requests to that resource, and SHOULD support it for subsequent safe requests. > """ > > ... and likewise for Last-Modified / If-Unmodified-Since. Thoughts? A slight refinement. """ 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). My inclination here is to document this requirement in PUTs definition, and advise new methods to document whether they require it too. Thoughts? -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 5 July 2012 03:00:31 UTC