#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 , 12 years ago
comment:2 by , 12 years ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
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 , 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.
follow-up: 5 comment:4 by , 12 years ago
Resolution: | needsinfo |
---|---|
Status: | closed → new |
more info provided in comment:3 -> reopen
comment:5 by , 12 years ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
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.