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

Lisa Dusseault wrote:

> On May 21, 2004, at 3:14 AM, Julian Reschke wrote:
> 
>> Comments on the latest draft:
>>
>> >    Note that byte ranges are already used in HTTP to do partial
>> >    downloads (GET method).  However, they are not defined for uploads,
>> >    and there are some missing pieces for uploads.  For example, the 
>> HTTP
>> >    specification has no way for the server to send errors if the byte
>> >    range in a PUT is invalid.  Byte ranges (or some other kind of 
>> range)
>>
>> The server could always send a 4xx status code. Am I missing something?
> 
> 
> Yes, the server could, but HTTP doesn't define this as a way to respond 
> to partial upload requests, so clients might find it hard to 
> interoperate well.  Anyway I think it's moot, unless we decide to design 

Sorry? Clients must expect a 4xx status code for every conceivable HTTP 
method.

> a partial upload request standard based around byte-range headers -- I 
> think sending a diff is far preferable since diff formats are already 
> well understood, used in HTTP, and more powerful.

Yes, but that wasn't the question. This is the rationale for defining a 
new method, and this particular given reason just is incorrect (at least 
I'm not understanding it). In doubt, just remove the statement.

>> I'm not sure how this is supposed to work. It may be an interesting 
>> feature, but to fully define it, the spec will need to say more about 
>> that topic (I personally feel that overloading COPY and/or MOVE with 
>> content modification operations would be a bad idea...).
> 
> 
> This is just pointing out that COPY and MOVE are useful -- this doesn't 
> overload them or even explain how this works.  COPY and MOVE are fully 
> defined in RFC2518 and are independent from PATCH.  The reason these are 
> mentioned, is because somebody asked if PATCH could be used to get the 
> source from one URL, but place the result in another URL -- and COPY or 
> MOVE combined with PATCH can achieve nearly the same thing without any 
> new specification required.  I will however try to make the text a 
> little clearer in that MOVE and COPY can be used as is, independently of 
> the PATCH proposal, to rename or copy an entity before applying PATCH to 
> it.

OK. I had the impression that you were planning to roll PATCH semantics 
into specific COPY/MOBE operations.

>> If one of the use cases for PATCH is creating sparse resources, it 
>> would make sense to allow PATCH to create new resources.
> 
> 
> I can't think of any benefit over using PUT.  It only makes PATCH more 

Creating sparse resources...

> complicated to define how it acts on new resources.  Note that the 
> client is perfectly capable of using PUT to create an empty resource, 
> and diff formats are perfectly capable of applying a diff to an empty 
> resource -- but I would think that generally clients would prefer to PUT 
> at least a significant chunk of the resource content when creating the 
> resource.

Agreed, that can be simulated by PUT (empty body) / then PATCH. In 
doubt, the spec should specify the simpler approach, though. I'm not 
sure that forbidding PATCH to unmapped URLs is indeed simpler...

>> 3. Thought: there may be servers without good ETag support (for 
>> instance when using filesystem-based backends). If we require the 
>> server to compute MD5 checksums, we can also require it to check the 
>> MD5 of the given entity *before* the modification. In WebDAV speak, 
>> that would be a new state token for the "If" header; however for a 
>> spec that doesn't require WebDAV as base protocol, we may have to 
>> define a new request header, such as "If-Content-MD5-Match". This 
>> would make PATCH extra-safe, and we wouldn't need to worry ETag support.
> 
> 
> This would be a great extension in general, completely independent of 
> PATCH, and I would support such an extension.

So should this be part of the PATCH spec?

>> I think this spec shouldn't use the "DAV:" namespace. Also, if this 
>> spec adopts RFC3253-style error handling, it should stay consistent 
>> with RFC3253 (in RFC3253, the names identify *conditions*, not 
>> *errors*; thus the individual codes need to be reversed, such as 
>> "delta-format-supported" instead of "delta-format-unsupported").
> 
> 
> I suppose we could define a new namespace just for PATCH; but you're the 
> only one who's mentioned this so I don't think it's likely to be much of 
> a problem.  Since error codes are simply identifying strings, I see no 
> problem with using identifying strings which make sense to the 
> reader/developer/debugger.

Could you please address the issue of this spec being inconsistent with 
RFC3253? *If* PATCH borrows mechanisms from RFC3253 (which I think is A 
Good Thing), it definitively should do that in a consistent way. If, as 
you say, it doesn't matter as we're only talking about identifiers for 
machine consumption, it's even less clear why you're changing the format 
here.

>> > 2.3  Delta Formats
>> >
>> >    A set of changes for a resource is itself a document, called a 
>> change
>> >    document or delta.  The delta format is uniquely identified through
>>
>> Make it a definition; and use the same term (I'd prefer "delta 
>> document") everywhere.
> 
> 
> A matter of readability; I think the draft is already pretty readable 
> here, because we're not defining any special meaning for the word, it's 
> already well used in other context.

Well, the spec text *sounds* as you're defining something here. I think 
it would make sense just to use *one* term and to stick with it.

>> >    The VCDIFF [5] format identifier is "vcdiff".  The GDIFF [6] format
>> >    identifier is "gdiff".  Servers SHOULD support VCDIFF for all static
>> >    resources.
>>
>> What's the relation of the aforementioned identifiers and the MIME 
>> type? And what is a "static" resource?
> 
> 
> Clarified.  I'll change "static" to "resources with static content, that 
> is, content that is not generated dynamically."  This brings the text in 
> line with the wording used in RFC2616.

I can't find the term "static" in RFC2616... It's also not clear how 
"generated dynamically" affects the ability to use a specific PATCH 
format. Assuming that PATCH will only work for authorable resources 
(those you can PUT to), could you please explain which of the set of 
these resources you're trying to exclude?


>> Shouldn't "vcdiff" appear here?
> 
> 
> I'm of two minds about this.  It might be undesirable for servers to 
> support 'vcdiff' if they support something that's better in this 
> particular circumstance.  I guess it's better for the example to show 
> what you'd see if the server followed every SHOULD.

Certainly. If you don't mean "SHOULD", don't make it a "SHOULD".

>> >    [6]  van Hoff, A. and J. Payne, "Generic Diff Format Specification",
>> >         August 1997.
>>
>> URL?
> 
> 
> It's funny -- it's in the XML source, but the generator didn't see fit 
> to put the URL in the text output.  I guess that URLs are just not 
> required in the text version.

Depends on how you put it into the XML source. If you send me the XML 
version (or just the reference), I'll figure out how to fix that.


Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 21 May 2004 16:29:17 UTC