Re: PATCH thoughts...

Only partial answers inline...

On Apr 28, 2004, at 3:40 PM, Alex Rousskov wrote:

> On Wed, 28 Apr 2004, Lisa Dusseault wrote:
>
>> Would it solve all these use cases if we provided a "Source: <url>"
>> header?
>
> Would Content-Location header be appropriate for this purpose?
>
>    The Content-Location entity-header field MAY be used to supply the
>    resource location for the entity enclosed in the message when that
>    entity is accessible from a location separate from the requested
>    resource's URI.

I don't think so -- that implies something different.  Could be 
confusing.  In this case we're thinking of providing a URL that isn't 
the resource location for the enclosed entity.

>
>> The job of the server is then to take the Source resource, apply the
>> patch body, and save it at the destination (the request URI).  I'd
>> probably define this so that if the Source header were missing, then
>> the Request URI is both the source and the destination.
>
> Sounds like a too complicated task for a web server, especially if
> source URI points to a different server. Also opens a nice door for
> "outsourcing" DoS attacks. If a server supports patching "local"
> objects only, how can it indicate that?

Agreed, I'd propose only supporting local resources as a MUST or 
SHOULD, and define an error whenever the server didnt' want to follow 
the link to the source.

>
>> Would anybody else find this useful?
>
> It would be nice to see a real use case for that feature.
>
>> Bear in mind that I'm not trying to solve all use cases.  Narrow use
>> cases are a great thing to actually make progress and get to standard.
>> This may be one of the situations where it's pretty safe to extend the
>> use cases and functionality but we'll see.
>
> For a given scope, starting with a minimal but extendible
> functionality is ideal, of course. IMHO, if you think Source URI or
> equivalent feature can be added to your core PATCH protocol without
> core modifications, then do not add it. Let others document that
> extension when/if needed! If core modifications are required, then it
> becomes a question of either protocol scope or protocol extensibility.

It can't be added without core modifications, unfortunately -- it is a 
required-to-understand header, otherwise the server would ignore it and 
do something the client didn't want to do.  Unless there's a 
"mandatory" flag for headers that's actually widely supported that I'm 
unaware of.

>
> Alex.
>
>
>> On Apr 28, 2004, at 2:45 PM, Justin Chapweske wrote:
>>
>>> o I'm concerned that the provided use cases for PATCH is a bit too
>>> narrow and the system may not be flexible enough to encompass
>>> future use cases.
>>>
>>> For example, it may be desirable to create a new file that is the
>>> combination of the PATCH request body and a totally different
>>> resource, rather than patching a file in place.
>>>
>>> Another possible use case is that it may be desirable to have the
>>> patch body retrieved from a third-party URI rather than embedded
>>> directly in the request.
>>>
>>> Of course, at a quick blush you could simply say that these cases
>>> are out of scope.  But, I think it is worth thinking deeper about
>>> the problem space to see if an even more generic solution doesn't
>>> arise.

Received on Wednesday, 28 April 2004 18:49:13 UTC