Inline PDF broken (only first page) in Chrome since fix #1193

[fashberg]

Hi,

i'm displaying PDFs inline and chrome only shows the first page.

The error was introduced here #1193 / aaf41e6

The code change was not to pass the URL directly but to pass with an dynamically loaded form passing the parameters with HTTP-POST.

Chrome seems to load the first bytes of the document and renders the first page but everything else is missing.

In Chrome Web-Developer you can see a cancelled second request, maybe because Chrome doesn't want to send the POST-request again, but the complete Document is not loaded at once again, so it stucks at the first page without any error – despite the users minds the Page 1 of X.

Reproduceable in current Chrome running Windows and Linux.
Not reproducable in Firefox, IE or Edge.

Tested with latest 2.1 nightly, PHP Connector with LocalFileSystem

Fix is to comment out:

if (url.indexOf(fm.options.url) === 0) {
     url = '';
}

elFinder/js/commands/open.js

Line 118 in 0360abe

if (url.indexOf(fm.options.url) === 0) {

I've investigated same time and found the reason:
The combination of "Accept-Ranges: bytes" and the POST-Request is the Problem!

If Chrome sees the "Accept-Ranges" header it stops probably after some bytes and starts later with a Range-Request - but the range request fails, because this is not valid!

See RFC https://tools.ietf.org/html/rfc7233

3.1 Range
[..]
A server MUST ignore a Range header field received with a request method other than GET.

Since elFinder sets “Accept-Ranges” and the “fix” introduced in #1193 sets all parameters with POST the Range-Mechanism gets broken.

Apache answers on the request

HTTP/1.1 416 Requested Range Not Satisfiable

So disabling it, e.g. by setting

header('Accept-Ranges: none');

in PHP before “new elFinderConnector()” also fixes this issue.

Or not using POST but get

form.method = 'GET';

also fixed it – but introduces a new problem: My connector is called with

connector.php?id=xxxx

So when using GET my “id=xxx” gets lost (correct behavior on GET-Requests not to combine the parameters at "action=" and the form-fields).

Here some lines which are adding all existing GET-Parameters (if any) as hidden fields which keeps the form-initiated opening of the requested file as introduced in #1193 but now with POST and not to brake the Accept-Ranges behavior.

if (url === '') {   
    /* extract ?name1=val1&name2=val2 from url - if any */
    /* otherwise using http-GET old ones are getting lost */
    /* Using POST is not possible, because it conflicts with HTTP-Range-Header */
    var match,
        pl     = /\+/g,  // Regex for replacing addition symbol with a space
        search = /([^&=]+)=?([^&]*)/g,
        searchfirst = /.*\?(.+)/g,
        decode = function (s) { return decodeURIComponent(s.replace(pl, " ")); },
        query  = "";
        var oldparams = {};
        if (match = searchfirst.exec(fm.options.url)){
            query=match[1];
        while (match = search.exec(query))
            oldparams[decode(match[1])] = decode(match[2]);
        }

    var form = document.createElement("form");
    form.action = fm.options.url;
    form.method = 'GET';
    form.target = 'new_window';
    form.style.display = 'none';
    var params = $.extend(oldparams, fm.options.customData, {
        cmd: 'file',
        target: file.hash
    });
    $.each(params, function(key, val)

Kind Regards

Folke

[nao-pon]

@fashberg Thanks! 👍