> 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