Re: Mahesh Jethanandani's No Objection on draft-ietf-httpbis-optimistic-upgrade-05: (with COMMENT)

________________________________
From: Mahesh Jethanandani via Datatracker <noreply@ietf.org>

...

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I also agree with Gorry that the abstract wording could be updated to explain
> the true purpose of the document.

Please let me know if the additional text in (https://github.com/httpwg/http-extensions/commit/ae6203dbff9fd7aea707df98c4d12b640fa5c4bd) is not sufficient.

> Section 5.3
> > A client MAY optimistically start sending UDP packets in HTTP Datagrams
> before receiving the response to its UDP proxying request, but only if the HTTP
> version in use is HTTP/2 or later. Clients MUST NOT send UDP packets
> optimistically in HTTP/1.x due to the risk of request smuggling attacks.
>
> The guidelines for the client are great, but shouldn’t there be a similar
> requirement for the server. Something along the lines of “If a server receiving
> UDP packets optimistically in a session that is HTTP/1.1 and has received a
> Upgrade Request but has not responded to that request, it should drop all the
> UDP packets received optimistically”.

This idea presents two problems:

1. Technical problem - CONNECT and Upgrade server implementations typically do not start reading the new protocol data until after they have processed the request headers and emitted a response message.  Once the response message is written, the server has no way to know whether subsequent bytes were transmitted optimistically.  While some servers may be able to detect disallowed optimistic data in some cases, it cannot be detected reliably.
2. Standards problem - These client requirements are mandatory: sending optimistic "connect-udp" data would be a protocol violation.  It would be unusual for us to instruct servers to permit or mitigate a forbidden client behavior.

> Something similar should be mentioned in Section 7 for the CONNECT method also.

Instead of attempting to detect optimistic CONNECT data (which is not possible in general), Section 7 requires servers to make optimistic transmission safe, by closing the connection when a CONNECT request is rejected (unless the client is known to apply its own safeguards).

--Ben