Upgrade failure and Connection: close request header (Re: Adoption call for draft-schwartz-httpbis-optimistic-upgrade)

Hi folks,

This might be a dumb question, but I have one thing to ask regarding the
concerns and the mitigations that we have laid out in
draft-ietf-httpbis-optimistic-upgrade.

IIUC, so far, we have assumed that "a client cannot necessarily begin using
an upgraded protocol merely because it has finished sending the upgrade
request message" on HTTP/1.1, under the rationale that if the server
rejects an upgrade the payload of the upgraded protocol will be considered
the next HTTP request.

Is that true even if the client sent "Connection: close, upgrade",
indicating that the upgrade request is the last request being sent on the
connection?

I'm asking this because if "Connection: close, upgrade" is parsed as such,
clients can retain the opportunity to optimistically start sending the
bytes of the upgrade protocol.

If that does not work (or if it is deemed too risky), I think it might be
worth pointing out in the draft that it is so.

PS. Regardless of how the question turns out, I think the draft is
important and that it is becoming in good shape. Thank you to Ben and
others for all the efforts.

2024年1月24日(水) 2:43 Tommy Pauly <tpauly@apple.com>:

> Hello HTTP,
>
> This email starts a working group adoption call for "Security
> Considerations for Optimistic Use of HTTP
> Upgrade”, draft-schwartz-httpbis-optimistic-upgrade. Notably, this
> updates RFC 9298 (connect-udp, which was produced by the MASQUE WG) on how
> to handle HTTP Upgrade, including to disallow optimistic data sending for
> HTTP/1.1.
>
> The document can be found here:
>
> https://datatracker.ietf.org/doc/draft-schwartz-httpbis-optimistic-upgrade/
>
> https://www.ietf.org/archive/id/draft-schwartz-httpbis-optimistic-upgrade-00.html
>
> This adoption call will last for 3 weeks, until *Tuesday, February 13*.
> Please reply to this email with your reviews and comments, and whether or
> not you think HTTPBIS should adopt this draft.
>
> Thanks,
> Tommy
>


-- 
Kazuho Oku