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: Tue, 7 Aug 2007 13:50:45 +0100
To: Adrien de Croy <adrien@qbik.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20070807125045.GC22464@mail.shareable.org>

Adrien de Croy wrote:
> since I write a proxy, I'm biased towards proxies, but every time a 
> method is added to HTTP, we eventually get requests to support it.

Why don't you support all unknown methods already?  RFC2616 is quite
clear that proxies shouldn't need to be changed as new methods are
deployed.

If you are filtering to allow only particular methods, you should at
least have the option on some configuration screen of your device to
add new permitted methods by name, right?

> But there are zillions of deployed hardware-based HTTP gateways that 
> don't get firmware updates.  These will be broken for any new methods 
> until they are replaced.  Many of these intercept connections as well :)

Again, why are they broken?  Is it just policy-based filtering?

> A layered approach might be a better solution to implementing new 
> higher-level applications.  One that doesn't invalidate deployed 
> servers, gateways etc.
> 
> e.g. use HTTP for the transport only, not the higher-level application 
> layer.  It would solve a lot of compatibility issues for proxy and 
> gateway vendors, reduce obsolescence and generally improve customer 
> return on investment.  Furthermore it would restrict the scope of 
> changes required for any functionality to only those parties involved 
> (i.e. specific servers and clients) rather than all intervening HTTP 
> infrastructure as well.

How is "application vs. HTTP" any different from "application vs. TCP"?

People are writing applications that run over HTTP as transport (and
hackily; see server-push AJAX) because general TCP/IP is not available
to them for infrastructure reasons.  In effect, there's firewalls and
NATs and application limitations (e.g. it must run in a browser) all
over the place which limit the available transport to HTTP over
TCP/IP.

10 years ago, it was more like TCP/IP was everywhere.  Applications
could use that as a near universal transport.

In 10 years time, won't we see exactly the same infrastructure problem
repeated with something-over-HTTP, just moved up a level?

Perhaps it's inevitable.

-- Jamie
Received on Tuesday, 7 August 2007 12:50:59 GMT

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