Currently the DefaultServlet accepts the "Ranges" request header, but doesn't indicate this in its response by returning "Accept-Ranges: bytes". Although this is not required in HTTP/1.1, setting the header is required in order for the Adobe Acrobat plugin to correctly handle Linearized PDF's (which can speed download by allowing random access to a PDF file). Although it's not strictly necessary according to the specification I can't think of any reason why this header is not safe to set in a response from DefaultServlet, which is always dealing with static files, and not doing so has a negative impact on serving large PDF files - so I'm filing it as a bug rather than an RFE.
We might have lost sight of the issue here; this issue is not whether or not it's possible to encode utf-16-le, it's that the URI was not encoded in that character set. As I pointed out above, in the similar -be encoding, we need 16 bits to transmit each character, This particular browser sent 8 bit octets. That is not utf-16. Two escaped characters does not constitute a utf-16 request, it's a utf-16 fragment within an ASCII/ISO-8859/UTF-8/whatever bytestream. I would recommend no change whatsoever in Tomcat's code on this issue. As far as working around it, it might be nice if one could deploy a Valve that was triggered based on User-Agent, that would probably be the most elegant hack for this browser flaw.
Ignore comment #1; bugzilla navigation bites again; this relates to another issue.
I think this is a design flaw of the Adobe client. There are plenty of servlets, so adding this to the default servlet is pointless, as it might not be the one answering the request on which the Adobe client . I think you're better off using a valve or a filter to achieve this.
I think this is a design flaw of the Adobe client. There are plenty of servlets, so adding this to the default servlet is pointless, as it might not be the one answering the request on which the Adobe client will base its decidion to use a range. I think you're better off using a valve or a filter to achieve this.
The Adobe client will request the entire document, but if it finds it's Linearized and the server accepts Ranges it will interrupt that initial request. If Ranges aren't supported and it interrupts the request anyway it will have to re-download the entire document, which (if it's dynamically generated) could be a very expensive operation. So the Accept-Ranges header really is essential to this transaction. Yes, this could be resolved with a Filter or some other workaround on the part of the webapp developer, but I'm not clear why this is a better approach than modifying the DefaultServlet, which after all is designed to a) serve files from the filesystem, and b) support Ranges. Advertising that fact in the headers is completely inline with the HTTP specification and has at least one demonstrable case where it's necessary by design. More to the point, it will improve the user experience of Tomcat out of the box for a not-insignificant number of requests, at a cost of one line of code and an extra 20 bytes for each response.
I'm guessing the Apache web server supports this just fine. If so, then that's both a workaround and a reason to improve Tomcat. Tomcat should strive to be a suitable replacement for Apache for non-esoteric things. Serving PDFs well is certainly not esoteric. [Neither is serving as a load balancing reverse proxy ala mod_proxy_ajp -- if Tomcat did this that would eliminate my major reason for using Apache in front of Tomcat.]
Yes, the Apache web server sets this header.
It's difficult to create a generally correct work-around for this in a filter, since a filter won't know which requests are destined for DefaultServlet. In my case I know that all my PDFs are served by DefaultServlet, so a filter works. But that's not universally true. I've never written a valve, but I can imagine similar problems there.
This has been fixed in trunk and proposed for 6.0.x. It is enabled by default but can be disabled if required.
This has been fixed in 6.0.x and will be included in 6.0.19 onwards.
Hi Mark, One of my customer is facing the issue that he is not able to byte server the PDF as PDF is getting completely downloaded in the memory first and then displayed..They are using JBOSS 4.0.3 SP1 ...I was going through the link https://issues.apache.org/bugzilla/show_bug.cgi?id=45419 and it says that this has been fixed in 6.0.x and will be included in 6.0.19 onwards....So what can i suggest to my customer ..because even with Jboss 4.2.0 ,tomcat 6.0.13 is shipped ...so if they upgrade to JBOSS 4.2.0 will it solve their issue?? .They are using Java Code to serve the PDF and i got one suggestion to implement byter serving functionality in the servlet but it is causing some performance issues. Kindly advice Regards KApil
(In reply to comment #10) > This has been fixed in 6.0.x and will be included in 6.0.19 onwards. Hi Mark, One of my customer is facing the issue that he is not able to byte server the PDF as PDF is getting completely downloaded in the memory first and then displayed..They are using JBOSS 4.0.3 SP1 ...I was going through the link https://issues.apache.org/bugzilla/show_bug.cgi?id=45419 and it says that this has been fixed in 6.0.x and will be included in 6.0.19 onwards....So what can i suggest to my customer ..because even with Jboss 4.2.0 ,tomcat 6.0.13 is shipped ...so if they upgrade to JBOSS 4.2.0 will it solve their issue?? .They are using Java Code to serve the PDF and i got one suggestion to implement byter serving functionality in the servlet but it is causing some performance issues. Kindly advice Regards KApil
Bugzilla is not a support forum. You should use the Tomcat users mailing list or perhaps the equivalent for JBoss.