Re: [hybi] -09: abstract and introduction

"Simon Pieters" <simonp@opera.com> Thu, 16 June 2011 11:15 UTC

Return-Path: <simonp@opera.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4719711E823E for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 04:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olpsobvddCuN for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 04:15:38 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 475E611E822C for <hybi@ietf.org>; Thu, 16 Jun 2011 04:15:37 -0700 (PDT)
Received: from simon-pieterss-macbook.local (oslo.jvpn.opera.com [213.236.208.46]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5GBFZm0006102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Jun 2011 11:15:35 GMT
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "hybi@ietf.org" <hybi@ietf.org>, "Peter Saint-Andre" <stpeter@stpeter.im>
References: <4DF91FCA.8060403@stpeter.im>
Date: Thu, 16 Jun 2011 13:15:37 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Simon Pieters" <simonp@opera.com>
Message-ID: <op.vw51kblbidj3kv@simon-pieterss-macbook.local>
In-Reply-To: <4DF91FCA.8060403@stpeter.im>
User-Agent: Opera Mail/11.11 (MacIntel)
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 16 Jun 2011 11:15:39 -0000

On Wed, 15 Jun 2011 23:10:34 +0200, Peter Saint-Andre <stpeter@stpeter.im>  
wrote:

> Section 1.3 says:
>
>    A JavaScript application cannot set a header starting with "Sec-" via
>    XHR.
>
> Why not? What is the nature of the restriction?

"Header names starting with Sec- are not allowed to be set to allow new  
headers to be minted that are guaranteed not to come from XMLHttpRequest."

http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-xmlhttprequest-setrequestheader

> Section 1.3 says:
>
>    If the |Sec-WebSocket-Accept|
>    value does not match the expected value, or if the header is missing,
>    or if the HTTP status code is not 101, the connection will not be
>    established and WebSocket frames will not be sent.
>
> Do we really mean the following?
>
>    If the |Sec-WebSocket-Accept|
>    value does not match the expected value, or if the header is missing,
>    or if the HTTP status code is not 101, the browser MUST NOT
>    establish the connection and MUST NOT send WebSocket frames.

All of section 1 is non-normative so shouldn't contain any requirements.


> This paragraph is hard to read:
>
>    Conceptually, WebSocket is really just a layer on top of TCP that
>    adds a Web "origin"-based security model for browsers; adds an
>    addressing and protocol naming mechanism to support multiple services
>    on one port and multiple host names on one IP address; layers a
>    framing mechanism on top of TCP to get back to the IP packet
>    mechanism that TCP is built on, but without length limits; and
>    includes an additional closing handshake in-band that is designed to
>    work in the presence of proxies and other intermediaries.  Other than
>    that, it adds nothing.  Basically it is intended to be as close to
>    just exposing raw TCP to script as possible given the constraints of
>    the Web. It's also designed in such a way that its servers can share
>    a port with HTTP servers, by having its handshake be a valid HTTP
>    Upgrade request mechanism also.
>
> I suggest breaking it up into bullet points:
>
>    Conceptually, WebSocket is really just a layer on top of TCP that
>    does the following:
>
>    * adds a Web "origin"-based security model for browsers
>
>    * adds an addressing and protocol naming mechanism to support
>    multiple services on one port and multiple host names on one IP
>    address;
>
>    * layers a framing mechanism on top of TCP to get back to the IP
>    packet mechanism that TCP is built on, but without length limits
>
>    * includes an additional closing handshake in-band that is designed
>    to work in the presence of proxies and other intermediaries
>
>    Other than that, WebSocket adds nothing.  Basically it is intended
>    to be as close to just exposing raw TCP to script as possible given
>    the constraints of the Web. It's also designed in such a way that
>    its servers can share a port with HTTP servers, by having its
>    handshake be a valid HTTP Upgrade request mechanism also.

I'm not sure this text is accurate anymore now that we have extensions and  
whatnot.

> Section 1.7 says:
>
>    By default the WebSocket protocol uses port 80 for regular WebSocket
>    connections and port 443 for WebSocket connections tunneled over TLS
>    [RFC2818].
>
> I know this has been discussed on the list, but how can an entity
> discover if WebSocket is offered on ports other than 80/443? Would the
> web server use a redirect to do that? Could it define SRV records?

I don't think there's any discoverability. You can't know that WebSocket  
is offered on ports 80/443 either. I think the Web page that opens a  
WebSocket is supposed to know which port to use. (The WebSocket API  
doesn't allow redirects.)

-- 
Simon Pieters
Opera Software