IE8/9 problem with response

[James Myers]

I had a page loading JSON data for a Dojo EnhancedGrid working just fine in Firefox.

When I tried it in IE8 it failed very mysteriously. After hours of debugging and reading code I discovered that all that was necessary was adding 1 line (the _IGNORE... line).

This looks like a serious Gotcha to me or a bug.  I'm using version 0.2.3.

class GroupMemberView(ResponseMixin, View):

    renderers = DEFAULT_RENDERERS

    _IGNORE_IE_ACCEPT_HEADER = False

.... code ...

   return self.render(response)

[Tom Christie]

Hi James,

  Thanks for pointing that out.  I don't have any easy way to test against IE, so it's really helpful to get some feedback.

I'm slightly surprised actually - the `_IGNORE_IE_ACCEPT_HEADER` behavior is there to avoid some grungy brokenness that IE does.

I've taken another quick look though, and the logic still looks right to me.

Anyways. I'll prob have a chance to look into this properly on Monday, but in the mean time there's a couple of things...

1. What exactly was the broken behavior you were seeing?  I'm presuming you were clicking on the 'application/json' link in the browse-able API, and the page was still rendering in HTML or something like that?

2. Do you see the same broken behavior on api.django-rest-framework.org?

3. Did you install rest framework using pip/easy_install or did you checkout from GitHub/Bitbucket?  (Both are on 0.2.3 ATM)

Thanks,

  Tom

[Jim Myers]

Tom,
1 - I'm using Dojo EnhancedGrid which uses AJAX call to server to get data in JSON format.  The data got sent back as html because_IGNORE_IE_ACCEPT_HEADER defaults to True (at least for IE 8 and 9).
When I set it to False as in my post, the data gets returned correctly as JSON.
2 - didn't try that
3 - I use buildout which uses pypi I believe.

Thanks - Jim Myers

--

Jim Myers

The TBone way, perfection is sacrificed for energy and impact.

[Tom Christie]

Realized I still hadn't replied to this - mostly because I'm still not quite sure what's the right thing to do here.

The problem is that rather than send a useful ACCEPT header letting the API know that the browser would like 'text/html' back in the response, IE sends a whole load of basically useless rubbish.  If REST framework honor's IE's accept header it'll end up sending back json to the request - at least with the current prioritization it gives the renderers.

I'd assumed that the right way to get around the problem would be to simply ignore accept headers from IE, and honor any other Accept headers, which -it turns out - does exactly the right thing _unless_ you're dealing with an AJAX client in IE, which _is_ sending the correct Accept headers (Saying that it'll accept JSON data), which promptly get ignored by REST framework.

As far as I can see the options are:

1. Respect _all_ accept headers.  Re-prioritize the renderers so that html is the default, rather than json.  I'm not super keen on this, because I think that json really ought to be the default.

2. Respect _all_ accept headers, and don't re-prioritize the renderers.  IE users don't get to see the browsable API, they'll just get back json, but at least AJAX clients in IE will work fine.  The browse-able API *can* still be got to using ?format=html.

3. Only respect IE accept headers if the HTTP header "X-Requested-With: XMLHttpRequest" is set - indicating an AJAX request.  Should do the trick in most circumstances, but leaves a dodgy corner case for IE if you're using an AJAX client library that doesn't set that header.

4. Use some other kind of header information to determine if the client is IE and non-AJAX.

I guess I'm leaning towards 3. it's probably the least bad option, and I'm fairly sure most ajax libraries are going to be setting that header now,

but still not totally happy with it.

NB Apparently this is finally fixed in IE9 - http://blogs.msdn.com/b/ieinternals/archive/2009/07/01/ie-and-the-accept-header.aspx

[Yaniv Aknin]

Hi Tom,

This bit me too, and I think option (3) is the best answer, though (2) is also viable (people browsing the API are mostly developers, they probably don't use IE8 and if they do, they deserve it :).

Thanks for a terrific framework,

 - Yaniv