You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Michele Mase' <mi...@gmail.com> on 2012/07/30 12:10:16 UTC
PDF Download problem tomcat >= 7.0.27
I've the following problem: the server is running tomcat 7.0.27 (but also
with 7.0.28 and 7.0.29) and from the client (ie + acrobat 9) when opening
some pdf docs I receive an error complaining about a network error:
"A network error occured while accessing this document on interntet. Would
you like to close the document or reload it?"
Reverting back to 7.0.26 the problem disappears ...
The connector is the http bio
This is one public pdf that caused me the error when i put it on a tomcat
>=7.0.27
http://www.regione.fvg.it/rafvg/export/sites/default/RAFVG/formazione-lavoro/agenzia-regionale-lavoro/allegati/joblab_2.0_scheda_tematica_1_FR.pdf
What happened to the bio connector under the 7.0.27 version that could
cause the issue?
The connector uses the standard roles, for example:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" compression="off"/>
Regards
Michele Maè
RE: PDF Download problem tomcat >= 7.0.27
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Johnny Six [mailto:johnny6cheung@gmail.com]
> Subject: Re: PDF Download problem tomcat >= 7.0.27
> It looks like Tomcat7 is munging the content-type header.
> The correct response header should be:
> Content-Type: multipart/byteranges; boundary=CATALINA_MIME_BOUNDARY <<
> good
> Content-Type: multipart/byteranges;boundary=CATALINA_MIME_BOUNDARY <<
> bad
> Where there needs to be a space after the ';' character.
No, there doesn't; read the HTTP spec. There is a bug in the Adobe plugin for IE that fails to follow the specification, but Adobe is so far ignoring the problem. Search the archives for a discussion.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Johnny,
On 10/30/12 3:44 PM, Johnny Six wrote:
> It looks like Tomcat7 is munging the content-type header. The
> correct response header should be:
>
> Content-Type: multipart/byteranges; boundary=CATALINA_MIME_BOUNDARY
> << good Content-Type:
> multipart/byteranges;boundary=CATALINA_MIME_BOUNDARY << bad
>
> Where there needs to be a space after the ';' character.
Says who?
> In my code, i am setting these values by hand, via setHeader, but
> Tomcat7 seems to parse it and remove the space (don't know why).
>
> If i downgrade to Tomcat6, this problem goes away, and i get the
> right headers again, exactly as what i set them to be.
Those headers are equivalent.
> Tomcat team needs to probably fix this bug.
Feel free to read the rest of this thread before you say stupid things
like this publicly.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlCRUOsACgkQ9CaO5/Lv0PBmPgCeNyiJOEfJ3TSeokAWaTJSXdRf
sl8AoKR4VrEo6SXvEkBP31OrzT9ahAXU
=3xqa
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by Johnny Six <jo...@gmail.com>.
It looks like Tomcat7 is munging the content-type header.
The correct response header should be:
Content-Type: multipart/byteranges; boundary=CATALINA_MIME_BOUNDARY <<
good
Content-Type: multipart/byteranges;boundary=CATALINA_MIME_BOUNDARY <<
bad
Where there needs to be a space after the ';' character.
In my code, i am setting these values by hand, via setHeader,
but Tomcat7 seems to parse it and remove the space (don't know why).
If i downgrade to Tomcat6, this problem goes away, and i get the right
headers again,
exactly as what i set them to be.
Tomcat team needs to probably fix this bug.
Michele Mase' wrote:
>
> I've the following problem: the server is running tomcat 7.0.27 (but also
> with 7.0.28 and 7.0.29) and from the client (ie + acrobat 9) when opening
> some pdf docs I receive an error complaining about a network error:
>
> "A network error occured while accessing this document on interntet. Would
> you like to close the document or reload it?"
>
> Reverting back to 7.0.26 the problem disappears ...
>
> The connector is the http bio
>
>
> This is one public pdf that caused me the error when i put it on a tomcat
>>=7.0.27
>
> http://www.regione.fvg.it/rafvg/export/sites/default/RAFVG/formazione-lavoro/agenzia-regionale-lavoro/allegati/joblab_2.0_scheda_tematica_1_FR.pdf
>
>
> What happened to the bio connector under the 7.0.27 version that could
> cause the issue?
>
> The connector uses the standard roles, for example:
>
> <Connector port="8080" protocol="HTTP/1.1"
> connectionTimeout="20000"
> redirectPort="8443" compression="off"/>
>
>
> Regards
>
> Michele Maè
>
>
--
View this message in context: http://old.nabble.com/PDF-Download-problem-tomcat-%3E%3D-7.0.27-tp34229642p34621346.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by Michele Mase' <mi...@gmail.com>.
Me too: "1. I suspect that the content is requested not by IE, but by the
Adobe
Acrobat plugin."
I was unable to view from the changelog of tomcat releases which could be
the cause of this strange behaviour.
Michele MAsè
On Tue, Jul 31, 2012 at 11:32 PM, Konstantin Kolinko <knst.kolinko@gmail.com
> wrote:
> 2012/8/1 Jose María Zaragoza <de...@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
>
>
Re: PDF Download problem tomcat >= 7.0.27
Posted by Pid <pi...@pidster.com>.
On 01/08/2012 08:54, André Warnier wrote:
> Konstantin Kolinko wrote:
>> 2012/8/1 Jose María Zaragoza <de...@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.
>>
> +1
> Talking about PDF files, there is a possible good reason for such a
> behaviour.
>
> A PDF file is not just a sequential text-like file. It is more like an
> indexed file containing tables of pointers which points to more or less
> randomly organised chunks of data inside the file. And, as per Adobe PDF
> 1.7 reference :
>
> 3.4.4 File Trailer
> The trailer of a PDF file enables an application reading the file to
> quickly find the cross-reference table and certain special objects.
> Applications should read a PDF file from its end. The last line of the
> file contains only the end-of-file marker, %%EOF. (See implementation
> note 18 in Appendix H.) The two preceding lines contain the keyword
> startxref and the byte offset from the beginning of the file to the
> beginning of the xref keyword in the last cross-reference section.
> etc..
> ...
> And Note 18 in Appendix H essentially says that Acrobat reader is
> "tolerant" with respect to the above, and accepts a PDF if the %%EOF
> marker is located within the last 1024 bytes of the file.
>
> So, it is not beyond belief to imagine that a smart browser PDF plugin
> would first request the last chunk of the file, in order to retrieve
> pointers to the contents of the first page of the PDF, so that it could
> quickly retrieve the range of bytes corresponding to this first page, so
> that it could quickly display this first page into the browser window,
> while later retrieving the rest on-demand (as the user scrolls). (*)
>
> And if this is not the real explanation for the behaviour we are seeing,
> at least it is a clever one.
>
> Now how this all works in conjunction with the behaviour of HTTP
> proxies/gateways with respect to Range requests and buffering, is left
> as an exercise for the reader.
> (Who can start by trying to understand
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35)
> But that there would exist a couple of obscure bugs somewhere in there,
> which show up only in very specific circumstances, is not beyond belief
> either.
>
>
> (*) The attentive reader will have noticed that there is a possible flaw
> in this explanation : in the case at hand, the browser/plugin requests 2
> chunks of bytes in the Range request : the end-of-file chunk, but also a
> chunk in the middle. How does it already know which second Range to
> request ?
The PDF plugin is a PITA.
It *does* request ranges, which can be a little painful; I found this
out the hard way with some dynamically rendered PDFs.
p
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
[key:62590808]
Re: PDF Download problem tomcat >= 7.0.27
Posted by Rainer Jung <ra...@kippdata.de>.
On 01.08.2012 09:54, André Warnier wrote:
> Konstantin Kolinko wrote:
>> 2012/8/1 Jose María Zaragoza <de...@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.
>>
> +1
> Talking about PDF files, there is a possible good reason for such a
> behaviour.
>
> A PDF file is not just a sequential text-like file. It is more like an
> indexed file containing tables of pointers which points to more or less
> randomly organised chunks of data inside the file. And, as per Adobe PDF
> 1.7 reference :
>
> 3.4.4 File Trailer
> The trailer of a PDF file enables an application reading the file to
> quickly find the cross-reference table and certain special objects.
> Applications should read a PDF file from its end. The last line of the
> file contains only the end-of-file marker, %%EOF. (See implementation
> note 18 in Appendix H.) The two preceding lines contain the keyword
> startxref and the byte offset from the beginning of the file to the
> beginning of the xref keyword in the last cross-reference section.
> etc..
> ...
> And Note 18 in Appendix H essentially says that Acrobat reader is
> "tolerant" with respect to the above, and accepts a PDF if the %%EOF
> marker is located within the last 1024 bytes of the file.
>
> So, it is not beyond belief to imagine that a smart browser PDF plugin
> would first request the last chunk of the file, in order to retrieve
> pointers to the contents of the first page of the PDF, so that it could
> quickly retrieve the range of bytes corresponding to this first page, so
> that it could quickly display this first page into the browser window,
> while later retrieving the rest on-demand (as the user scrolls). (*)
>
> And if this is not the real explanation for the behaviour we are seeing,
> at least it is a clever one.
>
> Now how this all works in conjunction with the behaviour of HTTP
> proxies/gateways with respect to Range requests and buffering, is left
> as an exercise for the reader.
> (Who can start by trying to understand
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35)
> But that there would exist a couple of obscure bugs somewhere in there,
> which show up only in very specific circumstances, is not beyond belief
> either.
>
>
> (*) The attentive reader will have noticed that there is a possible flaw
> in this explanation : in the case at hand, the browser/plugin requests 2
> chunks of bytes in the Range request : the end-of-file chunk, but also a
> chunk in the middle. How does it already know which second Range to
> request ?
Adobe calls the range requests in the context of acrobat "fast web
view". When you generate a PDF you can choose whether you want to
support it or not. I guess that at least there will be a byte range
index giving the byte ranges for each page at the beginning of the
document. Usually Acrobat then just gets the first page plus the index.
If you switch to a different page, then it only loads the byte range
needed for that page.
How does it know the second Range? Perhaps it already did another
request in front to collect all needed index data.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by André Warnier <aw...@ice-sa.com>.
Konstantin Kolinko wrote:
> 2012/8/1 Jose María Zaragoza <de...@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.
>
+1
Talking about PDF files, there is a possible good reason for such a behaviour.
A PDF file is not just a sequential text-like file. It is more like an indexed file
containing tables of pointers which points to more or less randomly organised chunks of
data inside the file. And, as per Adobe PDF 1.7 reference :
3.4.4 File Trailer
The trailer of a PDF file enables an application reading the file to
quickly find the cross-reference table and certain special objects.
Applications should read a PDF file from its end. The last line of the
file contains only the end-of-file marker, %%EOF. (See implementation
note 18 in Appendix H.) The two preceding lines contain the keyword
startxref and the byte offset from the beginning of the file to the
beginning of the xref keyword in the last cross-reference section.
etc..
...
And Note 18 in Appendix H essentially says that Acrobat reader is "tolerant" with respect
to the above, and accepts a PDF if the %%EOF marker is located within the last 1024 bytes
of the file.
So, it is not beyond belief to imagine that a smart browser PDF plugin would first request
the last chunk of the file, in order to retrieve pointers to the contents of the first
page of the PDF, so that it could quickly retrieve the range of bytes corresponding to
this first page, so that it could quickly display this first page into the browser window,
while later retrieving the rest on-demand (as the user scrolls). (*)
And if this is not the real explanation for the behaviour we are seeing, at least it is a
clever one.
Now how this all works in conjunction with the behaviour of HTTP proxies/gateways with
respect to Range requests and buffering, is left as an exercise for the reader.
(Who can start by trying to understand
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35)
But that there would exist a couple of obscure bugs somewhere in there, which show up only
in very specific circumstances, is not beyond belief either.
(*) The attentive reader will have noticed that there is a possible flaw in this
explanation : in the case at hand, the browser/plugin requests 2 chunks of bytes in the
Range request : the end-of-file chunk, but also a chunk in the middle. How does it
already know which second Range to request ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/8/1 Jose María Zaragoza <de...@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
Re: PDF Download problem tomcat >= 7.0.27
Posted by Jose María Zaragoza <de...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by Stefan Mayr <st...@mayr-stefan.de>.
Am 31.07.2012 23:28, schrieb André Warnier:
> 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.
>
How about APR? The changelog includes following information in 7.0.27:
"Update the native component of the Tomcat APR/native connector to
1.1.23 and take advantage of the simplified distribution. (mturk) "
The initial thread starter reported to use <Connector
protocol="HTTP/1.1" ... >
If the autodetection finds the neccessary tcnative-lib we might search
for a change in the APR. At the end of last year there was CVE-2011-3192
for a vulnerability in httpd and HTTP range requests.
Maybe one should test protocol="org.apache.coyote.http11.Http11Protocol"
vs. protocol="org.apache.coyote.http11.Http11AprProtocol" to ensure
which implementation causes this problem.
- Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by André Warnier <aw...@ice-sa.com>.
Konstantin Kolinko wrote:
> 2012/7/31 Michele Mase' <mi...@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
Re: PDF Download problem tomcat >= 7.0.27
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/7/31 Michele Mase' <mi...@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.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by Michele Mase' <mi...@gmail.com>.
Tomorrow I'will try with wireshark hoping better results!
On Tue, Jul 31, 2012 at 9:23 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> André,
>
> On 7/31/12 2:49 PM, André Warnier wrote:
> > 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.
>
> What's interesting to note is that the request specifies two separate
> ranges:
>
> Request
> - -------
> GET /test.pdf HTTP/1.1
> Accept: */*
> Range: bytes=3446021-3447865, 475136-1792507
>
> ...
>
> Response
> - --------
> 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
> (end of post)
>
> There should probably be a chunk of the response with a Content-Length
> of -(3446021-3447865)=1844 bytes and another one with Content-Length
> of -(475136-1792507)=1317371 bytes, all packaged-up inside this single
> response.
>
> Can we get more of the data that you see?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlAYMMIACgkQ9CaO5/Lv0PC3MQCfZcQ6Y6fka2miDK4yD5Uufp3K
> VKEAoIilIDXuuqDSa1DYWQ/WgxEJYFHa
> =qTvX
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: PDF Download problem tomcat >= 7.0.27
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 7/31/12 2:49 PM, André Warnier wrote:
> 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.
What's interesting to note is that the request specifies two separate
ranges:
Request
- -------
GET /test.pdf HTTP/1.1
Accept: */*
Range: bytes=3446021-3447865, 475136-1792507
...
Response
- --------
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
(end of post)
There should probably be a chunk of the response with a Content-Length
of -(3446021-3447865)=1844 bytes and another one with Content-Length
of -(475136-1792507)=1317371 bytes, all packaged-up inside this single
response.
Can we get more of the data that you see?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAYMMIACgkQ9CaO5/Lv0PC3MQCfZcQ6Y6fka2miDK4yD5Uufp3K
VKEAoIilIDXuuqDSa1DYWQ/WgxEJYFHa
=qTvX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by André Warnier <aw...@ice-sa.com>.
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<us...@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
Re: PDF Download problem tomcat >= 7.0.27
Posted by Michele Mase' <mi...@gmail.com>.
Since there are a lot of silly technicians that cannot utilize any browser
wxcept ie, and some people told me "look, before the upgrade (was tomcat
7.0.16) all worked for me and now some pdf are ko", it must work with the
ancient configuration XP+IE+Acrobat9.
Other brosers, like firefox or other pdf viewers like foxit seem not have
the problem.
Michele Masè
On Tue, Jul 31, 2012 at 9:28 PM, Jose María Zaragoza
<de...@gmail.com>wrote:
> 2012/7/31 Michele Mase' <mi...@gmail.com>:
> > I'm waiting for a better solution ...
>
> One silly question, do you have try to reproduce this issue with an
> upper version of PDF Library ? I know that you cannot to upgrade all
> clients but we can to discard a bug in this plugin
>
> And, do you have try with another browser, like Chrome ? i know that
> you cannot to ask your clients to change your browsers , but Chrome
> has tools for develovers to monitoring the usage of network, headers,
> etc.
>
> Well, finally, they were two silly questions :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: PDF Download problem tomcat >= 7.0.27
Posted by Jose María Zaragoza <de...@gmail.com>.
2012/7/31 Michele Mase' <mi...@gmail.com>:
> I'm waiting for a better solution ...
One silly question, do you have try to reproduce this issue with an
upper version of PDF Library ? I know that you cannot to upgrade all
clients but we can to discard a bug in this plugin
And, do you have try with another browser, like Chrome ? i know that
you cannot to ask your clients to change your browsers , but Chrome
has tools for develovers to monitoring the usage of network, headers,
etc.
Well, finally, they were two silly questions :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by Michele Mase' <mi...@gmail.com>.
I'm waiting for a better solution ...
Maybe should a sniffer pcap help in diagnosys?
Michele Masè
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<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: PDF Download problem tomcat >= 7.0.27
Posted by André Warnier <aw...@ice-sa.com>.
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
> 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 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
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
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by Michele Mase' <mi...@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
Michele Masè
On Tue, Jul 31, 2012 at 1:30 PM, André Warnier <aw...@ice-sa.com> wrote:
> Michele Mase' wrote:
>
>> Unluckly the problem is difficult to reproduce (almost 1/10 times
>> appears);
>> a small script that empty the IE's cache and kill explorer.exe helped me.
>> I used mod_proxy_ajp because the apache's logs were better for debugging
>> purposes.
>> The matter appears even using the http bio connector.
>> Michele MAsè
>>
>> If it happens 1 time out of 10, then it is not hard to reproduce.
> Again :
> - install one of the plugins earlier mentioned
> - activate it
> - load your PDF once
> - press the "page refresh", with the shift button pressed (forces reload,
> even when already in cache)
> - do this as long as you do not have the problem
> - when you have the problem, look at the display of the plugin. Highlight
> the request that did not come back with an OK response (OK=200), and
> display the request and response headers of that request. Copy them to the
> clipboard, and paste them in you next message to the list.
>
> Without "solid" information of that kind, it is difficult to help you
> further.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: PDF Download problem tomcat >= 7.0.27
Posted by André Warnier <aw...@ice-sa.com>.
Michele Mase' wrote:
> Unluckly the problem is difficult to reproduce (almost 1/10 times appears);
> a small script that empty the IE's cache and kill explorer.exe helped me.
> I used mod_proxy_ajp because the apache's logs were better for debugging
> purposes.
> The matter appears even using the http bio connector.
> Michele MAsè
>
If it happens 1 time out of 10, then it is not hard to reproduce.
Again :
- install one of the plugins earlier mentioned
- activate it
- load your PDF once
- press the "page refresh", with the shift button pressed (forces reload, even when
already in cache)
- do this as long as you do not have the problem
- when you have the problem, look at the display of the plugin. Highlight the request that
did not come back with an OK response (OK=200), and display the request and response
headers of that request. Copy them to the clipboard, and paste them in you next message to
the list.
Without "solid" information of that kind, it is difficult to help you further.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by Michele Mase' <mi...@gmail.com>.
Unluckly the problem is difficult to reproduce (almost 1/10 times appears);
a small script that empty the IE's cache and kill explorer.exe helped me.
I used mod_proxy_ajp because the apache's logs were better for debugging
purposes.
The matter appears even using the http bio connector.
Michele MAsè
On Tue, Jul 31, 2012 at 9:52 AM, Jose María Zaragoza
<de...@gmail.com>wrote:
> 2012/7/31 Michele Mase' <mi...@gmail.com>:
> > With the tomcat locally installed all works fine; the issue occurs from a
> > linux box (rhel6.x in my situation) with tomcat 7.0.29 as the server
> > machine and a client. Both are in lan without filtering elements.
> > Since I'm (as now) unable to determine the root cause of the issue (the
> > worst thing is that the problem is only with some pdf, and it is also
> > difficult to reproduce), the only solution that worked for me was the
> > downgrade to the 7.0.26 release.
> > Regards
> > Michele MAsè
> >
>
> But you said that you've got a Apache web server connected to Tomcat
> by AJP,right ?
> Which does it serve PDF file ? If you get PDF file from Tomcat server
> directly, does it work fine ?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: PDF Download problem tomcat >= 7.0.27
Posted by Jose María Zaragoza <de...@gmail.com>.
2012/7/31 Michele Mase' <mi...@gmail.com>:
> With the tomcat locally installed all works fine; the issue occurs from a
> linux box (rhel6.x in my situation) with tomcat 7.0.29 as the server
> machine and a client. Both are in lan without filtering elements.
> Since I'm (as now) unable to determine the root cause of the issue (the
> worst thing is that the problem is only with some pdf, and it is also
> difficult to reproduce), the only solution that worked for me was the
> downgrade to the 7.0.26 release.
> Regards
> Michele MAsè
>
But you said that you've got a Apache web server connected to Tomcat
by AJP,right ?
Which does it serve PDF file ? If you get PDF file from Tomcat server
directly, does it work fine ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by Michele Mase' <mi...@gmail.com>.
With the tomcat locally installed all works fine; the issue occurs from a
linux box (rhel6.x in my situation) with tomcat 7.0.29 as the server
machine and a client. Both are in lan without filtering elements.
Since I'm (as now) unable to determine the root cause of the issue (the
worst thing is that the problem is only with some pdf, and it is also
difficult to reproduce), the only solution that worked for me was the
downgrade to the 7.0.26 release.
Regards
Michele MAsè
On Mon, Jul 30, 2012 at 3:46 PM, Jose María Zaragoza
<de...@gmail.com>wrote:
> 2012/7/30 Michele Mase' <mi...@gmail.com>:
> > IE 6.x on my test pc, but also IE8 with other pcs.
> > Acrobat is 9.x, 9.5.1 version, a lot of clients have this version, an
> > upgrade is not possible for now.
> > I've reviewed the apache access log (when the doc is served by a web
> server
> > apache connected with ajp with the tomcat), the only thing I see is an
> http
> > 206 and a X showing that the client has closed the connection before the
> > server "%X : X connection aborted before the response completed."
> > The security zone is "internet".
> > To reproduce the issue:
> > Utilize the acrobat integrated in the browser
> > Install a new tomcat 7.x on a linux machine, not windows with tar zxf
> > apache-tomcat-7.x.tar.gz
> > Put the pdf in any webapp, the ROOT is enough.
> > Obviously use a recent jvm, I use latest version of 1.6 (.33)
> > Start the tomcat (sh catalins.sh run or what you prefer)
> > Point the browser to the url.
> > Every time you want to retry, just empty the browser's cache and kill the
> > explorer process.
> > Tomcat >= 7.0.27 the error occurs
> > Tomcat < 7.0.27 the error has gone.
> > Michele Masè
> >
>
>
> Sorry, but works fine for me :
>
> IE 8
> Tomcat 7.0.29 , connecting directly to
> Adobe PDF library 9.90 running into browser
> Same PDF file
>
> I could only reproduce that error by simulating a network problem (
> changing proxy settings )
>
> Regards
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: PDF Download problem tomcat >= 7.0.27
Posted by Jose María Zaragoza <de...@gmail.com>.
2012/7/30 Michele Mase' <mi...@gmail.com>:
> IE 6.x on my test pc, but also IE8 with other pcs.
> Acrobat is 9.x, 9.5.1 version, a lot of clients have this version, an
> upgrade is not possible for now.
> I've reviewed the apache access log (when the doc is served by a web server
> apache connected with ajp with the tomcat), the only thing I see is an http
> 206 and a X showing that the client has closed the connection before the
> server "%X : X connection aborted before the response completed."
> The security zone is "internet".
> To reproduce the issue:
> Utilize the acrobat integrated in the browser
> Install a new tomcat 7.x on a linux machine, not windows with tar zxf
> apache-tomcat-7.x.tar.gz
> Put the pdf in any webapp, the ROOT is enough.
> Obviously use a recent jvm, I use latest version of 1.6 (.33)
> Start the tomcat (sh catalins.sh run or what you prefer)
> Point the browser to the url.
> Every time you want to retry, just empty the browser's cache and kill the
> explorer process.
> Tomcat >= 7.0.27 the error occurs
> Tomcat < 7.0.27 the error has gone.
> Michele Masè
>
Sorry, but works fine for me :
IE 8
Tomcat 7.0.29 , connecting directly to
Adobe PDF library 9.90 running into browser
Same PDF file
I could only reproduce that error by simulating a network problem (
changing proxy settings )
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by André Warnier <aw...@ice-sa.com>.
Konstantin Kolinko wrote:
...
>
> So why a ranged request comes? A feature of Acrobat 9? I wonder what
> range headers are in it.
>
If talking about IE browsers and Windows workstations, installing the "Fiddler2" plugin or
similar would allow to see exactly which headers are being sent by the browser, and what
the server response looks like.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/7/30 Michele Mase' <mi...@gmail.com>:
> IE 6.x on my test pc, but also IE8 with other pcs.
> Acrobat is 9.x, 9.5.1 version, a lot of clients have this version, an
> upgrade is not possible for now.
> I've reviewed the apache access log (when the doc is served by a web server
> apache connected with ajp with the tomcat), the only thing I see is an http
> 206 and a X showing that the client has closed the connection before the
> server "%X : X connection aborted before the response completed."
1. "206 Partial Content",
so it was a request containing a Range header.
Using an HTTPD in front of Tomcat, you would be using the AJP
connector (which differs from your original configuration of "http
bio"). So the issue is reproducible in that configuration as well?
%X is a feature in HTTPD access log format. Tomcat does not implement it.
What is in Tomcat's own access log? The same request?
2. I my test (connecting to Tomcat directly over http with Adobe
Reader 10.1.3), the only access log line is "200", transferring the
whole document.
So why a ranged request comes? A feature of Acrobat 9? I wonder what
range headers are in it.
> The security zone is "internet".
> To reproduce the issue:
> Utilize the acrobat integrated in the browser
> Install a new tomcat 7.x on a linux machine, not windows with tar zxf
> apache-tomcat-7.x.tar.gz
> Put the pdf in any webapp, the ROOT is enough.
> Obviously use a recent jvm, I use latest version of 1.6 (.33)
> Start the tomcat (sh catalins.sh run or what you prefer)
> Point the browser to the url.
> Every time you want to retry, just empty the browser's cache and kill the
> explorer process.
> Tomcat >= 7.0.27 the error occurs
> Tomcat < 7.0.27 the error has gone.
> Michele Masè
>
> On Mon, Jul 30, 2012 at 12:45 PM, Konstantin Kolinko <knst.kolinko@gmail.com
>> wrote:
>
>> 2012/7/30 Michele Mase' <mi...@gmail.com>:
>> > I've the following problem: the server is running tomcat 7.0.27 (but also
>> > with 7.0.28 and 7.0.29) and from the client (ie + acrobat 9) when opening
>> > some pdf docs I receive an error complaining about a network error:
>> >
>> > "A network error occured while accessing this document on interntet.
>> Would
>> > you like to close the document or reload it?"
>> >
>> > Reverting back to 7.0.26 the problem disappears ...
>> >
>> > The connector is the http bio
>> >
>> >
>> > This is one public pdf that caused me the error when i put it on a tomcat
>> >>=7.0.27
>> >
>> >
>> http://www.regione.fvg.it/rafvg/export/sites/default/RAFVG/formazione-lavoro/agenzia-regionale-lavoro/allegati/joblab_2.0_scheda_tematica_1_FR.pdf
>> >
>> >
>> > What happened to the bio connector under the 7.0.27 version that could
>> > cause the issue?
>> >
>> > The connector uses the standard roles, for example:
>> >
>> > <Connector port="8080" protocol="HTTP/1.1"
>> > connectionTimeout="20000"
>> > redirectPort="8443" compression="off"/>
>> >
>>
>> 1. Why acrobat 9? The current version of acrobat reader (adobe reader)
>> is 10, 10.1.3 to be precise. Aren't there security issues with
>> acrobat 9?
>>
>> I tried to reproduce your issue by placing your document in the
>> default configuration of 7.0.29 + you connector configuration, but the
>> problem does not show itself. Using the said version of Adobe Reader +
>> IE 8, on WinXP.
>>
>> What version of IE you are using?
>>
>> 2. Is your document protected by security constraints?
>>
>> If it is, then Tomcat adds some headers to the response to prevent
>> caching. It might interfere.
>>
>> If you could inspect the response headers...
>>
>> 3. What is in access log? Is Tomcat delivering the content?
>>
>> Is acrobat (or IE) re-requesting the document when you agree to
>> "reload" (I mean what is mentioned in that error message)?
>>
>> Is there difference in access logs entries between 7.0.29 and 7.0.26?
>>
>> 4. To what security zone (in IE) your web site belongs? Is it internet
>> or local network?
>>
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PDF Download problem tomcat >= 7.0.27
Posted by Michele Mase' <mi...@gmail.com>.
IE 6.x on my test pc, but also IE8 with other pcs.
Acrobat is 9.x, 9.5.1 version, a lot of clients have this version, an
upgrade is not possible for now.
I've reviewed the apache access log (when the doc is served by a web server
apache connected with ajp with the tomcat), the only thing I see is an http
206 and a X showing that the client has closed the connection before the
server "%X : X connection aborted before the response completed."
The security zone is "internet".
To reproduce the issue:
Utilize the acrobat integrated in the browser
Install a new tomcat 7.x on a linux machine, not windows with tar zxf
apache-tomcat-7.x.tar.gz
Put the pdf in any webapp, the ROOT is enough.
Obviously use a recent jvm, I use latest version of 1.6 (.33)
Start the tomcat (sh catalins.sh run or what you prefer)
Point the browser to the url.
Every time you want to retry, just empty the browser's cache and kill the
explorer process.
Tomcat >= 7.0.27 the error occurs
Tomcat < 7.0.27 the error has gone.
Michele Masè
On Mon, Jul 30, 2012 at 12:45 PM, Konstantin Kolinko <knst.kolinko@gmail.com
> wrote:
> 2012/7/30 Michele Mase' <mi...@gmail.com>:
> > I've the following problem: the server is running tomcat 7.0.27 (but also
> > with 7.0.28 and 7.0.29) and from the client (ie + acrobat 9) when opening
> > some pdf docs I receive an error complaining about a network error:
> >
> > "A network error occured while accessing this document on interntet.
> Would
> > you like to close the document or reload it?"
> >
> > Reverting back to 7.0.26 the problem disappears ...
> >
> > The connector is the http bio
> >
> >
> > This is one public pdf that caused me the error when i put it on a tomcat
> >>=7.0.27
> >
> >
> http://www.regione.fvg.it/rafvg/export/sites/default/RAFVG/formazione-lavoro/agenzia-regionale-lavoro/allegati/joblab_2.0_scheda_tematica_1_FR.pdf
> >
> >
> > What happened to the bio connector under the 7.0.27 version that could
> > cause the issue?
> >
> > The connector uses the standard roles, for example:
> >
> > <Connector port="8080" protocol="HTTP/1.1"
> > connectionTimeout="20000"
> > redirectPort="8443" compression="off"/>
> >
>
> 1. Why acrobat 9? The current version of acrobat reader (adobe reader)
> is 10, 10.1.3 to be precise. Aren't there security issues with
> acrobat 9?
>
> I tried to reproduce your issue by placing your document in the
> default configuration of 7.0.29 + you connector configuration, but the
> problem does not show itself. Using the said version of Adobe Reader +
> IE 8, on WinXP.
>
> What version of IE you are using?
>
> 2. Is your document protected by security constraints?
>
> If it is, then Tomcat adds some headers to the response to prevent
> caching. It might interfere.
>
> If you could inspect the response headers...
>
> 3. What is in access log? Is Tomcat delivering the content?
>
> Is acrobat (or IE) re-requesting the document when you agree to
> "reload" (I mean what is mentioned in that error message)?
>
> Is there difference in access logs entries between 7.0.29 and 7.0.26?
>
> 4. To what security zone (in IE) your web site belongs? Is it internet
> or local network?
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: PDF Download problem tomcat >= 7.0.27
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/7/30 Michele Mase' <mi...@gmail.com>:
> I've the following problem: the server is running tomcat 7.0.27 (but also
> with 7.0.28 and 7.0.29) and from the client (ie + acrobat 9) when opening
> some pdf docs I receive an error complaining about a network error:
>
> "A network error occured while accessing this document on interntet. Would
> you like to close the document or reload it?"
>
> Reverting back to 7.0.26 the problem disappears ...
>
> The connector is the http bio
>
>
> This is one public pdf that caused me the error when i put it on a tomcat
>>=7.0.27
>
> http://www.regione.fvg.it/rafvg/export/sites/default/RAFVG/formazione-lavoro/agenzia-regionale-lavoro/allegati/joblab_2.0_scheda_tematica_1_FR.pdf
>
>
> What happened to the bio connector under the 7.0.27 version that could
> cause the issue?
>
> The connector uses the standard roles, for example:
>
> <Connector port="8080" protocol="HTTP/1.1"
> connectionTimeout="20000"
> redirectPort="8443" compression="off"/>
>
1. Why acrobat 9? The current version of acrobat reader (adobe reader)
is 10, 10.1.3 to be precise. Aren't there security issues with
acrobat 9?
I tried to reproduce your issue by placing your document in the
default configuration of 7.0.29 + you connector configuration, but the
problem does not show itself. Using the said version of Adobe Reader +
IE 8, on WinXP.
What version of IE you are using?
2. Is your document protected by security constraints?
If it is, then Tomcat adds some headers to the response to prevent
caching. It might interfere.
If you could inspect the response headers...
3. What is in access log? Is Tomcat delivering the content?
Is acrobat (or IE) re-requesting the document when you agree to
"reload" (I mean what is mentioned in that error message)?
Is there difference in access logs entries between 7.0.29 and 7.0.26?
4. To what security zone (in IE) your web site belongs? Is it internet
or local network?
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org