Bug 45419 - Return Accept-Ranges from DefaultServlet
Return Accept-Ranges from DefaultServlet
Status: RESOLVED FIXED
Product: Tomcat 6
Classification: Unclassified
Component: Catalina
unspecified
All All
: P2 normal (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2008-07-17 07:38 UTC by Mike Bremford
Modified: 2014-02-17 13:42 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Bremford 2008-07-17 07:38:07 UTC
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.
Comment 1 William A. Rowe Jr. 2008-07-17 08:02:53 UTC
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.
Comment 2 William A. Rowe Jr. 2008-07-17 08:09:48 UTC
Ignore comment #1; bugzilla navigation bites again; this relates to another issue.
Comment 3 Remy Maucherat 2008-07-24 06:34:02 UTC
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.
Comment 4 Remy Maucherat 2008-07-24 06:34:40 UTC
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.
Comment 5 Mike Bremford 2008-07-24 07:08:05 UTC
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.
Comment 6 Jess Holle 2008-07-24 07:50:18 UTC
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.]
Comment 7 Mike Bremford 2008-07-24 08:13:35 UTC
Yes, the Apache web server sets this header.
Comment 8 Fred Toth 2008-09-14 18:32:43 UTC
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.
Comment 9 Mark Thomas 2008-09-17 12:28:26 UTC
This has been fixed in trunk and proposed for 6.0.x. It is enabled by default but can be disabled if required.
Comment 10 Mark Thomas 2008-09-19 04:12:14 UTC
This has been fixed in 6.0.x and will be included in 6.0.19 onwards.
Comment 11 Kapil 2009-05-14 23:30:15 UTC
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
Comment 12 Kapil 2009-05-15 01:25:39 UTC
(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
Comment 13 Mark Thomas 2009-05-15 06:04:06 UTC
Bugzilla is not a support forum. You should use the Tomcat users mailing list or perhaps the equivalent for JBoss.