Konstantin Kolinko wrote:
2012/7/31 Michele Mase' <michele.m...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
