On August 27, 2019 6:54:22 AM UTC, Johan Compagner <jcompag...@servoy.com> wrote: >> >> >> > 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 >side.. >> > I guess if onclose was called programatically from the server side >then >> 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 >of >reload/refresh) >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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
