Drop application/xml from the Accept header

RESOLVED WONTFIX

Status

()

Core
Networking: HTTP
RESOLVED WONTFIX
6 years ago
2 years ago

People

(Reporter: hsivonen, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

6 years ago
Firefox currently sends the following header when loading stuff to a docshell:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

IE9 sends:
Accept: text/html, application/xhtml+xml, */*

That's 26 bytes shorter.

We could make ours 28 bytes shorter than now by omitting spaces from what IE sends:
Accept: text/html,application/xhtml+xml,*/*

Our UA string was developed in an era when we still believed that an XML-based Web was the future. That future didn't come. Still, enough sites on the fringes started sniffing for application/xhtml+xml in the Accept header that IE9 added it. However, the application/xml part seems mostly unnecessary even for the few sites that bought into XHTML.

I suggest we make each of our HTTP requests 28 bytes smaller by changing the header to:
Accept: text/html,application/xhtml+xml,*/*
I agree with the principle. Do we still need a lower q value for */*? That's not implied by the ordering, AIUI.

Gerv
(Reporter)

Comment 2

6 years ago
(In reply to Gervase Markham [:gerv] from comment #1)
> I agree with the principle. Do we still need a lower q value for */*? That's
> not implied by the ordering, AIUI.

I believe we don't need a lower q value for */*.

As I understand it, */* is there for servers that would respond with 406 Not Acceptable otherwise. application/xhtml+xml is there for sites that check if application/xhtml+xml is acceptable and otherwise fall back to text/html meant for IE8 and earlier. Those sites negotiate between text/html and application/xhtml+xml--not between those and some third format that they'd internally prefer more.

Actually, it's not clear that the text/html part is needed for compatibility with legacy sites...

Comment 3

6 years ago
I wonder if people are using Accept: application/xml to decide whether they can rely upon XSLT support in the browser. That's the only reason I can see for it being sent.
(Reporter)

Comment 4

4 years ago
(In reply to mnot from comment #3)
> I wonder if people are using Accept: application/xml to decide whether they
> can rely upon XSLT support in the browser. That's the only reason I can see
> for it being sent.

IIRC, we put it there, because we believed in the XML dream at the time. IIRC, there was no XSLT motivation. By now, there could of course be XSLT-using sites that expect to see application/xml there. :-(
I think compat needs to be the order of the day here, and xml is part of the chrome accept header.. so I think we ought to hold fast for now
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.