IE content negotiation getting cdn.mathjax.org

[Mike Pearson]

When fetching http://cdn.mathjax.org/mathjax/latest/MathJax.js there
can be problems with content negotiation in Internet Explorer. This
can show up as a javascript error on reading the first character of
the file which is delivered as gzip compressed, but then not decoded.

In Internet Options two settings can be used to avoid the problem:

The first is "Use HTTP 1.1", which must be set

The second is "Use HTTP 1.1 through proxy connections" which should
also be set, but commonly isn't.

The problem is that if IE duses HTTP 1.0, it does not send an Accept-
Encoding gzip field in the HTTP get request. The MathJAX cdn ignores
this and delivers gzip encoded content anyway, which IE proceeds to
treat as plain text.

I don't know how other browsers handle HTTP1.0, but should it not be
the case that MathJAX delivers uncompressed content when an HTTP 1.0
request comes in without Accept Encoding set to allow gzip?

Mike

[Sean Hogan]

Thanks Mike. Do you have statistics for this?

From what I've read, it was only early versions of IE6 that degraded to
HTTP 1.0 through proxies. I've just checked my installations of
IE6/7/8/9 and IE6 had "use HTTP 1.1 through proxy connections"
unchecked, but the others had it checked. (I haven't modified the
settings, but that doesn't mean they are representative for all).

The problem with trusting the Accept-Encoding header is that there are
proxies and browser add-ons that strip the header, even though the
browser is capable of receiving compressed content.

There are several sites using the CDN, and I'm not aware of any
confirmed reports of this problem.

regards,
Sean

[Davide P. Cervone]

Sean:

We have had several reports of people saying IE complained about the
first character of the file, so I think we've seen this before, and I
was glad to see an explanation for it, plus a work-around. I do not
recall what version of IE was involved, and haven't gone back to look
up the messages.

Davide

[K.J.Mcconway]

Hi Sean,

Maybe I can help, since it was me that originally reported this to Mike as a problem I was having, and I did some of the investigation that led to Mike's report.

I don't have any statistics. Maybe it's rare, maybe not.

To cut a long story short, I was having problems with the MathJax on Mike's site, where all that showed up was the original markup and not any kind of processed maths (and also no right-click context menu). This also happened in just the same way on the mathjax.org site. However, this was only when I used certain computers. One is inside a firewall at my work and hence always goes through a proxy server. On the other, a laptop, it worked fine except when I was connected through the LAN or through the VPN at my work, where it goes through a proxy server again (the same one, I believe). Both machines were set up by my work's IT people - one has IE8 (Windows XP) and the other IE9 (Windows 7) and both had the "Use HTTP 1.1 through proxy connections" unchecked. (I have no idea why, since I don't think this is the default, as you point out below, and I did not change the setting myself.) When I checked that option, the MathJax on Mike's site worked properly through the proxy on both machines (and, incidentally, it always worked fine using Firefox on both machines, because although I see that you can turn off using HTTP1.1 through proxies on Firefox too, nobody had done so - I haven't tested to see what would happen if I turned that off).

More playing about and looking at the HTTP headers live did establish that (in IE8 - I didn't have time to check IE9), when "Use HTTP 1.1 through proxy connections" was unchecked and I was going through a proxy (well, this particular proxy), the GET for the js from cdn.mathjax.org did not include any accept-encodings flag, but the file arriving at my PC did have a header indicating it was gzipped (and indeed, it /was/ gzipped, because if I simply saved it instead of trying to use it in Mike's and your web pages, I could uncompress it and read the javascript with no trouble). But IE8 was not unzipping it and was then reporting that it couldn't read the first character in the .js file (presumably because it was still compressed). This was stopping mathjax from working. I could send you copies of the HTTP headers if you like (but I can't do any more testing on that system because I'm on holiday, and similarly I can't ask why things were set up this way till I get back).

Regards,

Kevin McConway

regards,
Sean

--
The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).

[Sean Hogan]

I've done some more testing.

For reference, the MathJax CDN is currently configured to always gzip
content (except for image files) and appropriately set the
"Content-Encoding: gzip" header. This occurs irrespective of whether the
request contains the "Accept-Encoding" header. This is done because some
proxies and browser add-ons strip this header, even though the browser
is capable of receiving gzipped content.

My results are below, but in summary it seems that
a) all versions of IE ignore the "Content-Encoding" header when the
browser is restricted to HTTP 1.0
b) all other browsers always recognize the "Content-Encoding" header,
irrespective of HTTP version.

