Subject: [quicwg/base-drafts] Semantics of SETTINGS_MAX_HEADER_LIST_SIZE (#2516)

From: Kazuho Oku <[email-masked]>
Date: Mon, 11 Mar 2019 15:03:25 -0700

Semantics of SETTINGS_MAX_HEADER_LIST_SIZE in unclear. We should either:

* state that it's an advisory value that an endpoint is permitted to ignore. Otherwise, an endpoint written under the impression that it's a value to be enforced might terminate the connection (note: H3 allows a stream error to be promoted to a connection error) thereby disrupting other HTTP requests inflight.
* state that an endpoint must not exceed the value advertised by the peer.

spun off from #2510 #2512.

-- 
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/issues/2516

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 11 Mar 2019 15:07:00 -0700

My preference goes to being strict. Quoting from 
https://github.com/quicwg/base-drafts/pull/2510#issuecomment-47171000:
> Think it from an end-user perspective. Without the restriction, we might see one user-agent telling you that the request is too large, and the other processing the same request. That'd be confusing.

I also think that what @dtikhonov points out in 
https://github.com/quicwg/base-drafts/pull/2510#issuecomment-471716253 is an argument for making this an enforcement (or drop the settings entirely). Unless we do so, implementations would be tempted to ignore the setting for "maximum interoperability," making the feature meaningless.

-- 
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/issues/2516#issuecomment-471756391

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 11 Mar 2019 15:30:18 -0700

Thanks for creating the issue @kazuho!

Do we have some deployment experience that can weigh in here. I've heard anecdotal stories that nginx ignores the setting in HTTP/2 by default. And I've found an interesting Chrome crbug that also mentions HTTP/2 load balancers - https://bugs.chromium.org/p/chromium/issues/detail?id=751642* 

-- 
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/issues/2516#issuecomment-471765564

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Mar 2019 15:58:38 -0700

We have experience from HTTP/2, where it was clear that no intermediary was ever in a position to comply.  The setting is hop-by-hop and header fields are end-to-end, so there is an inherent incompatibility.  I don't see any stack being able to comply with a limit that is too low for the current message.  I'd prefer to see it removed if it came to that.

-- 
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/issues/2516#issuecomment-471773724

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Mon, 11 Mar 2019 18:27:06 -0700

I agree to removing it.

-- 
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/issues/2516#issuecomment-471809734

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 12 Mar 2019 05:31:54 -0700

I, too, think that removing this setting is fine.

-- 
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/issues/2516#issuecomment-471980815

---

From: MikkelFJ <[email-masked]>
Date: Tue, 12 Mar 2019 05:51:22 -0700

Does this mean constrained devices will not need a control stream?

-- 
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/issues/2516#issuecomment-471987030

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 12 Mar 2019 23:30:12 +0000 (UTC)

My own $0.02... I would much prefer to have this and treat it more strictly. In my experience, explicit limits are much easier to reason about than hidden limits. I'd much rather fail a request early than send it to a peer only to have it fail with a limit that I know nothing about. 

-- 
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/issues/2516#issuecomment-472220338

---

From: afrind <[email-masked]>
Date: Wed, 13 Mar 2019 13:30:18 -0700

I agree why Ryan.  Any reasonable server is going to have a limit and will have to fail requests that violate it.  It's better to have this be explicit.  

-- 
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/issues/2516#issuecomment-472592870

---

From: ianswett <[email-masked]>
Date: Wed, 13 Mar 2019 20:48:07 +0000 (UTC)

Agreed, explicit limits are good.  Unexpected failures are not.

In the case of proxies, it seems like the min of the received setting and local limit could be used?

-- 
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/issues/2516#issuecomment-472599257

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 13 Mar 2019 13:56:22 -0700

If this limit is not advisory, there is a good chance that some web applications will break once the underlying server is upgraded to HTTP/3.  The reason is that HTTP/2 servers ignore limits sent by the clients and the browsers just take it.  Hackish?  Yes.  But it works.

-- 
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/issues/2516#issuecomment-472602071

---

From: MikkelFJ <[email-masked]>
Date: Wed, 13 Mar 2019 14:06:09 -0700

How about SHOULD enforce, but MAY be configured to ignore, or use a higher multiple for compat reasons.

-- 
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/issues/2516#issuecomment-472605371

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 13 Mar 2019 14:22:29 -0700

An optional limit that's rarely enforced and, perhaps worse, unpredictably enforced seems like a waste of a limit. 

Implementations already have limits on the size of individual headers, which trigger semantic layer errors. Why does the sum total need to trigger a syntax type of error?

Enforcing error makes this stricter than H2, hurting interoperability between implementations that support H3 and H2 at the same time. 

Speculating, I can see this causing some strange issues in the wild, where clients Alt-Svc up to H3, encounter a sporadic error and then purge H3 endpoints from their Alt-Svc cache. 

-- 
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/issues/2516#issuecomment-472610912

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 13 Mar 2019 14:42:33 -0700

Yes. The problem here is the difficulty of the sender of the headers block complying to the limit advertised by the peer. Therefore, "SHOULD enforce" does not work as a fix.

@ianswett 
> In the case of proxies, it seems like the min of the received setting and local limit could be used? But I guess the proxy mah not know all backends it may contact when it advertises a limit. I still think something is better than nothing, but I'm not sure how to fully solve the proxy case.

FWIW, there are at least two issues regarding proxies.
* Downstream (e.g., origin server in case of a HTTP request) having smaller limits. In such case, the proxy will read the request then send a LIMIT_EXCEEDED error without forwarding the request.
* A proxy that streams the headers block. Such a proxy cannot tell the uncompressed size of the headers block until it receives the last byte of the HEADERS frame. But by the time that is observed, it would already have started sending the headers to the downstream.

-- 
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/issues/2516#issuecomment-472617433