Streaming pdf. Opens up before fully loaded on some sites

S

Sjodan

New Member
I am throwing this question out there since I am stumped . I’ll try to explain the problem as closely as I can, but it can get rather long-winded I’m afraid, and I don't really think that there is a webspeed problem either to be honest, it just so happens that there is a problem that occures in a webspeed application.

We have an application that displays invoices to be attested by users. One part of the page is an iframe into which we stream the actual invoice image as a pdf using the following code:

INPUT STREAM inputfile FROM VALUE(ip_filefullpath) BINARY NO-ECHO.
LENGTH(vfileline) = 1024.
REPEAT:
IMPORT STREAM inputfile UNFORMATTED vfileline.
PUT {&WEBSTREAM} CONTROL vfileline.
PAUSE 1 NO-MESSAGE.
END.
INPUT STREAM inputfile CLOSE.
INPUT CLOSE.
LENGTH(vfileline) = 0.

The header for the page is done with the following:

run output-header-custom( input vShortName, input "application/pdf", input bAttachment, INPUT FILE-INFO:FILE-SIZE ).
procedure output-header-custom:
define input parameter ipcShortname as CHAR NO-UNDO.
define input parameter ipcContentType as CHAR NO-UNDO.
define input parameter ipbAttachment as LOGICAL NO-UNDO.
define input parameter ipiFilesize as INTEGER NO-UNDO.
if ipbAttachment then
output-http-header ("Content-disposition","Attachment; filename=" + ipcShortname).
output-http-header("Accept-Ranges":U,"bytes":U).
output-http-header ("Content-Length",STRING(ipiFilesize)).
OUTPUT-CONTENT-TYPE( ipcContentType ).
end procedure. /* output-header-custom */

We have been using this method of streaming our invoices for years. The application runs on servers administrated by our clients and this one client has just changed the server on which the application is run. After this change users have been reporting that they get an error when they try to scroll down in large pdf images. If the pdf is about four pages or more and they scroll down when it opens up the browser locks up and eventually an error message appears that a network problem has occurred while trying to open the file.

Now, I have seen this problem for myself while borrowing one of our users account and it appears that the pdf opens up in the browser before it has fully loaded. With the invoice I tried I saw the loading bar of Adobe Reader up to about 50kB of a 405kB file before it opened up in the browser. Then when I scrolled down IE9 locked up and I eventually got an error message. If I wait for the file to load fully in the background everything works perfectly (I get no indication that the page is loading or when the file is fully loaded using Windows 7 and IE9 however)

I grabbed the very same pdf that gave me the error and put it into my development environment and opened it up there. There it loaded the full 405kB file before it opened it up in the browser. I also tried to open up even larger files (up to 20000kB) and I could never get it to open up in the browser before it was fully loaded. So the image was the same, the client was the same (my Windows 7 computer using Adobe Reader X version 10.1.0 and IE9) and the application code was the same. But on one site the pdf opens up before it is loaded and on the other it does not.

I have played around with the settings in Adobe Reader where there were a few things that sounded like they could potentially have an effect on this problem, but no matter what settings I use in Adobe Reader I still get the same results. If there was a problem with my client or my settings it doesn't explain why it would behave differently for different sites either.

We have this application running on about 20 different sites with thousands of users and it is only on this one site that this exact problem ever occurs (for all users there though it would seem). It seems to me that the problem must be something with the server setup, but what about that could possibly affect how the userclient behaves? And if there is no problem with the server setup, then why would my client behave differently for different sites when everything else is the same? We are not responsible for the administration of the server, so I am unfortunately not able to check the setup there for myself. The administrator of the server pretty much just refers the problem to us however, so I guess I have to try tfind some sort of solution.

So, does anyone have any ideas about what could be causing these problems? Any ideas at all?
 
a) why are you using the http header 'Accept-Ranges'? Try either removing it or changing it to 'none'.
b) have you tried another browser at this site? Firefox for example.
c) does the site where the pdfs fail go through a proxy server? if so, is that configured differently?

Lee
 
Thank you for your reply.