Results:

1. In IE6/8/9 I turned OFF the "Use HTTP 1.1" setting, cleared the
cache, restarted, and tried browsing to
http://cdn.mathjax.org/mathjax/latest/test/sample.html

In each case the browser displayed a page of garbage. This is what you
would expect if the browser is ignoring the "Content-Encoding: gzip"
header.

In IE9 I used the Developer Tools to view HTTP headers. It showed that
the request and response were HTTP 1.0, and that the response contained
the "Content-Encoding: gzip" header (all as expected).

2. In Firefox I went to about:config and set the "network.http.version"
to "1.0". I cleared the cache, restarted, and browsed to the
aforementioned page.

The page appeared as expected with rendered math.

Firebug did not display the version of the HTTP request or response, but
did confirm that the "Content-Encoding: gzip" header was in the
response. Additionally it indicated that the request had the
"Accept-Encoding: gzip,deflate" header. This can be turned OFF using the
"network.http.accept-encoding" config option, but this did not affect
Firefox's ability to interpret the accessed files (i.e. the test-page
still displayed as expected).

3. I couldn't find a setting for HTTP version in Safari or Chrome.

4. In Opera I configured a proxy and chose not to enable HTTP 1.1
through proxies. I cleared the cache, restarted, and browsed to the test
page.

The page appeared as expected with rendered math.

The Dragonfly debugger illustrated that the browser still sends the
Accept-Encoding header in its request, and still accepts
Content-Encoding in its response.

[K.J.Mcconway]

Just to say this is all in accord with what I found, and much more extensive - my only addition is that I had used ieHTTPheaders in IE8 and the Live HTTP Headers add-on in Firefox to see the HTTP request and response. In Firefox this was done only using HTTP 1.1 so did not tell us anything interesting except that everything was working properly. In IE8, which was at the time set to use HTTP 1.0 through proxies, and I was going through a proxy, it was as you'd expect from the description below; the request had no "Accept-Encoding" header and the response had a "Content-Encoding: gzip" header which was ignored by IE8, producing garbage and a warning message in IE about the js file beginning with an unreadable character.

One could argue about whether it's right for a browser to uncompress a file that it receives which it didn't expect to be compressed, but that's a bit pointless (and I think there are arguments both ways anyway) - the current position is that it works differently in different commonly used browsers, but only with HTTP 1.1 turned off, and I've no idea how prevalent that is.

There is however still a question of whether the MathJax CDN should be configured, as it currently is, to gzip content regardless of whether the request contains the "Accept-Encoding" header. I take the point about the header sometimes being stripped, but the question then is whether it's best to send a gzipped reply if there's no header, or to send an uncompressed reply. As it now is, gzipping everything reduces traffic quite a bit, I imagine, compared to having it send uncompressed content when there's no "Accept-Encoding" header in the request, but at the cost of it not working for an unknown (to me anyway) number of users who are using IE with HTTP 1.1. turned off.

Kevin

Results:

--

[Sean Hogan]

In lieu of real numbers, I would guess the decision to start sending
uncompressed content in the absence of "Accept-Encoding" depends on
whether there is a default group-policy in Windows Server to disable
HTTP 1.1 over proxy connections.

So if Win Server 2008 had this default then we should probably change.
Same for Win Server 2003.
Probably not for Win Server 2000.

Of course, if we get numerous confirmed reports of this issue we should
probably change anyway.

Sean