On 25 July 2011 05:11, Richard L. Barnes <rbarnes@xxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf