Martin Algesten wrote:
I don't see how chaning the Content-Type can be right in this scenario (yes, generally content-type changes might be ok), can you explain. If I understood this correctly we are asking Tomcat if a specific object has changed (If-Modified-Since), and any response should surely be true about the resource we're asking about. E.g. if we're asking if a certain gif file has changed since yesterday, then tomcat tells us that it is unchanged content wise, but meta-wise it is no longer a gif, but an html document?!Yes, in the scenario that is a bug. So report it as a bug.
But think of an ISO image incorrectly transferted as text/html due to _bad_ mime type configuration, would not it be nice to just change the mime type and not resend the whole file?
Martinjean-frederic clere wrote:Martin Algesten wrote:1. Tomcat should either not send any headers on a 304, or if it does then make sure that they do reflect the correct values for the requested object (e.g. not call a gif a text).
Changing a Content-Type is legitimate, but changing the Content-Length is probably not. But I do not think that Tomcat has to change the Content-Type.
2. Not entirely sure here. Reading the HTTP/1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5
It states:
"If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response."
I suspect that is what we're seeing in mod_proxy. But I just realised that I have some reading to do, the stuff about weak and strong validator didn't make much sense to me...
It changes the Content-Type and I think that is OK.Martin jean-frederic clere wrote:Pier Fumagalli wrote:On 30/10/02 20:02, "Martin Algesten" <[EMAIL PROTECTED]> wrote: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 :)
Nope, that's not it, but it's a good catch. We don't keep proxied content
cached... Thanks a lot for the clarification...
If I got it right there are 2 errors:
1 - Tomcat should not send a Content-Type nor Content-Length.
2 - mod_proxy should complain because we are sending "garbages" or ignore the "invalid" headers.
Pier (gone diggin' mirrors)
--
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>
--
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>
--
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>
