Re: Working Group Last Call: draft-ietf-httpbis-optimistic-upgrade-03

On Mon, May 12, 2025 at 02:48:30PM +1000, Martin Thomson wrote:
> It seems like the only reason to allow optimistic sending here is latency.
> That's important, but we have a solution for that in HTTP/2 and /3, as
> Section 7 says.  I'd much rather we keep the prohibition for HTTP/1.1.

Agreed, optimistic sending over H1 is a dead-end.

> Section 6 has some good advice, but Section 6.1 makes an odd recommendation
> about using GET with Upgrade to "reduce[] the likelihood that a faulty server
> implementation might process the request body as the new protocol" (in part,
> the other part is consistency).  This would seem to miss the point, because
> it is not the method of the failed request that matters, but the one
> afterwards. 
> 
> The fact that GET rarely includes a body is perhaps the only reason that
> might be relevant here, which might be cause to recommend GET, but the text
> should say that if it is.  But then it would be making another claim that I
> think is unwise, which is that you can't convince a client to generate a GET
> with a body, because that becomes part of the defense.

I think it would be clearer if it said "... to bodyless GET requests if ...".
Also that reminds me of that report of POST+Upgrade from Docker that I
reported a few months ago:

   https://lists.w3.org/Archives/Public/ietf-http-wg/2024OctDec/0302.html

Maybe we should suggest a way out for such protocols ? For example "There
are many risks in upgrading a connection upon a POST request, depending
on the entity controlling the body contents. Applications relying on
upgraded POST connections should consider alternate and safer ways of
conveying the data, such as query string parameters or header fields for
short contents".

> If it is part of the
> defense, the draft needs to say that.  I also don't think that it's a
> reliable defense.  Again, I'd much rather say that if you try to transition
> an HTTP/1.1 connection and it fails, stop using the connection.
> 
> I realize that this has non-trivial performance costs.  Section 7 explains
> how to deal with that.

I think that for this to be usable/acceptable, it needs to say that the
connection must stop being used if any data were already sent (only the
client knows, the server only sometimes knows). But if we try to encourage
servers (here proxies) to close the connection after a 407, or even the
client to always send a "connection: close" with every CONNECT that does
not try to send data, we'll get enterprise and campus proxies to simply
ignore the spec when they figure they cannot authenticate users anymore.

Thus IMHO it should be:
  - client:
    - SHOULD NOT send optimistic data with CONNECT
    - MUST send connection: close if it ever does
    - MUST NOT try to reuse a failed connection if it does
  - server:
    - MUST close the connection on failed upgrade attempts if anything
      suggests some data were sent prior to the proper connection upgrade.

All of this makes me think that we might be missing a tool comparable to
the Expect header field, that would work as a strong request *not* to
forward the body before the upgrade is done. We could imagine for example
"Expect: 200" (for CONNECT) or "Expect: 101" (for Upgrade) to ask
intermediaries to also hold the body until the upgrade is done.
Unfortunately most would ignore that since this has never been part of
any standard :-/

Willy

Received on Monday, 12 May 2025 05:51:08 UTC