Michele Mase' wrote:
I'm waiting for a better solution ...
Maybe should a sniffer pcap help in diagnosys?
Wireshark is your friend. It may at least show you when the client disconnects, and maybe
why. But if the problem is in the response body, I don't know if it will be very easy to
find with a packet dump (and these responses are big).
Wait a bit. Maybe someone else more knowledgeable will see something strange in those
headers.
Another idea : the 206 response header contains a "Content-Length" header. According to
the specs, this is supposed to be the total number of bytes which should be contained in
the response body (before decoding it into parts).
Try to compare this, with what your Apache log tells you about the response size for the
same request.
Careful when comparing : I believe that the response size, for Apache, includes the HTTP
headers; while the Content-Length headers refers only to the response body, without the
headers.
On Tue, Jul 31, 2012 at 5:28 PM, André Warnier <a...@ice-sa.com> wrote:
Michele Mase' wrote:
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<http://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<http://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 above appears (to me) to be two correct request/response pairs.
Even the 206, which is a normal response to the "Range" request as per
here :
http://www.w3.org/Protocols/**rfc2616/rfc2616-sec10.html<http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>
We still don't know if/why the browser/client resets the connection, but
it is not visible in the above exchange.
Maybe inspecting the response body to the second request would provide a
clue.
It is also a bit of a mystery to me why the same browser would sometimes
request the same resource in one go, and sometimes as byteranges. But I
don't know exactly how this part is supposed to work.
Maybe it depends on which part of the PDF the user decides to display ?
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
users-unsubscribe@tomcat.**apache.org<users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
