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
>>
>