-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP "Content-Encoding" window size wrt. RFC 8878 #2713
Comments
Specifying a hard limit on the window size for HTTP transfers is not a good solution, IMHO. A global limit that is conservative enough to be of use to resource-constrained endpoints will be harmfully restrictive for use cases which (by prior arrangement or expectation) transport large zstd-compressed objects. I would much rather have standardized an option on the Accept-Encoding item (" Frankly, we might encourage folks to use such a mechanism anyways. If we were to specify a Otherwise, in the absence of a coordination mechanism, I think implementations should just follow Postel's Principle: "be conservative in what you send, be liberal in what you accept". I'm curious to hear more about the experiences you've seen where this is a problem. |
@felixhandte I don't disagree with anything you say, but I think you should be more proactive in your approach. Experience shows that if there is a problem an encoding is rather dropped than having to wait for server implementations to be corrected/catch up. A |
I spoke to a couple people and it sounds like this would be relatively straightforward to specify. I've just spun up a thread on the IETF httpbis mailing list to discuss. Your input there would be appreciated! Edit: link to thread. |
This was discussed in the WebPerf working group at TPAC 2023. Our conclusion was to file an errata against the RFC to request an explicit definition of window size for the "zstd" content-encoding. |
We now have an example of this causing incompatibility in the wild: https://bugs.chromium.org/p/chromium/issues/detail?id=1520682 In a web browser, we can't necessarily trust the servers we connect to, so we can't allocate 2GB of RAM just because the server says so. Being liberal in what we accept isn't going to work for us. Unless someone has a better idea, I will file an errata against RFC 8478. |
Hi @ricea, Yeah, since it turned out that the accept-encoding header does not permit sub-options other than I see a few options that don't involve negotiation, in increasing order of complexity/specificity:
I'm most attracted to option 3, since it's still a fairly simple prescription, but doesn't block the non-browser use case of shipping huge tarballs and stuff around via HTTP where big windows are valuable. What do you think about the practicality of this sort of more nuanced rule? (P.S., we'll want to file it against RFC8878, the updated spec.) |
@felixhandte Option 1. Anything else is just overengineering and will just cause confusion down the line. If client cannot handle that they shouldn't request it - simple. But that is just my humble, outsider opinion. |
There are legitimate use cases (outside of the web domain) for which long Windows is an important capability. Note that protecting the client (receiver) from unreasonable Window Size requirements is already possible when using the reference library (and I believe chrome uses it), so this potential vector of attack is already well covered. After that, deciding which limit is suitable depends on the domain. Setting a limit adjusted for the web domain is a sensible decision. We could possibly strengthen the wording in the RFC to make it more "the" established limit for the web, rather than a suggested one. Such a change of wording would be an outcome of this discussion. |
Option 3 sounds attractive, but Option 2 currently sounds better to me because it provides more predictability and consistency across all use cases, unless otherwise negotiated via an alternate mechanism. If we want to cater to different domains, each one can negotiate a limit suitable for its needs. Chrome does use the |
Hey all, here's what we came up with: In RFC 8878 Section 3.1.1.1.2. Window Descriptor:
would become
What do you think? |
No. Decoders should always support 8MB when requesting zstd encoding in a browser. Otherwise they should not request zstd. Having a vague standard is worse than no standard IMO. |
The deployment scope of Zstandard is not limited to the web. Enforcing 8 MB as an official limit, for both the encoder and decoder, should be specified as limited to a specific domain, |
@klauspost, I see your point. I can also add decoder requirements specific to the web. Something like "Decoders handling web content must support a Window_Size of at least 8 MB." Does that address your concern? |
I'd been working on an internet draft for the window size issue for zstd Content Encoding, as it seemed better than an errata especially given we're trying to change the requirements of the document, and finally got a chance to push it to https://github.com/nidhijaju/draft-zstd-window-size. Hopefully it addresses @klauspost's concern as well about making the 8MB requirement more explicit for HTTP Content Encoding contexts. Please feel free to open any issues on the repo. I also started a thread on the IETF httpbis mailing list at https://lists.w3.org/Archives/Public/ietf-http-wg/2024JanMar/0153.html, so please feel free to leave any comments there. Thank you! |
Love it! |
Issue
It seems to me there is a need for RFC 8878 to specify a maximum window size for using "zstd" Content-Encoding. At least 8MB is recommended as max window size for the decoder, but is not a requirement.
The main issue I see with wide adoption is the risk of having to reject data because of the window size chosen by the encoder.
Describe the solution you'd like
A clear and concise limit on what the max accepted windows size for is HTTP transfers. Then the client has an easy choice, will it accept content with a window up to the limit. If not, it will not add "Accept-Encoding": "zstd".
Describe alternatives you've considered
The alternative is to specify nothing.
In practice what I could see happen is that each client sets its own limit, 64K, 1M, 8MB. The server would either have to just use the smallest accepted window limit (likely) or do client sniffing (unlikely to happen).
Additional context
In my personal opinion even 1MB is rather high. This is considering that browsers often have multiple connections open concurrently to multiple sites.
That said, I can understand you would make it 8MB as per the existing recommendation.
This limit should only apply when using zstd as transfer encoding.
The text was updated successfully, but these errors were encountered: