Re: [hybi] WebSocket feedback
Greg Wilkins <gregw@webtide.com> Fri, 05 March 2010 19:42 UTC
Return-Path: <gregw@webtide.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0985B28C33E for <hybi@core3.amsl.com>; Fri, 5 Mar 2010 11:42:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.592
X-Spam-Level:
X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8c3AcXVwpWOC for <hybi@core3.amsl.com>; Fri, 5 Mar 2010 11:42:42 -0800 (PST)
Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 2404828C33D for <hybi@ietf.org>; Fri, 5 Mar 2010 11:42:41 -0800 (PST)
Received: by fxm5 with SMTP id 5so4504865fxm.29 for <hybi@ietf.org>; Fri, 05 Mar 2010 11:42:40 -0800 (PST)
Received: by 10.223.16.66 with SMTP id n2mr1433488faa.83.1267818159908; Fri, 05 Mar 2010 11:42:39 -0800 (PST)
Received: from [192.168.0.100] (host116-234-static.43-88-b.business.telecomitalia.it [88.43.234.116]) by mx.google.com with ESMTPS id c28sm3257452fka.14.2010.03.05.11.42.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Mar 2010 11:42:38 -0800 (PST)
Message-ID: <4B915EA1.2030701@webtide.com>
Date: Fri, 05 Mar 2010 20:42:25 +0100
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Graham Klyne <GK@ninebynine.org>
References: <8B0A9FCBB9832F43971E38010638454F032E566DDF@SISPE7MB1.commscope.com> <Pine.LNX.4.64.1002150605580.29686@ps20323.dreamhostps.com> <4B8F6056.8060809@webtide.com> <CE4EF44A-6C8F-43BC-ABF4-777C1149A16F@d2dx.com> <4B8F72FA.2050908@webtide.com> <4B90D3B2.8070502@ninebynine.org>
In-Reply-To: <4B90D3B2.8070502@ninebynine.org>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] WebSocket feedback
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Mar 2010 19:42:44 -0000
Graham, it is my experience that GETs with bodies transit the internet without problem - which is as the spec says they should. But I agree that having a GET with a body can stretch the semantics of the method. For this reason and for avoiding auto retries, I think POST would be a better method. cheers Graham Klyne wrote: > From the "everything you always knew is (almost) false" department, this > comment sent me off to re-read bits of RFC2616. While what you say is > (almost) technically correct, I think it's misleading. > > [[ > A message-body MUST NOT be included in a request if the specification of > the request method (section 5.1.1) does not allow sending an entity-body > in requests. A server SHOULD read and forward a message-body on any > request; if the request method does not include defined semantics for an > entity-body, then the message-body SHOULD be ignored when handling the > request. > ]] > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3 > > Where GET is defined in section 9.3 [2], there is no mention of message > body either to prohibit or to define semantics, so it appears that while > the presence of a message body on GET is just about legal, it SHOULD be > ignored by any server that handles it. > > [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3 > > #g > -- > > Greg Wilkins wrote: >> Vladimir, >> >> GET's can have content. It's just the browsers mostly don't send >> content with GETs. >> >> The server needs to consider the bytes of content before formulating >> the accepting the upgrade request and sending the 101 response, so >> it can't be considered as data in the stream after the 101. >> >> regards >> >> >> Vladimir Katardjiev wrote: >>> I like this update, especially that the handshake is human-readable in >>> the spec now. Caveat that I haven't implemented it yet so I guess proper >>> feedback comes then. >>> >>> On 4 mar 2010, at 08.25, Greg Wilkins wrote: >>>> If the handshake messages are to contain content, then they >>>> MUST have headers to indicate the content length to be legal >>>> HTTP: in this case, a Content-Length header would be appropriate >>> I interpret the "content" to not relate to the HTTP handshake, but >>> belong to the WebSocket stream. To quote: >>> >>> "I've moved some of the handshake to the WebSocket _connection_, >>> after the headers." (emphasis mine) >>> >>> Besides, a GET request can't have a body, so it's pretty much intended >>> to break. However, if you instead view the sequence as WS Upgrade -> >>> client sent body -> server sent reply it is perfectly valid. >>> >>>> Considering that we are already shipping products with >>>> websocket implementations from the existing draft, can we >>>> specify a transition to the new handshake in an appendix. >>>> >>>> Ie while the standard is under development connections without >>>> websocket keys MAY be accepted, but implementation SHOULD warn >>>> that support for such connections is deprecated. >>> Actually, it's not enough to just drop the keys. The header names >>> changed too so you'd need to read WebSocket-Location instead of >>> Sec-WebSocket-Location, for example. It's almost as if we're at a new >>> "version" now. >>>> The text of 1.3, still kind of implies that the HTTP fields >>>> must be ordered as per the spec. Can we add a sentence to say >>>> that header ordering may be different. >>> YMMV, but I don't see any such implication in the text. >>> >>> Later on, the client handshake is explicitly asked to send the headers >>> in a _random_ order (although _any_ order should do fine?) so there >>> should be no confusion on that point. >>>> Also I'm not sure this sentence is really that clear: >>>> >>>> "Additional fields are used to select options in the WebSocket >>>> protocol. The only option available in this version is the >>>> subprotocol selector, |Sec-WebSocket-Protocol|:" >>>> >>>> I thought we were going to allow arbitrary extra headers, >>>> but that their interpretation was not defined by the ws spec >>>> other than the optional Sec-WebSocket-Protocol. We still >>>> need to allow headers for cookies, authentication etc. >>> Yes. Client handshake step 15 explicitly adds those cookies. This part I >>> guess is intended for things that can be modified directly using the >>> API. The "arbitrary" extra headers permitted thus far are only things >>> added by the browser implicitly. >>> Vladimir >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> hybi mailing list >>> hybi@ietf.org >>> https://www.ietf.org/mailman/listinfo/hybi >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >
- Re: [hybi] WS ABNF Dave Cridland
- Re: [hybi] WS ABNF Julian Reschke
- Re: [hybi] WS ABNF Greg Wilkins
- Re: [hybi] WS ABNF Thomson, Martin
- [hybi] WS ABNF Thomson, Martin
- Re: [hybi] WS ABNF Dave Cridland
- Re: [hybi] WS ABNF Julian Reschke
- Re: [hybi] WS ABNF Jamie Lokier
- Re: [hybi] WS ABNF Pieter Hintjens
- Re: [hybi] WS ABNF Dave Cridland
- Re: [hybi] WS ABNF Dave Cridland
- Re: [hybi] WS ABNF Greg Wilkins
- Re: [hybi] WS ABNF Scott Ferguson
- Re: [hybi] WS ABNF Dave Cridland
- Re: [hybi] WS ABNF Scott Ferguson
- Re: [hybi] WebSocket feedback Thomson, Martin
- [hybi] WebSocket feedback Ian Hickson
- Re: [hybi] WebSocket feedback Ian Hickson
- Re: [hybi] WebSocket feedback Greg Wilkins
- Re: [hybi] WebSocket feedback Vladimir Katardjiev
- Re: [hybi] WebSocket feedback Greg Wilkins
- Re: [hybi] WebSocket feedback Greg Wilkins
- Re: [hybi] WebSocket feedback Vladimir Katardjiev
- [hybi] Publishing drafts, Re: WebSocket feedback Julian Reschke
- Re: [hybi] Publishing drafts, Re: WebSocket feedb… Julian Reschke
- [hybi] Framing, was Re: WebSocket feedback Dave Cridland
- Re: [hybi] WebSocket feedback Greg Wilkins
- Re: [hybi] WebSocket feedback Vladimir Katardjiev
- Re: [hybi] WebSocket feedback Greg Wilkins
- Re: [hybi] WebSocket feedback Joe Hildebrand
- Re: [hybi] WebSocket feedback Greg Wilkins
- Re: [hybi] WebSocket feedback Greg Wilkins
- Re: [hybi] WebSocket feedback Julian Reschke
- Re: [hybi] WebSocket feedback Mridul Muralidharan
- [hybi] requirement: backwards compatible?. was : … Greg Wilkins
- Re: [hybi] requirement: backwards compatible?. wa… Anne van Kesteren
- Re: [hybi] requirement: backwards compatible?. wa… Vladimir Katardjiev