Business Server Pages [Read-only]
Page tree
Skip to end of metadata
Go to start of metadata

This troubleshooting guide contains many different aspects around the handling of file up and downloads. Especially GZIP aspects, and also the different behaviours of the file upload mechanism of the browser.

File Downloading

A very good article (BSP Programming: Handling Of Non-HTML Documents) is available to describe different aspects that should be considered with file downloading, and show a number of techniques in how this can be handled.

PDF: GZip Compression

Example Symptom: When you try to view a .pdf file in Internet Explorer, you may see a blank window or frame instead of the .pdf file. This may occur even though you have installed the Adobe Acrobat Reader program, and you are normally able to view .pdf files in that program.

Often we see problems with the display of PDF documents. In some combinations it might work, but in others if fail (usually specific combinations of IE and Acrobat). All the problems seems to be related to the use of GZIP compression. As first test/workaround, reconfigure the browser to only use HTTP/1.0, where GZIP is not available, nor supported. Usually the display of the PDF will then suddenly work.

TroubleShooting: To quickly test this, disable HTTP/1.1 (which implies HTTP/1.0 which does NOT support compression).

We generally recommend in ALL cases to disable GZIP compression for PDF documents. This can usually done on the specific BSP page from which the PDF document is send out. Use HTTP proxy tool to confirm that PDF documents are not compressed during transfer. As brute force workaround, it can be considered to completely disable compression for the complete application server. See Global deactivation of GZIP compression for HTTP.

There is a feature in ICM whereby compression can be selectively disabled (640 patch>=?? and 700 patch>=??). With this technique it will be possible to disable compression at kernel level for all PDF documents from the beginning, making it easy to configure the error possibility away. The kernel will recognize the following parameters (see also Tie HTTP request and response to disable GZIP in Kernel):

  ict/min_compression_size = <minimum byte size to start compression>
    default: 0

  ict/exclude_compression = <comma-separated-list of file-patterns to exclude from compression>
    default: *.gif,*.zip,*.cs,*.rar,*.arj,*.z,*.gz,*.tar,*.lzh,*.cab,*.hqx,*.ace,*.jar,*.ear,
             *.war,*.css,*.pdf,*.js,*.gzip,*.uue,*.bz2,*.iso,*.sda,*.sar

It is recommended in all cases to set this new profile parameter (once available) to disable compression for PDF documents.

Also, the Adobe Reader product may be unable to display a PDF file inside a compatible web browser window if the Acrobat product can't read the PDF file or if the web browser is not configured correctly with the Adobe PDF Reader plug-in. Below is the checklist:

  • If there are two versions of Adobe Acrobat Reader in the system, uninstall both the versions and then install the latest version and the latest update.
  • Open Adobe Acrobat Reader and go to 'Edit' -> 'Preferences'. Choose Internet in the Preferences window. Enable the 'Display PDF in browser' option and close the dialog.
  • Ensure the Adobe Reader ActiveX Add-On is registered in the system and the 'Run ActiveX Controls And Plug-ins' option is enabled in the security options in Internet Explorer.

GZIP/PDF (Adobe 6.0) and Long URLs

Some customers experience problems with Adobe Acrobat Reader 6.0, specifically it is not possible to print any PDF documents. These problems only appear when running the BSP application inside the portal. The reason for that is the 261 chars limitation for the length of the URL associated with the PDF file, which is a feature/bug of the Adobe Acrobat Reader 6.0. When running a BSP application inside the portal, the URL mangling is extended to also include both a session-ID and the themeRoot from the portal to use. This blows the URL length to well pass 400 bytes, causing the problems within the Acrobat Reader. In principle the problem is within the Acrobat reader, and we expect at some stage that Adobe will provide a fix for this.

We have already reviewed these long URLs, especially also under the aspect that they cause problems with GZIP in HTTP/1.1 (See GZIP Compression Errors With HTTP/1.1 and long URLs). What we did was to remove and strip out the theme stuff from the mangling and cache them in the session (and on the database). These changes were done in 620SP54, 640SP14 and 700SP03. Unfortunately, the changes are of a slightly complex nature, making it difficult to provide these via Note Assisted corrections.

How to Display Dynamic Generated Picture?

  • Question:* How to display dynamically generated pictures on the BSP page?

