On 25 July 2011 05:11, Richard L. Barnes <rbarnes(_at_)bbn(_dot_)com> wrote:
It seems like this gets you around the threat that masking is supposed to
address -- the proxy won't see anything mid-stream that looks like HTTP,
since it's just acting as a tunnel at that point. It's a little weird to use
CONNECT end-to-end, but that doesn't seem bad enough to be a blocking issue.
One concern expressed was that existing infrastructure may have
special handling that triggers on the CONNECT method. Eg. code that
will look at only the first HTTP request on a connection before
becoming a bit pipe. Such proxies will work with websockets when GET
is used, but will fail with CONNECT because it will trigger special
handling to look for the destination server, which will not be present
in the handshake.
If the concern with using GET is that we are changing established
semantics, then surely that concern must also apply to changing the
semantics of CONNECT. If changed semantics is the concern, then using
an entirely new method would be applicable.
However, my reading of the discussion resulting to Roy's objection to
the use of GET, is that he was mostly concerned that the 101 response
not be consider the final response to the GET, and that semantically
there is still a request to be responded to that is related to the
specific URL passed in the GET. If semantically the WS stream is
considered the response to the GET for the URI, then I think's Roy's
issues are resolved. (NB. I've misread Roy's concerns a few times...
so confirmation that I've got it right this time would be good).
cheers
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf