Re: PATCH thoughts...

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.

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

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

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:43:28 UTC