[Connect-TCP WGLC] Edge cases for FINAL_DATA

[ekinnear]

A few (potentially editorial) questions about FINAL_DATA that might be worth clarifying in the document text:

1. What happens if I get duplicate FINAL_DATA. We say:

After sending a FINAL_DATA capsule, an endpoint MUST NOT send any more DATA or FINAL_DATA capsules on this data stream. (See Section 3.4 for related requirements.)

But there is nothing that says what to do as a receiver if you receive a second FINAL_DATA. Is that an error? Do you ignore it?

2. HTTP stream FIN, but no FINAL_DATA. We say:

When the receive stream is closed abruptly or without a FINAL_DATA capsule received, the endpoint SHOULD send a TCP RST if the TCP subsystem permits it.

Given that this potentially means data is truncated, should we upgrade this to a "MUST, if", rather than a "SHOULD, if"? It'd be nice if this signal were as likely as possible to propagate.

3. FINAL_DATA, but no HTTP stream closure.

We say that an endpoint "MUST close its send stream", but what do I do as a receiver if I get FINAL_DATA but the HTTP stream stays open? Should I have a timeout? Is that an error? Do I just ignore it and decide the other endpoint is taking up some of its stream flow control credit, so it probably shouldn't do that, but it's fine if it does (I like this last one, personally)?

[wtarreau]

For point 2, I think SHOULD is preferable. RST is not always easy to produce and most frameworks will probably not expose this possibility at all. Also "closed abruptly" corresponds to the detection of a null read() before FINAL_DATA, and sending just a FIN will reproduce exactly that. Finally, sending an RST will result in truncation of bytes already sent down the send path which in certain circumstances might not necessarily be desirable, and some implementations might prefer to stick to a regular FIN instead.

Same question as you regarding points 1 and 3 however.

[bemasc]

On 1: IMHO, as a general rule, if party A detects that party B has violated a mandatory requirement, party A is permitted to abort and report unless there is an explicit prohibition.

On 3: I wouldn't want to complicate the state machine by addressing this explicitly. It's certainly weird, and I can imagine that production implementations might well have some kind of idle timeout, but that's also true at every other stage of the connection.