New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 818427 link

Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 571722
Owner: ----
Closed: Mar 2018
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment

Standards-incompliant handling of user-agent value

Reported by, Mar 3 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

Steps to reproduce the problem:
Any recent version of jQuery:
var myurl='';
        url: myurl,
    	headers: { 'User-Agent': 'some userAgentString' },
        dataType: 'json',
        jsonp: false,
        success: function (myjson) {

What is the expected behavior?
Ajax call without any console error message from Chrome.

What went wrong?
Console reports 'Refused to set unsafe header "User-Agent"'.  Chrome keeps standard User-Agent string and function sometimes correct answer, other times fails.  Any User-Agent string will give a console error message.

Did this work before? No 

Does this work in other browsers? N/A

Chrome version: 64.0.3282.186  Channel: stable
OS Version: 10.0
Flash Version: 

More and more sites now require a specific user-agent for load balancing and access control, for example OSM. The standard on being able to set User-Agent was changed in 2015. Both Edge and FireFox have implemented this, but apparently not Chromium yet.

Comment 1 by, Mar 3 2018

NB! Forgot to set that this works in latest versions of both FireFox and Edge!
Labels: Needs-Triage-M64
Components: Blink>Network>XHR
Labels: Triaged-ET Needs-Feedback
@Reporter: Please provide sample test file/URL to check this issue. This would help in triaging the issue in a better way.


Comment 5 by, Mar 5 2018

Hi, here is a simple file that demonstrates the problem.  You will most likely get the result from OSM that location is "Livingson, US", but the console states that the User-Agent was not changed.  

OSM and many other resources now require identification via the UA (ref OSM license terms!), passing the browser's UA means that access is likely to be pooled with everybody else using a given UA, resulting in throttling and many times that the query is rejected/timed out. 

1.2 KB View Download
Project Member

Comment 6 by, Mar 5 2018

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit - Your friendly Sheriffbot

Comment 7 by, Mar 5 2018

Chrome/Chromium violates XMLHttpRequest specification since the following WebKit commit in 2009:

Specification doesn't list "User-Agent" as a forbidden header.

On the contrary, the spec implicitly states it's allowed to be set by a user:

  > 11. If httpRequest’s header list does not contain `User-Agent`, 
        then user agents should append `User-Agent`/default `User-Agent` value to httpRequest’s header list.

Comment 8 by, Mar 5 2018

Evidently a duplicate of issue 571722.
Add a star to that issue to raise its importance.

Comment 9 by, Mar 5 2018

Yes, issue 571722 seems to have same bug profile.  Starred it, but worrisome that the bug has been outstanding and awaiting fix for two years, and now the issue owner has left the project.   

In the past week alone, I've had to add bespoke User-Agent strings to two REST services to maintain app functionality, and with one I had lost complete functionality with the default UA.  I hope more people will see the need to address the big with priority now. 
Mergedinto: 571722
Status: Duplicate (was: Unconfirmed)

Sign in to add a comment