-
Notifications
You must be signed in to change notification settings - Fork 336
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
Use case for Headers getAll #973
Comments
It might make sense to expose it properly for code that wants to use this class generically, but I think we ought to allow for implementations of this class to eagerly combine headers generally and store |
It's probably also worth investigating if https://www.npmjs.com/package/set-cookie-parser#splitcookiestringcombinedsetcookieheader is a reasonable alternative to expose. Though if that actually works HTTP would not have to consider cookies a special case... |
Maybe to clarify the environment a bit, Cloudflare Workers boils down to a proxy written in JavaScript and Node.js a HTTP client.
For such use-cases, it make sense to not filter headers in the response and let the user define its own headers. Any custom headers may contain |
I disagree, HTTP doesn't guarantee intermediaries won't combine such headers so we shouldn't either. I'd want HTTP to call out more than |
I'm a bit confused why we'd revisit this. Non-browser environments can consider adding nonstandard extensions for whatever purpose they wish, but in browser environments there's no need for this functionality, and our reasoning from the previous discussions seems to hold. (And the spec is written for browser environments.) |
We don't forbid appending |
We are considering adding the getAll method for Cloudflare Workers, I don't know Node.js' plans. With a basic filtered response you can access almost all the headers. I think this behavior can still happen in a browser. |
To be clear,
and
for any name other than |
In Cloudflare Workers, we'd really like to stick to standard APIs, to promote code portability across a wide range of JavaScript environments. We think it would be a great thing for the JavaScript ecosystem as a whole if common functionality like making HTTP requests actually worked the same everywhere, so it would be nice to see the We have an immediate need to support manipulation of Set-Cookie in Cloudflare Workers. Perhaps ironically, this is actually driven by a request from @rowan-m on the Chrome team related to the default SameSite=Lax change. A lot of people are going to need to work around this soon and doing it in CF Workers will likely be easier for many people than updating their backend code. We are proceeding with implementing |
I think that's a really unfortunate decision. I think you'd be better served by clearly signposting nonstandard APIs (e.g. using a Cloudflare global), instead of assuming that things which existed briefly in the spec but were never implemented anywhere have some sort of semi-standard semantics. |
|
@annevk Yes, I understand the issue -- for headers other than Set-Cookie, the header values may be comma-concatenated anyway by any intermediate proxy, so Do you have a recommendation for how we should proceed, in order to both solve the immediate problem and stay standards-compatible long-term? |
Again, not just by any intermediate proxy, by an implementation of the
|
|
What about This has the advantage that if ever there comes along another such header (probably, a non-standard header used by some badly-designed HTTP API that one of our customers really really needs to support), we can easily accommodate... |
@youennf @yutakahirano @ddragana @whatwg/http thoughts? |
I looks like we cannot read Set-Cookie if we once have set it, therefore I am for adding some function for this. |
cross-posting a suggestion from @nfriedly on #506 - use https://www.npmjs.com/package/set-cookie-parser#usage-in-react-native to parse the mangled cookie header The fact that this inconsistency is still around is mind boggling to me |
For future reference, this is how we solve this in Deno's fetch implementation:
This was the solution of us trying to come up with a solution for multiple years. We deem this breaks the least existing code, while also being relatively easy to understand and use. |
For the record, Cloudflare Workers went ahead with what I suggested in my last comment -- |
Am I correct that step one of what @lucacasonato proposed in #973 (comment) has now been completed and the impact of special handling Was the conclusion to adopt an implementation like Deno's or to add a |
The latter, see #1346. It's currently stuck on getting implementer interest from two browsers. |
This commit adds a UseCounter that tracks if a site in any way sets a header with the name "set-cookie" on a Headers object with a guard of "request". This is done to verify if it is a web compatible change to add "set-cookie" to the request forbidden header list. See whatwg/fetch#973 (comment) Bug: 1292458 Change-Id: I1edd161d941d6490838b77a2fec008de904793ad Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3423793 Reviewed-by: Yutaka Hirano <[email protected]> Commit-Queue: Yutaka Hirano <[email protected]> Cr-Commit-Position: refs/heads/main@{#965654} NOKEYCHECK=True GitOrigin-RevId: 4fa1c0bf6242c7bbdf97d25426d0dea7c7aa644c
As per whatwg/fetch#1453, the "Set-Cookie" header is added to the list of forbidden request header names in the Fetch spec. This is because the "Set-Cookie" header is semantically a response header, so it is not useful on requests, and we want to avoid leaking the complexity of handling them in requests. This CL implements this change. The impact of this change was already verified using a UseCounter[1], which showed that the % of pages that set a "set-cookie" header on an outbound fetch request hovers around 0.0003%. Additionally, the two popular domains that set a "set-cookie" header on request headers continue to work even when all outbound "set-cookie" headers were removed [2]. Hence, this change was deemed to be safe to make. Some tests depended on the assumption that there are no overlapping header names for forbidden request and response headers, which made tests fail as 'Set-Cookie' exists in both lists of forbidden names now. This has been fixed in this CL by finding the non-overlapping header names. As this change is sufficiently small, an intent to ship is not being sent, but the enterprise team were notified to include this in the release notes and a PSA to blink-dev was also sent[3]. [1] https://chromestatus.com/metrics/feature/timeline/popularity/4152 [2] whatwg/fetch#973 (comment) [3] https://groups.google.com/a/chromium.org/g/blink-dev/c/SyHAsPfO004 Bug: 1337091 Change-Id: Idf8ffd9c1169e5b9045c5a7e282c4fbdda00f550 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3709684 Reviewed-by: Yutaka Hirano <[email protected]> Reviewed-by: Shakti Sahu <[email protected]> Commit-Queue: Nidhi Jaju <[email protected]> Cr-Commit-Position: refs/heads/main@{#1016574} NOKEYCHECK=True GitOrigin-RevId: d77381726e0abdf260324bde656ff37620199f87
FWIW, using I think |
In my opinion, both of these options are bad, and |
FWIW Cloudflare Workers' implementation of However, the ship has clearly sailed here, |
what about X-Robots-Tag for example where rules specified without a user agent are valid for all console.log(
new Headers([
['x-robots-tag', 'noindex'],
['x-robots-tag', 'unavailable_after: 25 Jun 2099 15:00:00'],
['x-robots-tag', 'somebot: nofollow'],
['x-robots-tag', 'otherbot: noindex, nofollow'],
['x-robots-tag', 'noarchive'],
]).get('x-robots-tag')
==
'noindex, unavailable_after: 25 Jun 2099 15:00:00, somebot: nofollow, otherbot: noindex, nofollow, noarchive'
) now is the noarchive rule for all or just for otherbot ?! |
If you cannot split on comma, then |
where in the HTTP spec does it say that ? |
You always have to put the |
they "should" but what to do when a server sends them after other ua rules? |
Since 42464c8
Headers.prototype.getAll
has been deprecated/removed from the spec and implementations.I understand that in browsers (including service workers) filtered responses don't include headers that could benefit from the getAll method.
However, some JavaScript environment doesn't need to filter response/request headers, like serverless plateforms (for instance Cloudflare Workers) or maybe Nodejs at some point.
For example editing Cookie headers:
Spliting the combined header value by
,
will give an invalid result. InsteadgetAll
could be used to retrieve the individual headers.The text was updated successfully, but these errors were encountered: