Simone, please disregard the link to the test I gave you. My apologies. This test has nothing to do with starting a new message after a Close message has been received. It just verifies that the endpoint stops reading after receiving onClose. So not sending back a Pong is perfectly natural in this case.
But I still think we probably more safe assuming the intersection of our understandings, rather than a union :-) > On 23 Jun 2016, at 16:20, Pavel Rappo <pavel.ra...@oracle.com> wrote: > > >> On 23 Jun 2016, at 16:01, Simone Bordet <simone.bor...@gmail.com> wrote: >> >> Hi, >> >> However, here's another examples that shows the ambiguity: >> >> |-> sendBinary(huge, true); >> |<- onClose() >> >> The implementation will fragment "huge", or the write will be >> incomplete, so that "huge" is not fully sent yet. >> When the onClose() is received, who is it that is sending the frames ? > > The implementation. Sure. > >> Certainly not the application, since the sendBinary() call returned. >> It's the implementation that is sending the frames when onClose() arrives. >> >>>> I think this is wrong. >>>> Leaving room to "implementation specific" details is allowing for >>>> writing applications that are not portable. >>> >>> We're talking about an extremely rare corner case, where we guarantee that >>> a new >>> message WILL NOT be sent to the server. >> >> Why not ? >> >>> The difference is how the WebSocket will >>> react on attempting to do so. >>> >>> Okay, I'm fine with REQUIRING is a new message is a attempted to be send, WS >>> will send a Close message instead and complete the CF returned from send >>> operation exceptionally. >> >> Why you want to deny the possibility of sending data in half closed state ? >> Implementation wise is simple, semantic is simple, is there a specific >> reason ? >> >>> I'm not a TCP expert. Does TCP allow an endpoint to skip the data it >>> receives >>> after this endpoint has half-closed the connection? Because WebSocket does: >>> >>> ...However, there is no guarantee that the >>> endpoint that has already sent a Close frame will continue to process >>> data... >> >> See, the sentence after that is: >> >> "After both sending and receiving a Close message, an endpoint >> considers the WebSocket connection closed and MUST close the >> underlying TCP connection." >> >> Which tells that an endPoint closes the TCP connection when it is >> fully closed (2 halves). >> So, if you *have* to continue reading from the network to read the >> reply close frame, what do you do with the data that you read in >> between ? >> You throw it away ? >> I guess that is "legal" too, but I would stay on the side of >> reasonable behavior, not trying to literally adhere to a non-normative >> vague wording. > > Is that how it works in Jetty? Joakim has mentioned once his view on the > correct > behaviour here [1], which actually made me re-read the RFC and agree with him: > > ...Close should occur after the actively being sent message (aka once a > fin==true is encountered in the frame queue)... > > Have a look at this testcase: > > > http://autobahn.ws/testsuite/reports_20131013/clients/autobahnpypy_case_7_1_6.html > > Interestingly enough, the Pong is not sent back. Yes, there's a variability > in the test > expected, but only in the amount of echoed text data, but they do not expect > Pong. > > Thanks, > -Pavel > > -------------------------------------------------------------------------------- > [1] http://mail.openjdk.java.net/pipermail/net-dev/2016-June/009936.html >
