Re: Looking for comments on the HTTP Extension draft

Yaron,

Needless to say, I don't really want to argue for incompatible
upgrades.  I do want us to be very, very sure that we balance
extensibility and interoperability.  My first message and my responses
since are my feeble attempts to delineate where I believe this
proposal runs the risk of sacrificing interoperability, by the use of
certain behaviors which are either not current practice in HTTP 1.x or
not current expectations for URLs.

Revving the protocol number makes sure everybody knows about the new
rules.  As I've said before, I don't think it is the only possible way
to ensure that.  I don't really even think it's the best.  Thinking
about it in those terms, though, may be what it takes to get us to the
right design choices.

On the issue of "a priori" knowledge, this design allows a client to
send a vanilla request like:

GET /someresource.foo HTTP/1.1
Host: www.foobar.nl
User-Agent: Diva 98.2

and have the server derive from some information (which URL was
chosen, the User-Agent, whatever) that the client *could* support an
extended response.  That "a priori" knowledge is based on assumptions
(that the client has not turned off the capability, that the firewall
isn't configure to stop that, that the URL wasn't typed in from a
friend's bookmarks, whatever).  If those assumptions are wrong, a
response is sent that the client cannot handle properly and may not be
able to handle at all.  In the extensible world that has been
described, we have to acknowledge that capabilities change over
time--sometimes resulting in the removal of capabilities.  You can't
even rely on my previously stated support, as I may support FOOBAZ
today and give it up tomorrow when it interferes with my
mission-critical BARFUZZ extension.  Our lives and the lives of our
customers would be easier if we stuck to the idea you set forth and
only used FOOBAZ in a response when the client volunteered that it was
willing to use it in the request.

On the issue of multiple versions behind a single URL, this is,
indeed, like the dll hell you describe.  If we cannot solve the problem
in the standard, we can at least point others where that road leads so
that they don't take us down it too often.

		regards,
			Ted Hardie
			hardie@equinix.com

Received on Monday, 28 December 1998 20:46:05 UTC