Answer: So let us for the moment assume that you have a JPG in the hand (internal table is also good), and want to send it to the browser. We assume that this picture is only required for display, and can then be dumped. In no way would we recommend the MIME repository for such cases. This involves a lot of database work, and is very (time) expensive. The best approach is to take the picture, place it in a response object, generate a temporary URL (using a GUID), and storing this response + URL in the ICM cache. Then you send out your HTML document with a <img src="URL">.

The browser will automatically load the image from the cache. After the predefined timeout, the ICM will throw the picture from the cache. About writing into the cache, etc. look at the documentation.

You can also look in the class CL_HTMLB_CHART for an example from the IGS colleagues. Recommended is to play a little with SBSPEXT_HTMLB/chart.bsp. Look at coding, and generated HTML source.

File Upload: Changing the "Browse..." Text

In HTML, a file upload can only be done <input type=file>. This HTML code will have the browser render out the "Browse..." button. The text on this button is supplied by the browser, and can not be in any way influenced from HTML. The language used for the text is influenced by the language configured in the browser! Typical example, people configure their browsers for example with default language in German, but log onto a BSP application in English. Then the rendered pages will all be in English. Only the text on the "Browse..." buttons will be in German, as this is the configured language in the browser.

This is the way that the browser work, and it can not be changed. Please read INPUT TYPE="FILE" and your options... for a description and Input=FILE, how to hide the plain browse button for one "hack" to actually change the button. However, use this at your own peril and don't cry when you actually do!

File Upload: Dynamically Setting the FileName

Many times we receive questions about dynamically setting the file name for the file to upload. In short: this is NOT possible. Otherwise, it would be simple for the server to snag files from the client without the user's knowledge. Any files that must be uploaded, must be actively set by the user. There is no way around this.

An variation of the problem is that the user selected one file for upload. Then a completely separate button is pressed to quickly firean event back to the server. Of course, when now the new HTTP response page is rendered, the file upload field is empty! This works as designed (security feature from browser). It is NOT possible for the server to read and restore the filename that the user wanted to upload.

File Upload: Access Denied with IE6+ under WinXP SP2

Reference: XPSP2: Fully qualified path for "input type=file".

To improve security within the IE6 browser, it is required from IE6 (WinXP) SP2 onwards to have all file names fully qualified. What this means is that a file name "image_007.gif" is definitely NOT accepted. The file name MUST be specified as "c:\myImages\image_007.gif". There are two variations of this problem:

  1. If the form is submitted with the sequence <input type=submit>, nothing occurs.
  2. If JavaScript is used to submit the form with the sequence form.submit();, an Access is Denied scripting error is generated.

This second form is the typical error that will be expected with the use of the <htmlb:fileUpload> tag.

For detailed information on this change, please refer to Microsoft's Knowledge Base.

HTTP rc=500 with Upload of Files

Microsoft Security Updates 832894 or specifically the hotfix 821814 can sporadically cause a HTTP rc=500 (Page not Found) error. This is caused by a bug in IE. One recommended workaround is to configure the keep-alive time of the server to above 60 seconds, up from the default 30 seconds (icm/server_port_< x > = ... TIMEOUT=90, ...). Reference HTTP 500 error in HTTPS post requests for details.

Cannot Download File

Reference Internet Explorer file downloads over SSL do not work with the cache control headers. While running in HTTPS mode, the browser refuses to download a file, and gives the following error message:

  Internet Explorer cannot download <filename> from <host>.

  Internet Explorer was not able to open this Internet site.
  The requested site is either unavailable or cannot be found.
  Please try again later.

It is very important to understand that this error message happens only while running in HTTPS mode. Exactly the same page in HTTP mode will work perfectly without any error messages.

The problem is related to the typical approach that programmers take to set HTTP headers for caching. As BSP pages are by default used to display dynamic BSP pages, the BSP runtime will automatically set HTTP headers to instruct the browser not to cache the HTTP response. Often programmers will add additional HTTP headers that also influence caching. Once the browser downloads a file, that must be passed to an external program to display, it is forced to write the content onto a temporary file on disk, so that the external program can be started against this file. While running in HTTP mode, the browser will ignore some of the cache headers and force write the downloaded content to disk. However, when running in HTTPS mode, the security mechanism from the browser refuses that the file be written to disk at all if the "don't cache" headers are set. Thus the file can not be stored temporarily, and the error message is displayed. The typical headers that one should look at, are: Expires, Pragma and Cache-Control.

