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

Re: Patch options -- summary of recent conversations

From: Jamie Lokier <jamie@shareable.org>
Date: Sun, 12 Aug 2007 19:51:39 +0100
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Lisa Dusseault <lisa@osafoundation.org>, James M Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20070812185139.GA20717@mail.shareable.org>

Julian Reschke wrote:
> >>But at least OPTIONS/Allow will tell us whether the server has any idea 
> >>what PATCH is, right?
> >
> >If you're lucky.  If you're not lucky, the server will treat OPTIONS
> >like GET or POST, or something else.
> 
> In which case it won't return "Allow: PATCH", right?

That's right, but it may have unwanted side effects similar to POST,
so you shouldn't use OPTIONS indiscriminately.

Then again, you shouldn't be trying to PATCH a resource you don't know
is patchable anyway.

My point is if you don't know it's patchable, you shouldn't be trying
PATCH _or_ OPTIONS on it.

If you do know it's patchable, then using PATCH as a verb, or the
suggested alternative POST with Content-Type: application/patch seem
equally usable.  PATCH is more in keeping with the rest of HTTP (PUT,
DELETE etc.)

It's been suggested than PATCH will have problems with some
intermediaries.  But PUT etc. also has problems with intermediaries
(probably the same ones), and I imagine most uses of PATCH expect PUT
to work as well.  This is an argument in favour of PATCH as a verb.

-- Jamie
Received on Sunday, 12 August 2007 18:51:52 GMT

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