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 (athena.apache.org: domain of knst.kolinko@gmail.com
 designates 209.85.220.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABOBwRi4yioOw1GdChFni3ce0E-vX5W7Sghu32wp-u6YZGJ1-A@mail.gmail.com>
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>
	<CABzHfVnyirKkDsohGvYpu2DNXEjfDOsGUZVqfuH8k3jJSCUk3Q@mail.gmail.com>
	<CABOBwRi4yioOw1GdChFni3ce0E-vX5W7Sghu32wp-u6YZGJ1-A@mail.gmail.com>
Date: Wed, 1 Aug 2012 01:32:03 +0400
Message-ID: 
 <CABzHfVkncaG-2Dy_5p_SiXGeVMJP3KQY1wXtfwTsxjJ2oE=oMw@mail.gmail.com>
Subject: Re: PDF Download problem tomcat >= 7.0.27
From: Konstantin Kolinko <knst.kolinko@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/8/1 Jose Mar=EDa Zaragoza <demablogia@gmail.com>:
>> 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?
>
>
> Well, i don't know so much, but that doesn't have to do with chunked
> encoding, but Partial Content support, right ?
> And partial content is requested by client (IE) if Content-length is
> very big ( I guess ... )
> Maybe, IE requests a PDF file (GET) and  if it sees a Content-length
> very big , cuts downloading and re-send a GET request with a range of
> bytes.
>
> Chrome looks to perform something like that behaviour
>

1. I suspect that the content is requested not by IE, but by the Adobe
Acrobat plugin.

The "User-Agent" header says that it was IE6,  but it is hard to
imagine why the browser by itself would request that strange bytes
range, asking for the tail of the file first. So there is something
else that uses the browser to perform the request.

2. To clarify what I said about chunked encoding:

Tomcat itself does not know the size of data that it sends. So if the
response is HTTP/1.1, the response will be send using
"Transfer-Encoding: chunked" in blocks of bytes (chunks) each prefixed
with the size of the block, up to the terminating block of size 0. It
is a feature of HTTP/1.1 protocol.

If something sends "Content-Length: 1319458" response header, it must
calculate the size of data, and it can be only done by caching the
whole of response sent by Tomcat.  The response headers will not be
sent before the whole data is cached, so the client will observe a
delay. I think there is a possibility that the client can time-out.

Best regards,
Konstantin Kolinko

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