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