-
Notifications
You must be signed in to change notification settings - Fork 56
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
Support appending to User-Agent header in declarativeNetRequest #398
Comments
Is the use case behind the request publicly visible? I'd be interested in learning more about the use case. The requested behavior sounds reasonable, including the request to concatenate additions with a space. During the meeting (meeting notes pending to be merged at #397), I mentioned that additions to the User-Agent are separated by semicolons. This was referring to historical behavior in Internet Explorer. Plugins (external software in general) could insert parts in the User-Agent header by setting the P.S. This ticket here is about the "append" operation. It is already possibly to completely overwrite the User-Agent header with the "set" operation. If Chrome ends up supporting "append" for "user-agent", then we should add that to the list of headers at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/declarativeNetRequest/ModifyHeaderInfo#header_limits |
Perfect, thanks for taking a look and updating the label :)
Sure, you can see the CL here. That said, I'm not advocating for the merits of that specific use case. This simply prompted us to re-consider if this should have been on the list and we can't see a reason it shouldn't be. |
I had a similar use case but had to put in a workaround a few years ago due to lack of support for setting User-Agent at all in Chrome at that time: load balancer and web server logs usually log the User-Agent header by default which can be useful for debugging the cause of errors with our API (e.g. a specific extension version is the cause of all the HTTP 503 errors for a specific path). The extension I'm referring to would only append the extension version to the header on requests to our own API server, not to other origins. |
I know it's not contradictory, but Chrome has been pushing for User-Agent reduction. |
Chromium 116 will likely support this feature: chromium/chromium@b58ff2e |
Thanks for the callout @bershanskiy, as you say this will be in M116. Adding the implemented label. |
In Chrome's implementation of declarativeNetRequest, we have an explicit list of headers that we allow the "append" HeaderOperation to be applied to.
We're considering adding "User-Agent" to this list following a developer request. We discussed that in the last meeting and there was general support, but some discussion around what separator character to use.
Looking at the examples on MDN, it seems like a space is the most common character here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent
This also matches the spec, which says it should follow the form
User-Agent = product *( RWS ( product / comment ) )
. Based on my understanding this is basically saying you can have as many products as you like and they are separated by whitespace.Based on this, I propose allowing this header and making whitespace the character automatically added internally between each appended value.
The text was updated successfully, but these errors were encountered: