Michael S�dkamp wrote:
Hello,

I investigated the topic of byte-range-serving from the
DefaultServlet with Acrobat 6.

I noticed that Tomcat 4.1.30 did not any byte-range-serving with
Acrobat 6.0.0. The entire file was sent instead.

I compared the HTTP communication with that of Internet Information
server where byte-range-serving of PDF files works. Here are my
results:

1. HTTP header Acrobat does not request byte-ranges unless the server
sends the header "Accept-Ranges: bytes". Once I added this header,
Acrobat requested byte-ranges.
From the HTTP 1.1 spec I read that sending this header is not
required, but Acrobat seems to need it.

Well, sorry, but I don't see any good reason to send this filter. Use a filter.


2. blanks in multi-byte-range-requests After having added the header
above, Acrobat sent byte-range-requests. But Acrobat choked. I did a
packet filtering and recognized the following status code sent by
Tomcat "416 request range not satisfiable". The reason was that
Acrobat sent multi-byte-range-request using e.g. the following string
 "1000-2000, 3000-3010" Notice the blank character. It leads to a
parsing exception in line 1300 of the DefaultServlet (Tomcat 4.1.30).
If you do a trim() on the rangeDefinition obtained there, this error
does not occur.

Please prove using the HTTP spec that it has to be done that way.

3. newline before Mime-separator-string After fixing step 2 Acrobat
did not choke anymore. However, the pdf file was still served
entirely. Further comparison with the IIS communication revealed that
ISS writes the mime-separation-string ("CATALINA_MIME_BOUNDARY" for
Tomcat) on a line line, whereas Tomcat does not. After prefixing the
println-commands with "\n" (lines 1910, 1930, 1964, 1984), it finally
worked.

Same as 2).

I wonder if you would consider to change the DefaultServlet. IMO
Acrobat is a very important application, and unless it doesn't
explicitly violate the HTTP spec Tomcat should support it.

Acrobat 6 is terrible. The performance decrease over the previous release is simply staggering (and gPDF becomes yet another good reason to switch to Linux).


R�my


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to