[quicwg/base-drafts] Placeholder limits make for awkward clients (#2734)

[Robin Marx <[e-mail]>]

When chatting a bit about how/when to create placeholders on the server on the slack, there seem to be two camps:

1. Server creates all placeholders it advertises upon sending the SETTINGS frame (full up-front)
2. Server creates the placeholder when it is referenced by the client (as-needed basis)

Argument for not doing 2 seems to be:
> Lazy loading placeholders is a great path to under estimating required resource and getting DoS'd by clients

However, when not doing 2, you will probably limit yourself in the amount of placeholders you allow (e.g., not 100, but more like 10).

So the question becomes: what if those 10 are not enough for the client? Is every complex client required to support two schemes, one with a minimal amount of placeholders (e.g., let's say a server only supports 1 or none), and one where the server allows their needed amount? What about more dynamic schemes, where the placeholder count needed might not be known by the client up-front?

Some potential "solutions" to think about:
- Specifying a minimal value for SETTINGS_NUM_PLACEHOLDER (e.g., 20?)
- Client indicating the amount of placeholders they expect to need in their own SETTINGS, server deciding with some heuristics if it allows that
- New option in which the client can articulate the full placeholder setup in a single packet instead of separate PRIORITY frames (though that doesn't cover the dynamic setup case above)

This may seem like a non-issue, but depending on the prioritization setup we end up choosing (see #2700, #2723, #2690, etc.) a larger amount of placeholders might be required to be able to model all use cases, and then clients really don't want to be limited in the amount they are allowed to use. 


-- 
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/2734