Re: Looking for comments on the HTTP Extension draft

<Yaron, do you dream in XML?>

Lo, Yaron spake thusly:
> I suspect we all can also agree that this mechanism must work with HTTP/1.0
> and HTTP/1.1. The tools available to achieve this goal are:

If I'm willing to rev the protocol number, obviously I don't believe
that this mechanism must be one which fits in the 1.x framework.  A
really good extension mechanism that had to have one incompatible
change would be fine by me.  Once this extension mechanism takes
off, there will be no more major or minor protocol number changes,
only extensions.  One big change to note that shift isn't that hard
is it?  It's not as if all of the old clients out there are going
to become extension aware anyway.

> Servers/firewalls/proxies which do understand the mechanism also understand
> that they can infer nothing from the method name without having first
> checked the mandatory prefix. I agree that this is a significantly
> sub-optimal solution. Additionally, when processing the method one needs to
> first find out if there is a mandatory header so one can find the prefix
> translation and thus "decode" the HTTP headers, an equally sub-optimal
> solution.

Sub-optimal is certainly nice phrasing.  In large-scale production
environments, I would bet it would be sub-optimal enough to be
described as "broken" or "very expensive".  The need for more review
by those designing firewalls, proxies, and the like is a persistent
refrain in this little exchange, but let's let it run through our
minds one more time.


> <Our weapons are fear, uncertainty and doubt>
> The "a priori" language was added at my insistence. The reason being that
> previously the standard allowed for the return of mandatory headers on
> responses without the client having first identified to the server that it
> could understand the mandatory extensions. The spec had some vague language
> about what a client was supposed to do when it got an unrecognized Mandatory
> extension on a response. I felt the language was absolutely unacceptable and
> demanded, without exception, that a client MUST have somehow expressed to
> the server that it understands a particular mandatory extension before the
> server is allowed to use that extension on a response. I did not, however,
> demand an actual specification of what "a priori" meant because I recognize
> that such a definition was futile. Given that the very nature of a mandatory
> extension means that extension specific code has been added to the
> client/server I believe it is in our interest to retain maximum flexibility
> in defining how client signaling of support is accomplished.
> </Our weapons are fear, uncertainty and doubt>

I prefer "fear, surprise, and a ruthless and fanatical devotion to
interoperability."

I think you saw the right problem, but I don't think your demands
weren't quite met.  "a client MUST have somehow expressed to the
server that it understands a particular mandatory extension before the
server is allowed to use that extension on a response" is great principle,
and one I wish this spec followed.  The spec describes a way for the
client to indicate it understands a particular mandatory extension, but it
doesn't *require* that the server wait for that indication; it allows
the server to send it based on "a priori" knowledge.  As I said in
my mail to Larry, anything outside of the protocol-defined indication
is a guess, and if you are going to allow guessing, you have some problems
to solve that this doesn't solve.  

> <It's a feature!>
> Absolutely true! Nor is there any implication in the draft that an
> administrator could do so. In fact I assume our readers are just as smart as
> you are and will, as you did, figure out that for their firewall to have any
> chance of parsing the method they MUST parse the mandatory header itself,
> see if they recognize the extension and if they do then and only then do
> they have sufficient information to deal with the method. Otherwise the
> firewall must treat the method as any other method it knows absolutely
> nothing about. The beauty of mandatory is that this is what a firewall which
> knows nothing about mandatory, much less the enhanced method, will do with a
> mandatory request. Everything just works. However a note about this in the
> security section is probably appropriate.
> </It's a feature!>

The document seems to me to imply to security folk "that if you allow
'GET' you ought to allow 'M-GET'.  If the authors agree with your
interpretation, wordsmithing in the security section might fix the
problem.  Other changes in the way the document describes methods
might also be needed, but that would be wordsmithing rather than a
design change.


> 2) I trust the market a hell of a lot more than I trust some text in a
> standards document. If people choose to use someone's extension and that
> person does not properly maintain their extension then people will stop
> using that extension. No "MUST" in a standard can change that one way or
> another. I think the language is actually quite clear and well written. I
> disagree that any word smithing is necessary.

Will manufacturers willingly give different URLs to different patch
releases of a product, when the URLs are being used as *tokens* in a
system like this?  Remember,
"http://www.bigcompany.com/products/foo/v1" and
"http://www.bigcompany.com/products/foo/v2" are completely different;
there is no defined relationship and no way to presume if you do one
you can do the other.  Especially, there is no way for a proxy to know
whether allowing one through implies *anything* about letting the
other through.  Hint: I have had systems in which all had the same
product, with the same identifier, but a substantial percentage did
not interoperate because of a patch release mis-match.  Trust the
market all you like, but make damn sure that implementors understand
the consequences of not doing the right way; "strongly recommended"
doesn't say "fail to do this and die horribly, unspeakable rascal"
to me, and I suspect it ought to.


> <Ohhhhhh Ted..... I love it when your brutal!>
> Sigh... I have to agree. December is a lousy month to try to perform a
> review. Half the necessary people are gone and the rest are too busy to deal
> with it.
> </Ohhhhhh Ted..... I love it when your brutal!>

Hmm, if half the people necessary people are gone, and the rest are too busy,
those actually performing the review are...sorry, didn't mean to go there.

> <Nobody here but us Chickens>
> Ohh goodie... Henrik can commit a double homicide. I just love company. =)
> </Nobody here but us Chickens>


</Yaron, do you dream in XML?>


		regards,
			Ted Hardie
			hardie@equinix.com

Received on Monday, 28 December 1998 17:59:54 UTC