Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)

[Salvatore Loreto <[e-mail]>]

to be clear, I am sympathetic with the need to better clarify the text 
and serialize
on both |host| and |port| but with the meaning of IP and |port|


-- 
Salvatore Loreto, PhD
www.sloreto.com



On 2/14/13 9:45 AM, Salvatore Loreto wrote:
> the original idea was to serialize the tentative to connect to the 
> same IP address (especially in
> the case several /host/ names share the same IP address);
> IMO it becomes clear if you read the second paragraph of the bullet #2 
> and the NOTE.
>
>
>     2.  If the client already has a WebSocket connection to the remote
>         host (IP address) identified by /host/ and port /port/ pair, even
>         if the remote host is known by another name, the client MUST wait
>         until that connection has been established or for that connection
>         to have failed.  There MUST be no more than one connection in a
>         CONNECTING state.  If multiple connections to the same IP address
>         are attempted simultaneously, the client MUST serialize them so
>         that there is no more than one connection at a time running
>         through the following steps.
>         If the client cannot determine the IP address of the remote host
>         (for example, because all communication is being done through a
>         proxy server that performs DNS queries itself), then the client
>         MUST assume for the purposes of this step that each host name
>         refers to a distinct remote host, and instead the client SHOULD
>         limit the total number of simultaneous pending connections to a
>         reasonably low number (e.g., the client might allow simultaneous
>         pending connections to a.example.com and b.example.com, but if
>         thirty simultaneous connections to a single host are requested,
>         that may not be allowed).  For example, in a web browser context,
>         the client needs to consider the number of tabs the user has open
>         in setting a limit to the number of simultaneous pending
>         connections.
>
>
>         NOTE: This makes it harder for a script to perform a denial-of-
>         service attack by just opening a large number of WebSocket
>         connections to a remote host.  A server can further reduce the
>         load on itself when attacked by pausing before closing the
>         connection, as that will reduce the rate at which the client
>         reconnects.
>
>
> -- 
> Salvatore Loreto, PhD
> www.sloreto.com
>
>
> On 2/5/13 3:00 PM, Martin Thomson wrote:
>>
>> That is approximately where my reasoning lead. I think that the 
>> *safe* option is to have one connection per name.
>>
>> On Feb 4, 2013 3:20 AM, "Adam Rice" <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>     On 1 February 2013 23:27, Martin Thomson
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         Is this "host and port" or "IP and port" ?  That too is
>>         unclear.  If
>>         I'm sharding a.example.com <http://a.example.com> and
>>         b.example.com <http://b.example.com> and they are served on
>>         the same VIP, is the expectation that wss://a.example.com/
>>         <http://a.example.com/> and
>>         wss://b.example.com/ <http://b.example.com/> can't have
>>         concurrent connection attempts?
>>
>>
>>     I was assuming that in the first sentence the text "connection to
>>     the remote host (IP address) ... even if the remote host is known
>>     by another name" made the interpretation of "IP address" unambiguous.
>>
>>     But section 4.1 says that /host/ is defined in section 3, and
>>     section 3  actually defines /host/ as "host = <host, defined in
>>     [RFC3986], Section 3.2.2
>>     <http://tools.ietf.org/html/rfc3986#section-3.2.2>>", ie. the
>>     host portion of the URI.
>>
>>     So now I don't know.
>>
>>
>>
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi