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

Re: New issue: Need for an HTTP request method registry

From: Jamie Lokier <jamie@shareable.org>
Date: Thu, 9 Aug 2007 14:11:58 +0100
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Adrien de Croy <adrien@qbik.com>, Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20070809131158.GE25240@mail.shareable.org>

Lisa Dusseault wrote:
>    +1.   I've  never  understood  why, in the worst case, an intermediary
>    couldn't  have a configuration file or admin UI that allowed humans to
>    add  or  remove  whitelisted  or  blacklisted  method names.  It seems
>    extraordinarily  backwards,  especially  nearly  10 years after WebDAV
>    first  appeared on the 'Net, to require software updates to handle new
>    methods!

+1.  It seems pretty broken to me.

However, even when intermediaries _are_ configurable, organisational
difficulties can make it hard to deploy applications that need new

For example, someone may access a web server, and it works fine, and
then they try connecting to the same place using a WebDAV authoring
tool, and it just breaks, while it works fine for someone else in the

It may be quite difficult to locate and reconfigure all the
intermediaries which are filtering the methods.  Particularly as most
applications over the same route and protocol work fine, and
especially if the intermediary's response is to just close the
connection.  And it may be impossible for the server admins or the
users to do the changes.

Unfortunately, using anything other than GET/POST in HTTP is one of
those things which changes the infrastructure from "always works or
doesn't work" to "works for some applications and not others".  There
is hardly any use, by most users, other than GET/POST.  So it all
seems to work, infrastructure maintainers are happy, then one new
application doesn't work properly, and it's a challenge to debug
because it's relatively obscure protocol usage.

TCP/IP (and IP generally) suffered a similar problem when ECN,
Explicit Congestion Notification, was added.  Some routers blocked all
IP packets with those bits set, as a precaution.  They were called
"reserved" and should have been ignored, but the routers were cautious
because you never know if a node inside a protected network will behave
reasonably on seeing those bits.

It took many years before it was possible to deploy this standard IETF
feature on public-facing servers, entirely because of this router
filtering, and I'm still not sure how many users won't be able to
access a server that does.

-- Jamie
Received on Thursday, 9 August 2007 15:03:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC