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

Re: I-D ACTION:draft-dusseault-http-patch-05.txt

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 2 Sep 2004 10:20:02 -0700
Message-Id: <5302A117-FD04-11D8-A023-000A95BD86C0@mnot.net>
Cc: HTTP working group <ietf-http-wg@w3.org>, Webdav WG <w3c-dist-auth@w3c.org>
To: Lisa Dusseault <lisa@osafoundation.org>

Thanks for the quick answers! A couple of responses below.

On Sep 2, 2004, at 10:01 AM, Lisa Dusseault wrote:

>> * 3.1 "A cache MAY mark the resource identified in the Request-URI as 
>> stale if it sees a successful response to the PATCH request." First 
>> of all, a minor nit; I think this should be "A cache MAY mark 
>> entities associated with the resource identified..." Secondly, I'm 
>> uncomfortable with the MAY here; is there any reason it isn't a 
>> stronger requirement, if the cache is PATCH-aware? RFC2616 section 
>> 13.10 sets the bar at SHOULD.
>
> I don't think that would really help or matter, as I don't expect 
> caches to be PATCH-aware.

Typically not, but I can imagine people building PATCH-aware 
intermediaries that did some caching. It's not a big deal, I was just 
curious if there was any particular reason behind the (trival) 
inconsistency with 2616.


>> * How does PATCH interact with server-driven content negotiation? I 
>> might expect that if I PATCH something with an Accept header that was 
>> sufficiently specific, I'd be patching that particular 
>> representation.
>
> An interesting thought, but authoring variants is so underspecified at 
> this time that anything I could describe in PATCH would probably get 
> in the way.

Understood. Would it be helpful to state "The interaction between PATCH 
and server-driven content negotiation is not defined by this 
specification."?


>> * 3.3 "OPTIONS * is not used to advertise support for PATCH because 
>> the patch formats supported..." From context, it seems that you want 
>> to say that OPTIONS * shouldn't return an Accept-Patch header. 
>> However, the text above could be read as saying that OPTIONS * 
>> shouldn't return PATCH in the Allow header. I'd suggest something 
>> like "OPTIONS * is not used to advertise support for patch formats, 
>> because those supported are likely to change from one resource to 
>> another."
>
> This is a really tricky issue and has already been discussed on the 
> list, with one outcome possibly that the next update to HTTP should 
> clarify what OPTIONS * is all about.  The text is supposed to warn 
> clients that a server might, or might not, include PATCH in the Allow 
> header in response to OPTIONS *.  My intent is that clients will not 
> rely on OPTIONS * to find out if PATCH is supported because in 
> practice clients can't rely on OPTIONS * for extension discovery.

OK. My first reading of it was that servers shouldn't send Allow: PATCH 
in response to OPTIONS *. Maybe start the sentence with "Some servers 
may not advertise support for PATCH in response to an OPTIONS * request 
because..." ? Just a thought.


>> * PATCH's safety and idempotency should be clearly specified.
>
> I believe this depends on the patch format used.  I am not certain 
> what the idempotency of 'gdiff' is, for example.

If that's the case, I'd think that PATCH should be, by default, 
non-idempotent (in the same way that a sequence of POSTs on some 
particular resources might be idempotent, even when the method itself 
is not).

> As for safety, the document does discuss (in security considerations) 
> the risk that PATCH could corrupt a file and what safeguards are 
> suggested to avoid this.

Yes, but it should also use the language defined in RFC2616, so people 
can relate its operation to the concepts defined there.


Cheers,

--
Mark Nottingham     http://www.mnot.net/
Received on Thursday, 2 September 2004 17:20:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:35 GMT