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

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 UTC