[quoted text, click to view] GuruPrasad wrote:
>
> Test Scenerio
>
>
> Tools usage for the Test
>
> ASP.NET Web Application
> .Net Framework 1.1
> Windows XP
> LocalHost
> Fiddler HTTP Debugger
> Internet Explorer
>
>
> The web project also contains few JS files and Images. The
> application when run through the
>
> Internet Explorer, on local host, was not downloading few of the
> images and js files on the
>
> first case and secondly, few files were being downloaded on a
> subsequent request ( here i
>
> mean referred by other pages).
>
> The tests were conducted first time by clearing the IE Cache (tempry
> folder) and next just
>
> refreshing IE. When looked through the Fiddler, i found :
>
>
> Issue 1. (IE's cache is cleared)
>
> Rarely and randomly few of the files are returned by server as bad
> request(202).
[...]
202 is not an error. It's just an information that a server received a
valid request. Here's what the spec says:
The request has been accepted for processing, but the processing has
not been completed. The request might or might not eventually be acted
upon, as it might be disallowed when processing actually takes place.
There is no facility for re-sending a status code from an asynchronous
operation such as this.
The 202 response is intentionally non-committal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without requiring
that the user agent's connection to the server persist until the
process is completed. The entity returned with this response SHOULD
include an indication of the request's current status and either a
pointer to a status monitor or some estimate of when the user can
expect the request to be fulfilled.
This of course can also be used to gracefully tell a client that a
server is rather busy ;-)
[quoted text, click to view] > Issue 2. (IE is simply refreshed - using F5)
>
> Most of the files' response contained 304, Not Modified - which is
> correct since the
>
> If-Modified-Since
> in the request header is = the Last-Modified on the file itself.
>
> Few files which are downloading (we are facing an issue with some .js
> file(1 or 2) while
>
> most other are correctly returning the 304 response ). For the ones
> where is does not
>
> return a 304 response, but instead a 200 - i.e its downloading the
> resource form the IIS -
>
> we noted that strangely the request header does not contain an
> "If-Modified-Since" while
>
> other resources with the same extension (i.e for example .js) do
> contain the
>
> "If-Modified-Since" are we are correctly getting a 304 for them. How
> is the client browser
>
> (IE 6.0) seletively not sending the "If-Modified-Since" header for
> these (2 or 3) files
>
> while doing it for the others? Any ideas? Anything to do with the
> physical file attributes
>
> in the application folder?
A conditional GET, which may lead to either a reload (200) or a not
(304), requires a local copy to make sense. Any non-cached file doesn't
really require a If-Modified-Since header -- the server *must* serve a
fresh copy every time.
Cheers,
--
http://www.joergjooss.de