- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 27 Oct 2017 10:39:23 +1100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: John Fallows <john.fallows@kaazing.com>, Patrick McManus <pmcmanus@mozilla.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 27 Oct 2017, at 10:07 am, Martin Thomson <martin.thomson@gmail.com> wrote: > > I still lean toward CONNECT for this, despite reservations about the subtle difference between usages (proxy vs. origin). A natural lightweight implementation of this has the server add proxy code that forwards the tunnel to a websocket server. That proxy would need to perform the old-school 6455 handshake with the websocket server, but could construct that from the headers of the CONNECT request. The handling of the header might be different, but the DATA frames are handled just like a CONNECT tunnel. That said, there is enough difference here to justify a different method. Just to give some context as to why I don't think it's a subtle change -- consider OWASP's mod_security CRS, which is the basis of most WAF products. It has baked-in assumptions about the semantics of CONNECT; e.g., <https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/e4e0497be4d598cce0e0a8fef20d1f1e5578c8d0/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf> That is pretty widely deployed, and just one example. Don't assume that HTTP is just a two-party protocol, even over HTTPS. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 26 October 2017 23:39:55 UTC