If-Modified-Since
header passed by IE9In my ASP.NET 4.0 web app, I've got a generic handler (.ashx) that serves images stored in the DB. In the interest of efficiency, I'm handling some caching-related headers and passing cache information.
I'm getting DateTime parse errors moderately frequently from trying to parse the If-Modified-Since
header contents, usually from IE9. Turns out it's sending something like this:
Mon, 28 Nov 2011 16:34:52 GMT; length=8799
I'm handling that by using a regular expression to strip out the last part. But I'm curious: what length is it referring to, and what use is it? Is it the size of the cached data for the requested URL?
The If-Modified-Since request HTTP header makes the request conditional: the server sends back the requested resource, with a 200 status, only if it has been last modified after the given date.
The If-Modified-Since HTTP header indicates the time for which a browser first downloaded a resource from the server. This helps to determine whether the resource has changed or not, since the last time it was accessed.
The If-Modified-Since header is used to specify the time at which the browser last received the requested resource. The If-None-Match header is used to specify the entity tag that the server issued with the requested resource when it was last received.
If the client has done a conditional GET and access is allowed, but the document has not been modified since the date and time specified in If-Modified-Since field, the server responds with a 304 status code and does not send the document body to the client.
According to an old post on the Squid proxy mailing list:
The length parameter to If-Modified-Since is a Netscape extension of HTTP/1.0, meant to improve the accuracy of If-Modified-Since in case a document is updated twice in the same second.
HTTP/1.1 solved the same problem in a better way via the ETag header and If-None-Match.
I'm guessing that IE adapted this extension at some point and have left it in.
This seems to be an old Netscape extension of the header field (see an ancient discussion on http-wg); even though it seems to actually be against both HTTP/1.0 and HTTP/1.1 specifications (the idea was (functionally) replaced with the ETag header). No idea if/why IE9 sends it and under what specific conditions (I would guess only a specific combination of caching headers triggers it).
I guess the best solution would be to drop anything after a semicolon, which is normally used in HTTP to separate extension parameters in headers (see e.g. the Accept header).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With