-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:
> mult
> From: Johnny Six [mailto:johnny6che...@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_BO
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 t
2012/9/25 Ted Smith :
> Thanks. Does it mean this bug can be "worked around" by
> setting its init parameter "useAcceptRanges" to the value of "false"?
>
> BTW
> I found the following that is acked by Adobe
> http://helpx.adobe.com/acrobat/kb/pdf-files-dont-display-some.html
>
Interesting, but t
Thanks. Does it mean this bug can be "worked around" by
setting its init parameter "useAcceptRanges" to the value of "false"?
BTW
I found the following that is acked by Adobe
http://helpx.adobe.com/acrobat/kb/pdf-files-dont-display-some.html
On 9/24/2012 4:26 PM, Mark Thomas wrote:
Ted Smit
Ted Smith wrote:
>Hello:
>
>I just upgraded to Tomcat 7.0.29 from Tomcat 6 and encountered the
>exact
>issue as described in
>
>http://comments.gmane.org/gmane.comp.jakarta.tomcat.user/223299
>
>Is there any workaround? I would be fine if there is an option to
>disable the range handling funct
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
On 01.08.2012 09:54, André Warnier wrote:
Konstantin Kolinko wrote:
2012/8/1 Jose María Zaragoza :
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 i
On 01/08/2012 08:54, André Warnier wrote:
> Konstantin Kolinko wrote:
>> 2012/8/1 Jose María Zaragoza :
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,
Konstantin Kolinko wrote:
2012/8/1 Jose María Zaragoza :
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 i
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 wrote:
> 2012/8/1 Jos
2012/8/1 Jose María Zaragoza :
>> 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
Konstantin Kolinko wrote:
2012/7/31 Michele Mase' :
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 happe
> 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 r
2012/7/31 Michele Mase' :
> 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, fol
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 pd
Tomorrow I'will try with wireshark hoping better results!
On Tue, Jul 31, 2012 at 9:23 PM, Christopher Schultz <
ch...@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
2012/7/31 Michele Mase' :
> 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,
-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, a
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 wi
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 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
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 s
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
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
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è
2012/7/31 Michele Mase' :
> 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
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 tha
2012/7/30 Michele Mase' :
> 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 th
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 browse
2012/7/30 Michele Mase' :
> 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 th
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 a
2012/7/30 Michele Mase' :
> 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 d
32 matches
Mail list logo