As a first step to understand the problem, we wrote a small test program. It will be shipped in future service packs with the BSP application system_test, page test_https_download.csv.

 <%
  IF request->get_form_field( 'DoIt' ) IS NOT INITIAL.

    response->set_header_field( name = 'Content-Type'        value = 'application/octetstream' ).
    response->set_header_field( name = 'Content-Disposition' value = 'attachment; filename=test_https_download.csv' ).
    response->set_header_field( name = 'Connection'          value = 'close' ).

    DATA: expires TYPE string. expires = request->get_form_field( 'expires' ).
    DATA: pragma  TYPE string. pragma  = request->get_form_field( 'pragma' ).
    DATA: cc      TYPE string. cc      = request->get_form_field( 'cc' ).

    IF expires IS NOT INITIAL.
      response->set_header_field( name = 'Expires'       value = expires ).
    ENDIF.
    IF pragma IS NOT INITIAL.
      response->set_header_field( name = 'Pragma'        value = pragma ).
    ENDIF.
    IF cc IS NOT INITIAL.
      response->set_header_field( name = 'Cache-Control' value = cc ).
    ENDIF.

    DATA: html TYPE string.
    CONCATENATE `a;b;c` cl_abap_char_utilities=>cr_lf
                `1;2;3` cl_abap_char_utilities=>cr_lf
                `4;5;6` cl_abap_char_utilities=>cr_lf
                `7;8;9` cl_abap_char_utilities=>cr_lf
           INTO html.
    response->set_cdata( html ).

    RETURN.
  ENDIF.
 %>
 <html><body><form method="POST"><table>
  <tr><td> Expires:       </td><td> <input name=expires value="0">         </td></tr>
  <tr><td> Pragma:        </td><td> <input name=pragma  value="no-cache">  </td></tr>
  <tr><td> Cache-Control: </td><td> <input name=cc      value="max-age=0"> </td></tr>
  <tr><td> <input type=submit name=DoIt value="DoIt!">                     </td></tr>
 </table></form></body></html>

First we quickly test with the page in HTTP mode. The .cvs file is opened correctly. We test the same page in HTTPS mode, and see the above error message. For reference, the HTTP proxy trace is:

There are a number of interesting aspects to this picture. The first is that we are running in HTTPS mode. The second is that we have three cache relevant HTTP headers set. And the most important aspect, the HTTP response is already completely available in the browser. Reference specifically the HTTP rc=200 return code (OK) and the size reflects already the downloaded file. Now the ''File Open'' dialog is displayed, and then directly afterwards comes the "cannot download error". The content was actually available, but because of the HTTPS mode and the strict don't cache headers, the file can not be saved to start the external program. Thus the (slightly) confusing message about the site not been available. (Note that the exact window sequence differs depending browser versions, but always the same error message will be displayed; at least for IE5 and 6.)

Using the supplied test program, we can quickly determine that the HTTP header Pragma: no-cache is the critical header. Once this is removed from the HTTPS response, the page also works for HTTPS mode. (Note that these results reflect testing done on IE5 and 6, for new browsers the referenced test page should be used again to verify these results.)

This HTTP header is by default set by the BSP runtime in HTTP mode, but is NOT set in HTTPS mode. However, there is one scenario which requires special care. This is the case where a complex proxy landscape is used, that has HTTPS from the browser to the proxy and only HTTP from the proxy to the server. Here the BSP runtime did not on older service packs correctly detect the HTTPS mode from the browser, and did set this Pragma: no-cache header in-correctly. This error is fixed with File Downloads via Web Dispatcher with HTTPS->HTTP. When running in HTTPS mode with a proxy, this note must be applied.

In addition, verify that the application does not set any critical HTTP headers. Use a HTTP proxy tool to verify that no critical HTTP headers are in the HTTP response.

The problem from the browser side is also described in detail in the Microsoft Knowledgebase: Internet Explorer file downloads over SSL do not work with the cache control headers. There included are references to either a hotfix that can be downloaded on each computer, or a change to the registry to workaround the problem. This is required per computer.

References