On August 27, 2019 6:54:22 AM UTC, Johan Compagner <jcompag...@servoy.com> 
>> > As far as i can understand it should not try to send a close
>message at
>> > that point, because the close did already happen from the client
>> > I guess if onclose was called programatically from the server side
>> it
>> > is logical.
>> RFC 6455, section 5.5.1
>> Close is a two-stage process and closing the TCP connection is the
>> server's responsibility.
>> Looks like you have a non-spec compliant client.
>But that is just a browser that gets an other url loaded (i think kind
>how can that be a 2 way thing?

Because RFC 6455 says it is. The WebSocket connection is not considered closed 
until both endpoints have sent, and received, a close frame. Then it is the 
server's responsibility to close the TCP connection.

>If i close a tab or i force reload the tab then yes i can get that the
>browser can send a close request to the server
>But it has to wait for it?

To be RFC 6455 compliant, yes.

> I can't believe that many browsers do that?
>What if the latency is a few hundred millis?

Nothing says the browser can't do this in the background. I'd expect it to wait 
in the background so the UI remains responsive.


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to