Re: [quicwg/base-drafts] Brian Kaduk's nits on HTTP/3 (#4810)

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.

One change here looks a little off.

> @@ -1908,13 +1920,13 @@ A client can discard responses that it cannot process.
 
 ### CONNECT Issues
 
-The CONNECT method can be used to create disproportionate load on a proxy,
-since stream creation is relatively inexpensive when compared to the creation
-and maintenance of a TCP connection.  A proxy might also maintain some resources
-for a TCP connection beyond the closing of the stream that carries the CONNECT
+The CONNECT method can be used to create disproportionate load on a proxy, since

```suggestion
The CONNECT method can be used to create disproportionate load on a proxy, as
```

> +Therefore, a proxy might delay increasing the QUIC stream limits to account for
+the resources consumed by CONNECT requests.

The original text existed to note that accounting for streams as requests is insufficient in the case that a CONNECT request is used.  Delay does no good.  What we might instead say is that any proxy that supports CONNECT might choose to limit the number of concurrent CONNECT streams it accepts (and account for the higher cost of those streams when considering overall resource allocation).

> @@ -2267,6 +2286,10 @@ of time.  HTTP/3 servers might choose to permit a larger number of concurrent
 client-initiated bidirectional streams to achieve equivalent concurrency to
 HTTP/2, depending on the expected usage patterns.
 
+In HTTP/2, only request and response bodies (DATA frames) are subject to flow

```suggestion
In HTTP/2, only request and response bodies (the frame payload of DATA frames) are subject to flow
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4810#pullrequestreview-575100683