Close in response to invalid CONNECTION_CLOSE #3230
Conversation
The looping case was a little unclear. This should make it a tiny bit clearer. As Roni observes, we can't really let invalid CONNECTION_CLOSE through without some sort of special handling. This proposes that. Unfortunately, this is a little more than an editorial fix. So I'm going to ask that the issue be promoted. Closes #2475.
martinthomson
added
design
| @@ -2709,8 +2710,10 @@ frame risks a peer missing the first such packet. The only mechanism available | |||
| to an endpoint that continues to receive data for a terminated connection is to | |||
| use the stateless reset process ({{stateless-reset}}). | |||
|
|
|||
| An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT signal the | |||
| existence of the error to its peer. | |||
| An endpoint that receives an invalid CONNECTION_CLOSE frame MUST treat the | |||
There was a problem hiding this comment.
What is an invalid CONNECTION_CLOSE frame?
There was a problem hiding this comment.
One that has an reason phrase that overruns the packet would do it. I can't see any other reason.
There was a problem hiding this comment.
I don't think we need any extra rules for this special case. Just do what you'd normally do: close the connection with a FRAME_ENCODING_ERROR.
There was a problem hiding this comment.
I see, you think that it is enough to rely on rate limiting of the CONNECTION_CLOSE packet (c.f., #3095). That would also work.
| send further packets, which could result in a constant exchange of | ||
| CONNECTION_CLOSE frames until the closing period on either peer ended. | ||
| After receiving a CONNECTION_CLOSE frame, or an invalid packet that appears to | ||
| contain a CONNECTION_CLOSE frame, endpoints enter the draining state. An |
There was a problem hiding this comment.
Looks like Github swallowed my previous comment on this line:
How would you even parse an invalid packet? What does it mean to "appear to contain" a frame?
There was a problem hiding this comment.
A packet might "appear to contain a frame" if it contains the truncated beginning of a frame.
There was a problem hiding this comment.
"or an invalid packet that appears to contain a CONNECTION_CLOSE_ frame," is a pretty big category of potential issues. Does this need to be called out as separate from the general invalid packet case?
There was a problem hiding this comment.
I think that we'll just go with #3231 and avoid having to worry about this definition.
| An endpoint that receives an invalid CONNECTION_CLOSE frame MUST treat the | ||
| message as being equivalent to a CONNECTION_CLOSE with the INTERNAL_ERROR error | ||
| code. The endpoint MAY send a single CONNECTION_CLOSE in response, but it MUST | ||
| then enter the draining period; see {{draining}}. | ||
|
|
There was a problem hiding this comment.
Would INTERNAL_ERROR not suggest a locally induced inconsistent state as opposed to an observed remote inconsistent state? If so, I think it is important to make a distinction since it affects who is to blame and consequently where to debug.
The looping case was a little unclear. This should make it a tiny bit
clearer. As Roni observes, we can't really let invalid CONNECTION_CLOSE
through without some sort of special handling. This proposes that.
Unfortunately, this is a little more than an editorial fix. So I'm
going to ask that the issue be promoted.
Closes #2475.