IE bug with HTTP_ACCEPT HTTP header, and workaround
Internet Explorer only sends an "HTTP_ACCEPT" header once per HTTP session.
To see the bug, load this page once in IE and below you'll see the HTTP_ACCEPT header which your browser sent to the server.
Reload and it becomes just "*/*".
Fortunately, you can work around this by capturing that info elsewhere the first time it's sent.
My Workaround Code (ASP):
Run this where needed and then you can then use
Request.Cookies.Item("HTTP_ACCEPT") in place of
'IE HTTP_Accept workaround: Cookie should last the duration of the browser's HTTP session.
IF Request.Cookies.Item("HTTP_ACCEPT") = "" THEN
Response.Cookies.Item("HTTP_ACCEPT") = Request.ServerVariables("HTTP_ACCEPT")
- Why is this bug bad? My bug discovery experience was this: I needed to write code to decide whether to return data as an Excel spreadsheet or as a CSV text file. I've heard of similar needs with smartly sending content-types for XHTML (a different IE bug).
- Info: An HTTP session differs from the Session in ASP/.Net & other server-side platforms. Importantly here is that (I think) it lasts as long as the browser is open (same place Integrated Authentication credentials are cached, I'd guess).
- AFAIK, this only affects Internet Explorer (tested on v6).
- Another good workaround is to vary the URL by changing meaningless data in the querystring, e.g. this.
Of course, this also breaks browser-side data-caching, which can be a performance hit.
- Another possible workaround is to somehow suppress the HTTP_CONNECTION header (which defaults to "Keep-Alive").
Response.AddHeader("HTTP_CONNECTION", "anything") doesn't work
(perhaps because it's a built-in header, and can't be changed? Ideas are welcome.)
- Another bad workaround is to do the same "grab/store" technique with an ASP (or whatever) session. This fails as soon as the ASP session times out.
-Rob Eberhardt (@throbs.net)