[RFE] XUL should be added to Accept:

VERIFIED WONTFIX

Status

()

Core
Networking: HTTP
--
enhancement
VERIFIED WONTFIX
17 years ago
14 years ago

People

(Reporter: Jacob Steenhagen, Assigned: gerv)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
I was doing some poking on bug 37339 and figured that it'd be nice to be able to
tell if a browser could accept XUL or not w/out having to parse the
HTTP_USER_AGENT string and try to determine if the browser was known to handle
it (and hoping that the useragent.override wasn't in use).  It seem to me that
the best way to do that would be to include "application/vnd.mozilla.xul+xml" in
the HTTP_ACCEPT string.

I'm going under the assumption that this header is assembled by the HTTP
networking part of the browser... but I could be wrong :)
This should be reassigned to Gervase Markham, "Guardian of the Accept Header".
(Reporter)

Comment 2

17 years ago
-> Gerv, then.
Assignee: neeti → gervase.markham
The header is a pref (and therefore, incidentally, as susceptible to tampering 
as the user agent.) 

The problem is that the header is currently sent out with _every_ request, and 
takes a non-trivial amount of time to send on a 33.6k modem when you are 
sending several requests a second. So, extending its length is a matter of some 
controversy. Key things, like making sure we get XHTML in preference to HTML, 
and HTML in preference to WML, and PNG in preference to GIF, are already 
included. 

However, XUL is (and will almost certainly be for a very long time) the sole 
preserve of browsers with Gecko date strings after (the last incompatible XUL 
change) and marked Mozilla/5. I haven't checked the other Gecko derivative 
browers, except that KMeleon sends "KMeleon/0.4". I assume Galeon does something 
similar.

Therefore, the need for a (long) MIME type in the Accept: header is much 
reduced, and I don't think it's currently justified. Maybe in a year or two, 
when everyone's got broadband, or we implement a way to send different Accept: 
headers based on the context of the request.

So, given that we'll revisit the whole issue then, this is a WONTFIX.

Gerv
(Reporter)

Comment 4

17 years ago
Fair enough. So to detect if I can send XUL, should I just use something like:

if ($useragent =~ m:Mozilla/[5-9][0-9]*: && $useragent =~ m:Gecko:) {
    # XUL is OK
}

[5-9][0-9]* seems to be the easiest way to say 5 or larger in a regular expression
You might want to check the Gecko date string
Gecko/(\d+)
is later than the last incompatible XUL change (which was, IIRC, sometime back 
at the beginning of April.)

You can leave off the [0-9]*. The subversion is irrelevant.

But yes, try that for starters. 

Gerv
(Reporter)

Comment 6

17 years ago
The [0-9]* probably could be left off... I thinking I was being very forward
compatible (ie, when it was Mozilla/10) but because the first character has to
be a 5 or greater, that won't work... and I guess by the time the major version
is larger than 9, things will be much different :)

Marking as WONTFIX so it appears in that list and not in the things to do list.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 7

17 years ago
VERIFIED:
good points, I'm clearing off the open list.
clarified summary. As a general note, we should use summaries that reflect the
data structure in HTTP, not the receiving server terminology (because it might
vary from system to system).
Severity: normal → enhancement
Status: RESOLVED → VERIFIED
Summary: XUL should be added to HTTP_ACCEPT → [RFE] XUL should be added to Accept:
*** Bug 229579 has been marked as a duplicate of this bug. ***

Comment 9

14 years ago
*** Bug 270534 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.