tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Algesten <puck...@taglab.com>
Subject Re: production quality?
Date Thu, 31 Oct 2002 16:36:50 GMT
Yup.. as I said, generally content-type changes might be ok. And yes I 
have reported it as a bug.

Martin


jean-frederic clere wrote:

> 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?
>
>>
>> Martin
>>
>>
>>
>> jean-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" <martin@taglab.com> 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>
>


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


Mime
View raw message