> On 13 Jun 2016, at 14:45, Simone Bordet <simone.bor...@gmail.com> wrote: > > Because contrary to ping, the specification does not say "as soon as > possible" but: > > "An endpoint MAY delay sending a Close frame until its current message is > sent (for instance, if the majority of a fragmented message is > already sent, an endpoint MAY send the remaining fragments before > sending a Close frame)."
This should be read in context :p If an endpoint receives a Close frame and did not previously send a Close frame, the endpoint MUST send a Close frame in response. (When sending a Close frame in response, the endpoint typically echos the status code it received.) It SHOULD do so as soon as practical. An endpoint MAY delay sending a Close frame until its current message is sent (for instance, if the majority of a fragmented message is already sent, an endpoint MAY send the remaining fragments before sending a Close frame). I think it's more about reciprocated Close rather than unsolicited. Overall I'm thinking of pushing the change, with the disclaimer that in future it doesn't stop us from accepting a custom queue in the builder. So 1-outstanding write policy could be enforced by the implementation.
