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 15:52:18 +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: <20070812145218.GA17169@mail.shareable.org>

Julian Reschke wrote:
> >>If the server advertises its support for this Content-Type somewhere,  
> >>I could imagine this being sufficiently reliable.  I'm still a little  
> >>worried that the server might respond successfully to a POST request  
> >>without treating it as the client desires -- e.g. adding the request  
> >>entity to an Atom collection, submitting it to a HTTP "drop-box",  
> >>treating it as an alternative body for the resource, or one of the  
> >>many things POST might already be used for out there.
> >
> >Quite a few resources out there will respond to PATCH by doing those
> >things anyway.  I've seen quite a few CGI scripts and libraries which
> >will respond to all requests as though they are POST, unless they are
> >GET/HEAD.
> >
> >So you always have to know a bit about which resource you're PATCHing
> >or POSTing.
> 
> 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.

For example, as far as I can tell, any Perl CGI script which uses the
standard CGI.pm Perl module will probably treat OPTIONS as though it
is a GET request but ignore the query part of the URL.

Perhaps it's not a problem: you'll get a response with no Allow
header.

That's because it has some bits of code which compare method against
'POST', and some bits which compare against 'GET|HEAD'.  Yes it's poor
programming, but it's widely deployed - it's the standard way to do
Perl CGI, and also Apache with mod_perl, if you're not using some
other framework.

I've seen other (non-Perl) code which similarly assumes it is always
called with GET/HEAD/POST, and effectively defaults to one of them if
another method is used.

That includes the OPTIONS method.  So it might be unwise to depend on
OPTIONS without at least _some_ out of band knowledge that it's safe
to use on a particular resource.

-- Jamie
Received on Sunday, 12 August 2007 14:52:28 GMT

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