Re: [hybi] Clarify the role of closing handshake

[Takeshi Yoshino <[e-mail]>]

Gabriel's idea is even simple. I don't object to that. I see the benefit of
Greg's idea, too.

A while back, Yuta listed error cases can happen during frame processing,
and suggested we define how we handle them. Maybe we would use abnormal
close frame for them.
http://www.ietf.org/mail-archive/web/hybi/current/msg05131.html

I think abnormal close frame should indicate only protocol level error
(frame parsing error, too large message, etc.). Any error inside application
can be exchanged on application level. So we don't have to extend close()
interface.

CloseEvent interface should be changed. _cleanly_ must be re-defined. We
would define three type of close, _normal close_, _abnormal close_,
_underlying channel terminated_, and replace "wasClean" with, say, "reason"
or something. I'm not sure if we should invoke error event, too. I
personally think it's redundant.

Then,
- close() called on WebSocket object -> send normal close frame -> "normal"
close event regardless of whatever happen
- any protocol level error happened on client side and sent abnormal close
frame -> "abnormal" close event
- received normal close frame -> "normal" close event
- received abnormal close frame -> "abnormal" close event
- underlying channel is closed without receiving close frame -> "underlying
channel terminated" close event

I think this modification on CloseEvent doesn't violate the security model
we now have to prevent WebSocket from being abused for port scanner.
Abnormal close is just a new variant of closure information explicitly sent
from the server. Thoughts?

So, by putting them together, like this?

----

4.5.1.  Close

The Close message contains an opcode of 0x01.

The Close message contains a body that is a single byte in length.  This
byte carrys the reason for the close.  For normal close, the body MUST be a
0x00. For abnormal close, the body MUST be a 0x01.

The websocket is considered fully closed when an endpoint has either sent or
received a Close message, or when the underlying channel is closed.

The application MUST NOT send any more data messages after sent or received
a Close message.

7.1.1.  Client-initiated closure

<I'm not sure how much it's useful to have client send normal/abnormal.
Server cannot retry by itself so, it's not the case Greg explained. But
maybe we can just add it as well as server.>

7.1.2.  Server-initiated closure

<No change on *abort WebSocket connection* during opening handshake>

Certain algorithms require or recommend that the server *abort2
the WebSocket connection* after WebSocket connection is established.  To do
so, the server must send a Close message with a single byte body 0x01
meaning abnormal closure and close the WebSocket connection.

<We need some verb to replace abort2>

7.2.  Normal closure of connections

To *close the WebSocket connection*, the user agent MUST send a Close
control frame with a single byte body 0x00 meaning normal closure, as
described in Section 4.5.1.  Once an endpoint has sent or received an Close
control frame, that endpoint must close the TCP ...  If the connection was
closed after the client sent or received normal close frame, then it's
called _normal close_. If the connection was closed after the client send or
received abnormal close frame, then it's called _abnormal close_. Otherwise,
it's called _underlying connection terminated_.

The user agent can distinguish protocol failure notified by abnormal close
frame from disconnection caused by network or intermediary to allow the
application to determine if it should retry connection or not.

...

On Thu, Feb 10, 2011 at 18:44, Greg Wilkins <[e-mail]> wrote:

> On 10 February 2011 20:25, Gabriel Montenegro
> <[e-mail]> wrote:
> > I think your simple reason would be enough (either normal or abnormal
> close for now).
>
> cool
>
> > To be clear: you're not arguing against the simplified semantics of
> considering the websocket closed (no further data or control) upon either
> sending or receiving a Close message, correct?
>
> I'm not arguing either way.  I can see the benefits of half close and
> flush through, but also the complexities, so I'm happy to follow herd
> on this one.
>
> cheers
>
>
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Greg
> >> Wilkins
> >> Sent: Wednesday, February 09, 2011 17:04
> >> To: Takeshi Yoshino
> >> Cc: [e-mail]
> >> Subject: Re: [hybi] Clarify the role of closing handshake
> >>
> >> One of the other aims of the closing handshake was to better identify
> error
> >> condition, so as to prevent a client repeating unacceptable operations.
> >>
> >> For example, if a client sends a frame that is too large for the server
> to handle,
> >> the server needs to indicate that an error condition has occurred.  If
> the
> >> connection is closed (orderly or otherwise) , then the client might
> assume that it
> >> was an idle shutdown or transient condition on the server and thus open
> a new
> >> connection and continue to send over large frames.
> >>
> >>
> >> Currently -05 says:
> >>
> >> 7.1.2.  Server-initiated closure
> >>    Certain algorithms require or recommend that the server *abort the
> >>    WebSocket connection* during the opening handshake.  To do so, the
> >>    server must simply close the WebSocket connection.
> >>
> >>
> >> the problem with this is that for a client such a close of the websocket
> >> connection cannot be distinguished from a
> >> network/intermediary failure.   I think that typically an aborted
> >> connection should not be retried, but a network/intermediary failure
> should be -
> >> so it would be good to be able to signal to the client the difference.
> >>
> >> Thus I'd like to suggest that the close handshake carry a single byte of
> reason for
> >> the close.
> >> I think it would be sufficient to define just:
> >>
> >>   0x00 Normal close
> >>   0x01 Abnormal close
> >>
> >> But I could see an argument for something a little richer:
> >>
> >>  0x00 Idle close
> >>  0x01 close
> >>  0x02 abnormal close
> >>
> >> but I concede that the danger here is trying to define too many close
> states
> >> _______________________________________________
> >> hybi mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/hybi
> >
> >
>