Re: [hybi] thewebsocketprotocol #39 (closed): multiple extensions selection in the server side handshake

"hybi issue tracker" <trac@tools.ietf.org> Tue, 08 February 2011 19:29 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: hybi issue tracker <trac@tools.ietf.org>
Precedence: bulk
Auto-Submitted: auto-generated
To: ifette@google.com
Date: Tue, 08 Feb 2011 19:29:21 -0000
Message-ID: <077.d634d5b0cd4d9b5b8c98ab033ec56a2b@tools.ietf.org>
References: <068.36490524d935945394c51f239c8e5ca3@tools.ietf.org>
In-Reply-To: <068.36490524d935945394c51f239c8e5ca3@tools.ietf.org>
Cc: hybi@ietf.org
Subject: Re: [hybi] thewebsocketprotocol #39 (closed): multiple extensions selection in the server side handshake

#39: multiple extensions selection in the  server side handshake

Changes (by ifette@…):

  * status:  new => closed
  * resolution:  => fixed


Old description:

> the fact that the server can select more then one extension, among the
> ones that client has offered, is not clear in the current version (04).
>
> in order to clarify that,
> the following minor change to the text has been proposed by Alexander:
>
> 1 /extensions/
> 2   A (possibly empty) list representing the protocol-level
> 3   extensions the server is ready to use.  If the server supports
> 4   multiple extensions, then the value of each extension should be
> 5   derived from the client's handshake and match exactly one of the
> 6   values in the "Sec-WebSocket-Extensions" field.  The absence
> 7   of such a field is equivalent to the null value.  The empty
> 8    string is not the same as the null value for these purposes.
>
> The changes are in lines 4 and 5.
>
> see: http://www.ietf.org/mail-archive/web/hybi/current/msg05851.html

New description:

 the fact that the server can select more then one extension, among the
 ones that client has offered, is not clear in the current version (04).

 in order to clarify that,
 the following minor change to the text has been proposed by Alexander:

 1 /extensions/
 2   A (possibly empty) list representing the protocol-level
 3   extensions the server is ready to use.  If the server supports
 4   multiple extensions, then the value of each extension should be
 5   derived from the client's handshake and match exactly one of the
 6   values in the "Sec-WebSocket-Extensions" field.  The absence
 7   of such a field is equivalent to the null value.  The empty
 8    string is not the same as the null value for these purposes.

 The changes are in lines 4 and 5.

 see: http://www.ietf.org/mail-archive/web/hybi/current/msg05851.html

--

Comment:

 Resolved in r58 in svn. will be included in -05

-- 
-------------------------------------------+--------------------------------
 Reporter:  salvatore.loreto@…             |        Owner:        
     Type:  enhancement                    |       Status:  closed
 Priority:  minor                          |    Milestone:        
Component:  thewebsocketprotocol           |      Version:        
 Severity:  -                              |   Resolution:  fixed 
 Keywords:                                 |  
-------------------------------------------+--------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/hybi/trac/ticket/39#comment:1>
hybi <http://tools.ietf.org/hybi/>
The Hypertext-Bidirectional (HyBi) working group will seek
standardization of one approach to maintain bidirectional
communications between the HTTP client, server and intermediate
entities, which will provide more efficiency compared to the current
use of hanging requests.

[hybi] thewebsocketprotocol #39 (new): multiple e… hybi issue tracker
Re: [hybi] thewebsocketprotocol #39 (closed): mul… hybi issue tracker