tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: PDF Download problem tomcat >= 7.0.27
Date Tue, 31 Jul 2012 21:28:17 GMT
Konstantin Kolinko wrote:
> 2012/7/31 Michele Mase' <michele.mase@gmail.com>:
>> The "only" way to reproduce it is (for me) without the plugin; i'm sorry ...
>> I haven't seen what happens using a sniffer, but the X in the apache's log
>> file tells me that the client is aborting the session, I suspect a session
>> reset could happen.
>> And finally, following your suggestion, a F5 helped me:
>>
>> 200Ok session:
>> GET /test.pdf HTTP/1.1
>> Accept: */*
>> Accept-Encoding: gzip, deflate
>> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
>> CLR 2.0.50727)
>> Host: installazioni-el6b.insiel.it:8080
>> Connection: Keep-Alive
>> Pragma: no-cache
>>
>> HTTP/1.1 200 OK
>> Server: Apache-Coyote/1.1
>> Accept-Ranges: bytes
>> ETag: W/"3447866-1343391729000"
>> Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
>> Content-Type: application/pdf
>> Content-Length: 3447866
>> Date: Tue, 31 Jul 2012 12:32:05 GMT
>>
>> 206KO:
>> GET /test.pdf HTTP/1.1
>> Accept: */*
>> Range: bytes=3446021-3447865, 475136-1792507
>> Accept-Encoding: gzip, deflate
>> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
>> CLR 2.0.50727)
>> Host: installazioni-el6b.insiel.it:8080
>> Connection: Keep-Alive
>> Pragma: no-cache
>>
>> HTTP/1.1 206 Partial Content
>> Server: Apache-Coyote/1.1
>> Accept-Ranges: bytes
>> ETag: W/"3447866-1343391729000"
>> Last-Modified: Fri, 27 Jul 2012 12:22:09 GMT
>> Content-Type: multipart/byteranges;boundary=CATALINA_MIME_BOUNDARY
>> Date: Tue, 31 Jul 2012 12:32:20 GMT
>> Content-Length: 1319458
>>
> 
> The Content-Length header in the above 206 response is not from Tomcat.
> 
> Tomcat's DefaultServlet does not calculate the whole size of the parts
> and does not set content-length, and the file size is much more than
> fits into the buffer.
> So it would use  Transfer-Encoding: chunked  in its response and not
> the one that you cited.
> There must be some proxy in the way that buffers the data and sends
> them as one response instead of chunks. HTTPD? Was there some option
> in it that disables chunked encoding when interacting with IE?
> 
> I tried to reproduce this request locally with a telnet client, and
> when I have local A/V software turned on, it interferes and re-chunks
> the response into larger chunks.
> If I turn the A/V off, I see Tomcat 7.0.29 responding in chunks of 2Kb
> (0x2000 bytes) each, as expected.
> 
Konstantin, Christopher,

According to the OP, this issue happens with Tomcat 7.0.27, 7.0.28 and 7.0.29, and 
disappears if he reverts to 7.0.26.
Other environmental conditions - according to the OP - appear not to change between these

tests with different Tomcat versions.  The browser in all cases in WinXP-IE-Acrobat9.
Quote: "Other brosers, like firefox or other pdf viewers like foxit seem not have
the problem."

I could not spot anything in the 7.0.27 Changelog which would explicitly appear to relate

to this, but maybe you can ?
Not saying that a bug was introduced in Tomcat 7.0.27, but maybe some difference in the 
way in which Tomcat 7.0.27+ produce the response to a Range request could explain why 
7.0.26 does not trigger the problem, and later versions do ?

To be more explicit : my bet at this stage would be a bug in the XP+IE+Acrobat9 
combination (as being "the usual suspects"), but a bug that gets triggered only because 
Tomcat 7.0.27+ send the response just a bit differently than 7.0.26.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message