> Shelby,
>
>
> The concerns I've mostly seen discussed is for an intermediary to pass
> the handshakes, but then not forward arbitrary data.
>
> However,I guess it is possible for a really stupid proxy to inject
> "HTTP headers" or similar into a websocket stream and corrupt data,
> specially if the data looked like a HTTP message.    Perhaps that is
> an argument for a simple checksum in the framing mechanism (previously
> suggested and rejected because we are not trying to fix problems with
> TCP/IP - but this is a different use-case).
>
> cheers

I am not stating that will happen or at any significant frequency, I am
asking if it could be a problem? Why is the data currently limited to
UTF8?

Until evidence or expert experience is stated otherwise, my "Murphy's Law"
(entropy) intuition is that if we inject clear (not encrypted) text data
into HTTP channels, whose primary reason for existing is to be an
orgy/feast of filtering (refering to the security discussion today between
Willy and myself in this thread and the HTTP Compliance), that does not
look and act like HTTP that those networks have seen, then we are
prefering to risk a can-of-worms (indeterminacy). Although HTTP Upgrade is
part of the specification (since 1.1?), am I correct to understand (from a
comment made in this list's archives) that it has never been successfully
deployed to any significant scale?

And to the extent the above is a real issue, I had mentioned before in
other thread that I would also be ask if there is a possibility that
messages will silently fail to be delivered, so in that case TCP is not
working as expected because it is not a failure-to-deliver to the network
nodes, but rather a failure to forward data by the silent transparent
proxy. So if so, then you need handshaking because the receiver doesn't
know when data was sent. I had suggested that such handshaking could be
accomplished (with least bandwidth wasted) in messages received and in
keep-alive pings. But the more I think about it, if proxies might not
forward data and we want to assume we have the behavior of normal TCP
without proxies, then we will need to handshake on each sent message,
which means latency advantage is destroyed! That is major point, if true.
If proxies can eat the checksums (hashes), TCP efficiency is lost.

This is why I am arguing in this thread for a clean break to a specific
port+tunneling (aka WS/P+T), because it will give us a true TCP
semantics+efficiency (after the tunnel succeeds) and the only issues not
TCP recoverable will occur as a hard fail of the tunnel handshake, which
is cacheable result (time cost) because can only occur once per tuple
(client, server, DCHP lease, etc).

Ian Hickson wrote more than once last year in this list's archives "443 is
the interesting case", so I assume/deduce he had already worked through
the above in his mind, and realized that WS/HTTP is really a can-of-worms
if we can't get a hard fail at handshake for all non-compliant proxies. I
think perhaps this is why he was so focused on minimizing "false
positives" and why he made the comment that the failure of reverse proxies
for proposal 76 was "a success".

So that is why I say our good choices may be between WS/TLS and WS/P+T, so
I proposed a fall back suite: WS/P+T -> WS/TLS -> Comet/BOSH (or leave
this to the application to decide).

I assume there are many details that need to be discussed (or re-iterated
from prior discussion) to get a more objective understanding of this
issue.  I am not satisfied or confident enough to say I have sufficient
understanding of the facts, to argue that what I wrote about is anything
other than a set of concerns and questions.

I am hoping someone can collect and enumerate comparative facts with great
organization skill.


>
>
>
> On 16 August 2010 11:12, Shelby Moore <shelby@coolpage.com> wrote:
>>> Shelby,
>>>
>>> Maybe I've missed something in recent threads, but how is WS/HTTP more
>>> vulnerable to data corruption?
>>>
>>> cheers
>>
>> Perhaps I misunderstood the issue.  Do some proxies monitor and filter
>> the
>> data, and may make mistakes because they think they are looking at HTTP,
>> because they didn't properly recognize the Upgrade handshake?  And maybe
>> other scenarios?  I really don't know.  I don't have enough experience
>> with proxies.
>>
>> Also I read that certain data patterns (e.g. unencoded binary) can not
>> traverse all proxies safely.  I realize perhaps we can avoid these known
>> patterns, but doesn't that imply there might also be some unknown
>> collisions?
>>
>>>
>>>
>>> On 16 August 2010 10:51, Shelby Moore <shelby@coolpage.com> wrote:
>>>>> On 16 August 2010 10:24, Shelby Moore <shelby@coolpage.com> wrote:
>>>>>>> On Sun, Aug 15, 2010 at 07:03:05PM -0400, Shelby Moore wrote:
>>>>>> We must have that fallback no matter what we do.  All options
>>>>>> forward
>>>>>> have
>>>>>> failure cases.
>>>>>>
>>>>>>> If I had the choice, I'd rather go for
>>>>>>> WS/TLS with a quick fail to WS/HTTP.
>>>>>>
>>>>>>
>>>>>> WS/HTTP can fail at random times after that quick fail, you still
>>>>>> need
>>>>>> Comet/BOSH.
>>>>>
>>>>> and Comet/BOSH can fail at random times.
>>>>> All solutions need to handle the fact that the internet can fail
>>>>> silently.
>>>>>
>>>>> I do not think it is possible to design a system that will always
>>>>> fast
>>>>> fail, other than an explicit declaration by a participant that a
>>>>> protocol is not supported.   It is impossible to design a handshake,
>>>>> whose success will guarantee the delivery of a subsequent websocket
>>>>> message .
>>>>>
>>>>> The only real evidence of a protocol working is the protocol working.
>>>>> The level of confidence in the protocol will be determined only by
>>>>> mechanisms built into the protocol: messages, keep-alives, ping/pongs
>>>>> and any extensions for acknowledgements etc.
>>>>>
>>>>> There is no silver bullet.
>>>>
>>>> Strong point, but won't the WS/port+tunnel (over TCP or equivalent)
>>>> only
>>>> fail-to-deliver and never corrupt, whereas WS/HTTP could corrupt the
>>>> data
>>>> (and will not support some data types at all, need encryption)?
>>>>
>>>> Also WS/HTTP is likely to fail more often during data transfer (after
>>>> initial handshake) given reasonable robust networks.
>>>>
>>>> So they are not equivalent failure costs.
>>>>
>>>
>>>
>>
>>
>
>