Re: WGLC Review: Connect-TCP

[Ben Schwartz <[e-mail]>]

I'm happy to improve the text as suggested on all these points.

Regarding TCP RST, the argument here is that TCP connections can close cleanly or uncleanly, and that difference can be important.  The proxy needs a way to convey that information to the client.  In HTTP/2+ we have a framing layer within the protocol that can convey this distinction.  In (secure) HTTP/1.1, TLS is the framing layer, so it's logical that it should have responsibility for carrying this signal.  We could have used a TCP RST (bypassing the TLS layer) instead, but that would be less secure, less private, and prone to accidental loss by TCP middleboxes.

________________________________
From: Mike Bishop <[e-mail]>
Sent: Thursday, April 11, 2024 5:07 PM
To: HTTP Working Group <[e-mail]>
Subject: WGLC Review: Connect-TCP

Yes, I know the WGLC was a while ago, but I don’t see that we’ve submitted it yet, so here we go. 1) The direction in 3. 1 to use a TLS alert from the proxy to signal TCP RSTs from the server surprises me. Is the logic here to ensure


Yes, I know the WGLC was a while ago, but I don’t see that we’ve submitted it yet, so here we go.



1) The direction in 3.1 to use a TLS alert from the proxy to signal TCP RSTs from the server surprises me. Is the logic here to ensure that the error is reliably delivered to the client? Maybe I missed some discussion, but it might be worth mentioning the rationale in the doc.



2) Looks like we’re missing normative references to Extended CONNECT in 3.2. That’s an easy fix. (Filed an issue for this one.)



3) The permission for optimistic data in 4.1 for HTTP/2 and HTTP/3 is “not permitted” for HTTP/1.1 for good reason; is there a reason the draft stops short of a MUST NOT?



I think the document is in good shape, and I appreciate the work everyone has put into it until now.



Thanks,

Mike Bishop