W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: #350: WGLC Issue for p4: Optionality of Conditional Request Support

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 16 Jul 2012 16:05:13 +1000
Message-Id: <DAC98E13-8161-4F12-BFF7-E164EC53B419@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
I haven't heard anything else about this, so I've marked the proposal below for incorporation.


On 05/07/2012, at 1:00 PM, Mark Nottingham wrote:

> 
> 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/
> 
> 
> 
> 

--
Mark Nottingham
http://www.mnot.net/
Received on Monday, 16 July 2012 06:05:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 16 July 2012 06:05:52 GMT