Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#18648 closed Bug (needsinfo)

ConditionalGetMiddleware does not work with Internet Explorer

Reported by: KyleMac Owned by: nobody
Component: HTTP handling Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

For whatever reason Internet Explorer (tested 9 and 10) append the original uncompressed content length to the end of If-Modified-Since and so it fails to parse in ConditionalGetMiddleware.

The header I'm seeing in Fiddler from IE9 is the following:

If-Modified-Since: Thu, 19 Jul 2012 12:48:50 GMT; length=51894

Change History (5)

comment:1 by anonymous, 12 years ago

This only seems to happen with runserver so it's probably a header issue.

I'm going to guess that it's due to runserver responding with HTTP 1.0 which triggers the behaviour in Internet Explorer. I don't see why the other headers added by Apache would make a difference.

comment:2 by Preston Holmes, 12 years ago

Resolution: needsinfo
Status: newclosed

assuming comment 1 was from the OP - this seems to potentially not be related to the middleware - as that would send the same headers either through runserver or Apache/WSGI

An incompatibility between runserver and IE probably is going to be a very low priority - as a development server can't be expected to chase browser quirks.

The actual problem needs to be clarified more than "failing to parse in IE" before this could be accepted

comment:3 by KyleMac, 12 years ago

Yes, the anon comment is me.

The reason the middleware fails to parse the header from IE is pretty simple. The whole header value is passed to parse_http_date_safe which returns None due to the extra stuff IE adds to the end. The simple fix is something like:

if_modified_since = parse_http_date_safe(if_modified_since.split(';')[0])

This bug has nothing to do with the middleware adding headers but is instead about how it parses headers sent by the browser. The mystery is what does runserver do that causes IE to send an invalid header while IE responds to Apache + mod_wsgi with a valid header.

This bug is minor but really annoying if you're actually developing views that are meant to be cached. Since Webkit, Firefox and IE all have slightly different caching behaviour you do need to test thoroughly in each browser and this bug makes that harder.

comment:4 by harm, 12 years ago

Resolution: needsinfo
Status: closednew

more info provided in comment:3 -> reopen

in reply to:  4 comment:5 by Ramiro Morales, 12 years ago

Resolution: needsinfo
Status: newclosed

Replying to harm:

more info provided in comment:3 -> reopen

Can you perform the tests and provide the information that comment suggests?

Last edited 12 years ago by Ramiro Morales (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top