Issue metadata
Sign in to add a comment
|
Standards-incompliant handling of user-agent value
Reported by
keikl...@gmail.com,
Mar 3 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: 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='https://nominatim.openstreetmap.org/reverse?format=json&lat=40.74954&lon=-74.33605&zoom=10&addressdetails=0'; $.ajax({ url: myurl, headers: { 'User-Agent': 'some userAgentString' }, dataType: 'json', jsonp: false, success: function (myjson) { alert('Success'); } }); 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.
,
Mar 4 2018
,
Mar 4 2018
,
Mar 5 2018
@Reporter: Please provide sample test file/URL to check this issue. This would help in triaging the issue in a better way. Thanks!
,
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. Kjell
,
Mar 5 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 5 2018
Chrome/Chromium violates XMLHttpRequest specification since the following WebKit commit in 2009: https://chromium.googlesource.com/chromium/src/+/8104f3312813c07771e26317ae8e39295d9db269%5E%21/#F4 Specification doesn't list "User-Agent" as a forbidden header. https://xhr.spec.whatwg.org/#the-setrequestheader()-method https://fetch.spec.whatwg.org/#forbidden-header-name 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.
,
Mar 5 2018
Evidently a duplicate of issue 571722. Add a star to that issue to raise its importance.
,
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.
,
Mar 7 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by keikl...@gmail.com
, Mar 3 2018