Re: PDF Download problem tomcat = 7.0.27
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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. 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=2 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: PDF Download problem tomcat = 7.0.27
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_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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
Ted Smith ted_smi...@verizon.net 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 function so that Tomcat would always send back the whole PDF instead of figuring out what to do with the range request. It would not be right to ask users to reconfig their web browser setting for this issue so any kind of workaround would work for me, even if it slows down the performance. Thanks in Advance. -T - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org https://issues.apache.org/bugzilla/show_bug.cgi?id=53814 The above may help. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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 Smith ted_smi...@verizon.net 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 function so that Tomcat would always send back the whole PDF instead of figuring out what to do with the range request. It would not be right to ask users to reconfig their web browser setting for this issue so any kind of workaround would work for me, even if it slows down the performance. Thanks in Advance. -T - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org https://issues.apache.org/bugzilla/show_bug.cgi?id=53814 The above may help. Mark - To unsubscribe, e-mail: 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
Re: PDF Download problem tomcat = 7.0.27
2012/9/25 Ted Smith ted_smi...@verizon.net: 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 that is a different issue. 1. That Adobe issue is said to be fixed in 9.4.4, 10.1 and it is about mime type of application/pdf;charset=UTF-8. (Adding charset parameter to application/pdf mime type is an odd behaviour and as such is rare. Though I can envision circumstances/programming errors when it might happen). 2. In BZ 53814 the mime type is multipart/byteranges;boundary=CATALINA_MIME_BOUNDARY and it is said to be observed in Adobe Reader 9.5.0 A different issue. Please do not top-post. On 9/24/2012 4:26 PM, Mark Thomas wrote: Ted Smith ted_smi...@verizon.net 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 function so that Tomcat would always send back the whole PDF instead of figuring out what to do with the range request. It would not be right to ask users to reconfig their web browser setting for this issue so any kind of workaround would work for me, even if it slows down the performance. Thanks in Advance. -T https://issues.apache.org/bugzilla/show_bug.cgi?id=53814 The above may help. Mark Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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.koli...@gmail.com wrote: 2012/8/1 Jose María Zaragoza demablo...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
Konstantin Kolinko wrote: 2012/8/1 Jose María Zaragoza demablo...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
On 01/08/2012 08:54, André Warnier wrote: Konstantin Kolinko wrote: 2012/8/1 Jose María Zaragoza demablo...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: PDF Download problem tomcat = 7.0.27
On 01.08.2012 09:54, André Warnier wrote: Konstantin Kolinko wrote: 2012/8/1 Jose María Zaragoza demablo...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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 demablo...@gmail.comwrote: 2012/7/30 Michele Mase' michele.m...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
2012/7/31 Michele Mase' michele.m...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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 demablo...@gmail.comwrote: 2012/7/31 Michele Mase' michele.m...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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 a...@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.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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 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:**8080http://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:**8080http://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.htmlhttp://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.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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:**8080http://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:**8080http://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.htmlhttp://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.orgusers-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
Re: PDF Download problem tomcat = 7.0.27
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
2012/7/31 Michele Mase' michele.m...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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 demablo...@gmail.comwrote: 2012/7/31 Michele Mase' michele.m...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
2012/7/31 Michele Mase' michele.m...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
Konstantin Kolinko wrote: 2012/7/31 Michele Mase' michele.m...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
2012/8/1 Jose María Zaragoza demablo...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
2012/7/30 Michele Mase' michele.m...@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=2 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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.koli...@gmail.com wrote: 2012/7/30 Michele Mase' michele.m...@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=2 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
2012/7/30 Michele Mase' michele.m...@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.koli...@gmail.com wrote: 2012/7/30 Michele Mase' michele.m...@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=2 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PDF Download problem tomcat = 7.0.27
2012/7/30 Michele Mase' michele.m...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
