You may experience problems with a returned file if you submit an HTTP or HTTPS request that ends with a file extension. The web browser can interpret the request improperly. If Arbortext Publishing Engine passes the content-type header correctly (for instance, application/pdf) in its response to the browser, the web browser may ignore the content-type header and try to render the response based on a file extension occurring at the end of the URL. To avoid this problem, you may want to structure an HTTP request so that file extensions do not appear at the end.

In the following example, the first request may cause a problem. By reordering the parameters in the same request, as in the second example, the request will succeed. The best practice is to place the f=java, f=javascript, f=vbscript, f=acl, or f=convert specification at the end of the URL.

The following HTTP f=acl request may cause a problem because the request ends in .xml. The web browser may try to interpret XML as the content-type, rather than the PDF content-type which is specified and is the content-type that will be returned. Ignore the line breaks in the examples:

The following HTTP request will succeed because the URL ends with the f=acl specification, which won't confuse the web browser:

You may also want to take advantage of the fact that the web browser can interpret content-type from a URL that ends in a file extension. You can include a dummy parameter at the end of the URL to specify a file extension, for example, dummy=file.pdf for a PDF file. The dummy parameter will be ignored by Arbortext Publishing Engine, but the web browser may try to render the response based on the file extension .pdf occurring at the end of the URL.