Re: [hybi] #1: HTTP Compliance

[Greg Wilkins <[e-mail]>]

On 17/05/10 12:35, Maciej Stachowiak wrote:

> True. If someone comes up with a proposal to solve the same problem 
> in a way that doesn't technically violate HTTP, that would be great,
> and we can consider it.

I have given several such proposals.

The simplest was just to leave out the random bytes after the handshake
request, but to include them after the handshake response.

This is compliant and will still test if intermediaries forward non-HTTP
content.

There is no extra RTT over the current handshake as the client already
cannot send any messages until the bytes after the 101 are received


> I can see how the idea of HTTP compliance should be a preference, but 
> I don't see how it can be a hard requirement, if it turns out that we
> can make the protocol work better only by violating.

When operating in a standards based environment, the assumption should
be that standards are respected.

If there is a reason to violate the self evident truth that messages
should be HTTP on a HTTP connection, then I think those that
want to violate should make the case that violation is needed.

Then effort should be expended to see of the violated standard
can be improved.

Only then should a violation of an established standard be
contemplated... and then it would have to be for a very very
good reason and I'm not sure that an imperfect fast fail
mechanism is such a good reason.

Regardless, it should be the violators obligation to make
their case.

It should not be necessary for those that wish to respect
and existing standard to defend the need to respect it.
Unfortunately this is what is occurring because the
editor has included a mechanism in the draft that
did not have consensus.


regards