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

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/350>

Hi Ray,

On 07/04/2012, at 5:47 AM, Ray Polk wrote:

> Have you had the chance to propose some prose for this ticket?  If not, was this approximately what you were thinking?

I've been thinking about it more recently (sorry for the long delay).

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


> I also had further concerns in this area.  I think the Conditional decision tree looks sort of like this:
> 
> Origin Server SHOULD generate Validators
> --> UA MAY use Conditionals corresponding to the Validators
> --> Origin Server MUST respect Conditionals
> 
> Since the UA only MAY use the conditionals, what should the Origin Server do if the UA doesn't supply a conditional?  For safe methods, it's no big deal.  However, for PUT & DELETE, I can see a case for UA MUST use the conditional.  So does this make sense?

We can't retroactively require it, but we did recently define something that allows the origin to express this: <http://tools.ietf.org/html/rfc6585#section-3>


> 3.1.  If-Match
> 
> The "If-Match" header field MAY be used to make a <new>safe</new>
> request method conditional <new>and MUST be used to make an unsafe
> request method conditional</new> on the current existence or value
> of an entity-tag for one or more representations of the target resource.

Pending discussion above, yes.


> Continuing the theme of Conditionals and method properties -- In last week's F2F discussion, there was some further discussion on the topic of conditional requests and PATCH.  Is the following assertion true?
> 
> Some Non-idempotent methods (e.g. PATCH) may be considered idempotent when the appropriate Conditional is applied (e.g. If-Match).

Hmm. Certainly, some non-idempotent methods are sometimes actually idempotent; consider some uses of POST, for example. However, from a visibility standpoint, it's all in the method.


> Finally, how do Validators & Conditionals interact with POST?

Just as any other method would; i.e., if the resource has a representation (obtained by GET), the validators obtained therein can be used to make POST requests pre-conditional.

Cheers,


--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 25 June 2012 03:48:42 UTC