Re: production quality?

[Martin Algesten]

In a nutshell mod_proxy updates its cached entries with whatever new headers are given to it. E.g. first request comes into mod_proxy and it can't find the requested resource in its cache. It forwards on to my tomcat who responds with something like:
HTTP/1.1 200
Content-Type: image/gif
Content-Length: 12345

Second call comes into mod_proxy this time with an "If-Modified-Since" for the same resource. mod_proxy needs to revalidate its cached entry against tomcat and does an "If-Modifed-Since" against tomcat and tomcat answers:
HTTP/1.1 304
Content-Type: text/html
Content-Length: 0

At this point mod_proxy updates it's cached entry and ends up with a gif that has got a Content-Type set to text/html.

Further requests to mod_proxy without "If-Modified-Since" results in GIFs with strange content types. Thank god for IE not trusting the content type :)

Bug 13846 has my curl detective work in it...

M


Pier Fumagalli wrote:

On 30/10/02 6:06 pm, "Martin Algesten" <[EMAIL PROTECTED]> wrote:

An incorrect If-Modified-Since response seems to shag mod_proxy. Now I
don't know how widely used mod_proxy is, or if perhaps this should be
fixed there instead. However I am concerned about this and as I pointed
out I am happy to look into it myself, however I would appreciate a hint
of what to look at. You mention a header refactoring, elaborate?

Could it be what we are observing on http://nagoya.apache.org/eyebrowse when
we pass stuff in the backend on port 8080?

What would be the "outcome" of this? (I mean you know any way in which I can
find out if this is the bug we're seeing)

Pier


--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>