- From: Greg Wilkins <gregw@webtide.com>
- Date: Wed, 8 Dec 2010 10:28:02 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Mark Nottingham <mnot@mnot.net>, hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 8 December 2010 00:47, Maciej Stachowiak <mjs@apple.com> wrote: > The main complaint about CONNECT from server folks seems to be literally a > question of semantics. There is also the related practical issue of having > to turn off alerts on CONNECT attempts if you want to serve WebSocket. Maciej, While I agree that semantics is an element of the complaints against CONNECT, I do not think it is the main complaint. One part of the technical complaint is that CONNECT is not a method that should arrive at an origin server and has been the basis of past attacks. It is not just a matter of turning off alerts for CONNECTs arriving in a data centre so that websocket can work, as the concern would be what other attacks are you opening up on other infrastructure by allowing connects. If the inclusion of websocket headers is sufficient to turn off attack alerts, then we may be re-enabling classes of attack that have previously been dealt with. Another complaint of substance with the CONNECT proposal as it has been made is the bogus host headers, which likewise can break a lot of existing HTTP infrastructure. I'm not saying these issues cannot be dealt with, but they also cannot be dismissed out of hand. We have very senior/experienced people saying that letting CONNECT requests reach the servers is going to be a real problem. We need to address that will a little more rigour than suggesting we just turn off alerts. regards
Received on Wednesday, 8 December 2010 09:28:35 UTC