New issue
Advanced search Search tips

Issue 760659 link

Starred by 1 user
Status: Duplicate
Merged: issue 447866
Owner: ----
Closed: Sep 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug



Sign in to add a comment

406 Error for XSLT due to ommission of correct/registered MIME type from Accept header

Reported by argos.ne...@gmail.com, Aug 30 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Edge/15.15063

Steps to reproduce the problem:
1. Navigate to test case: http://staging.anamera.com/3rdPartyBugs/FFdropdown.xml
2. It will request XSLT style sheet FFdropdown.xsl
3. Results in 406 Not Acceptable 

What is the expected behavior?
XSLT style sheet should be loaded and processed by browser.

What went wrong?
Browser's Accept header for XSLT is non-compliant with RFCs. Browser uses "Accept:text/xml, application/xml, application/xhtml+xml, text/xsl, application/rss+xml, application/atom+xml".

However, the correct and registered MIME type would be: "application/xslt+xml".

Chrome needs to INCLUDE "application/xslt+xml" in Accept header for XSLT documents. Servers that follow RFCs will offer "application/xslt+xml" and thus not match Chrome's incomplete Accept header - resulting in the 406 error.

Did this work before? No 

Does this work in other browsers? Yes

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

Confirmed working correctly in IE, Edge, Netscape. Chrome is the ONLY one that fails.
FFdropdown.xml
333 bytes View Download
FFdropdown.xsl
909 bytes View Download

Comment 1 by phistuck@gmail.com, Aug 30 2017 

> Netscape
I sure hope you are not using Netscape anymore. The number of known security issues that browser has by now should be... enormous.

I assume it also does not work in Safari. If so, it is a WebKit originated bug and I suggest that you also file a bug at bugs.webkit.org for completeness.

According to Wikipedia, by the way (I know, not the authoritative source, but still), XSLT 2.0 onward uses the MIME type you mentioned, however - I do not think browsers support (or completely support) XSLT 2.0. It also mentions that browser use the technically incorrect text/xsl.

Using BrowserStack -
Firefox and Edge send */*, by the way (at least according to their Developer Tools features).
Internet Explorer 11 does not report the request headers for that request, but it formats the XML, so it sends something acceptable.
Safari fails due to the same Accept header Chrome sends.


While Safari and Chrome are being too specific and somewhat wrong in their MIME types - in my opinion, your server should also accept that reality (at least according to Wikipedia).

Comment 2 by phistuck@chromium.org, Aug 30 2017

Components: Blink>XML Blink>Loader
Labels: OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Also, you seem to be using a pretty outdated version of Chrome that has a lot of known security issues, which may get you hacked. I strongly recommend that you update your browser immediately (the bug exists in the new version as well, I tested it).

Old browser versions are really dangerous...

Comment 3 by argos.ne...@gmail.com, Aug 30 2017 

Sorry - too many issues at the same time. Correct - NOT Netscape, Firefox.
Also tested with Chrome 60.0.3112.113, but didn't catch that the bug form autofilled version 52. 
Yes, confirmed that Safari has same bug - so your hint regaring WebKit might be applicable.

Problem with outputting NON-standard MIME type is, that it causes problems with other browsers in other areas. 

I have no problem with maintaining backward compatibility but there is no valid reason to reject the registered MIME type that dates back several YEARS.

Comment 4 by yhirano@chromium.org, Sep 29 2017

Mergedinto: 447866
Status: Duplicate (was: Untriaged)
►

Sign in to add a comment