I don't really know why we are using the 'Accept-Ranges' header to be honest. That code was written several years ago by a co-worker that has since left us and we have not had any problems with it until now, so I haven't had to give it much thought. I'll go ahead and remove the line and see if that does anything, alternatively set it to none.

I did try to view pdf in different browsers and the problem remains the same both in Firefox and Chrome.

The sites does not go through a proxy.

Yeasterday afternoon we also got another report of the same problem from another site, which should be good for troubleshooting the issue if nothing else. The thing that both sites have in common appear to be that they have both recently changed servers and are now using IIS7, so I suspect that the problem might have something to do with how that is set up. I don't personally know much about that sort of thing though I'm afraid.

I have however found a somewhat ugly workaround that works that seem to fix the immidiate problem to just get the users to be able to see their invoices. When I instead of "application/pdf" I use "application/octet-stream" the pdf-reader on the client side does not open the pdf before it is fully loaded. With that it works exactly the way I would want it to (loading fully before displaying), except for the fact that it makes it very slow. It takes a number of seconds just to get to the point where the pdf-reader shows the loadingbar. It takes up to about 20seconds for a five page pdf just to get to the point where it starts loading in the file. A different and more permanent solution is most definately needed, but seeing as how "slow" is better then "not working" I guess it will have to do until I can find what the actual problem is and a more permanent solution.
 
Guessing Time.

**GUESS STARTS HERE***

Here is what I think. I'm guessing that a newer/updated version of the PDF reader plug-in (Adobe Acrobat) is trying to take advantage of the "Accept-Ranges" functionality. When the user scrolls down through the pages before the PDF content a has be fully delivered from WebSpeed, it's applying an asynchronous web request to fetch part of the of the PDF document for a particular page.

My recommendation would be to remove output-http-header("Accept-Ranges":U,"bytes":U). Statement. This has probably (I'm guessing again) not never been an issue because in the past because older versions of Adobe Acrobat reader never made asynchronous web request.

Or alternative if Adobe Acrobat is in fact making asynchronous web request, change your code to handle the web requests for bytes range and deliver what is requested.

**GUESS ENDS HERE***

Also why is there a PAUSE 1 NO-MESSAGE. in the export to webstream loop?

Also here is what I have in my http header when I deliver PDF documents:

output-http-header("Status",'200 OK').
output-http-header("X-Powered-By":U, SUBSTITUTE('&1 &2',PROVERSION, OPSYS)).
output-http-header("Content-Transfer-Encoding", "binary").
output-http-header("Content-MD5", STRING(MD5-DIGEST(mpData))).
output-http-header("Content-Length",STRING(GET-SIZE(mpData))).
output-http-header("Content-Disposition", SUBSTITUTE('inline~;filename=&1', get-field('filename')) ).
output-content-type (SUBSTITUTE('application/pdf; name=&1':U,get-field('filename'))).

{&OUT-LONG} mpData.



I know this might not fix your problem however might try
 
Other thing to look at. But I bet my bottom dollar you have already tried it.

To set your internet preferences in Adobe Acrobat,
1. Choose ‘Edit’ on the top menu and select ‘Preferences’.
2. From the menu on the left-hand side, select ‘Internet’.
3. In the ‘Web Browser Options’ section, check the options that best suit your needs.
a. Display PDF In Browser - allows any PDF opened from the web to display inside the current browser window. If this option is not selected, PDF documents open in a separate Acrobat window.
b. Allow Fast Web View - downloads PDF files for viewing one page at a time. If this option is not selected, the entire file downloads before it is displayed.
c. Allow Speculative Downloading in the Background – allows a PDF file to continue downloading from the web, even after the first requested page displays. Downloading in the background stops when any other task, such as paging through the document, is initiated in Acrobat.
4. Unless you have Administrative Rights for the computer you are using, ignore the ‘Internet Options’ section.
 
I think rather than older versions of Acrobat not supporting the Accept-ranges option it's actually the server side that hasn't supported it in the past. On the couple of sites that are now broken my guess is that these have got more recent versions of IIS.

Regards, Lee
 
You must log in or register to reply here.
Back
Top