Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <501828D1.7000000@ice-sa.com>
Date: Tue, 31 Jul 2012 20:49:53 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: PDF Download problem tomcat >= 7.0.27
References: 
 <CAC=Hunt=16kVDG-GuyPq6mhw3wJTZNYQgU5A8OaPKzmUKJXG-A@mail.gmail.com>
	<CABzHfVkQCH=7-5=3xvOetV2W2ACeTDz-6E703RLu5Ja7+wAqog@mail.gmail.com>
	<CAC=HunuF5zqKf5s_D9syTZ1J2nFXdCjEWKj=zQ+Hc8BgnN1hzA@mail.gmail.com>
	<CABOBwRg_fBPSwUQpiNkzE3m1evWn0-zN=f5oXRaV3kmg9UEBKQ@mail.gmail.com>
	<CAC=HuntJh1ixdv71fhmxRqaHhNxUXptXvywkKKb0=hbCMLnkjA@mail.gmail.com>
	<CABOBwRhxPPO25wRLSjHch0Mj9QCRQ5nzW-JAq47Ddif0BNzOtQ@mail.gmail.com>
	<CAC=Huntp=fA4GiV8HBpLGuq0ZmYJu5=-C179YXK389hpuFv0jg@mail.gmail.com>
	<5017C1D3.5030608@ice-sa.com>
	<CAC=HunsuyMyHL0Dnh-7dU59P846aZ29oPOOZbiHS9w1Lh05ROg@mail.gmail.com>
	<5017F9B8.7090303@ice-sa.com>
 <CAC=HunsXryTANAe5ec5KesPn92T-fMoyGSWOFD2GTAj7PTPT4A@mail.gmail.com>
In-Reply-To: 
 <CAC=HunsXryTANAe5ec5KesPn92T-fMoyGSWOFD2GTAj7PTPT4A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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 <aw@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-unsubscribe@tomcat.apache.org>
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
> 


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