protocol-relative urls not supported as "endpoint" values

[smcoll]

Type of issue [REQUIRED]

bug

Uploader type [REQUIRED]

S3

Bug details [DELETE EVERYTHING IN THIS SECTION IF THIS IS A FEATURE REQUEST]

Fine Uploader version [REQUIRED]

5.11.5

Browsers where the bug is reproducible [REQUIRED]

Chromium

Operating systems where the bug is reproducible [REQUIRED]

Ubuntu

Exact steps required to reproduce the issue [REQUIRED]

Specify relative path URLs in Fine Uploader request options.

All of your Fine Uploader initialization JavaScript code [REQUIRED]

$('#fine-uploader').fineUploaderS3({
    template: 'qq-template',
    objectProperties: {
        bucket: "<bucket>",
    },
    request: {
        endpoint: "//<bucket>.s3.amazonaws.com",
        accessKey: "<key>"
    },
    signature: {
        endpoint: "//example.com/upload-handler/"
    },
    uploadSuccess: {
        endpoint: "//example.com/upload-handler/success/"
    },
    retry: {
       enableAuto: true
    },
    chunking: {
        enabled: true
    },
    autoUpload: false
})

Detailed explanation of the problem [REQUIRED]

In 09cb5ef#diff-1e1ad9f5d4438601d07bc4548460fc19R196 a change was made which always prefixes the endpoint with 'https' if it doesn't start with 'http'.

One case which is not handled here is protocol-relative urls, which start with "//". i have some code which will be run over SSL in some cases and not in others. When i set an "endpoint" value like "//example.com", the link will be turned into "http://example.com" regardless of the protocol used by the page. This causes a blocked:mixed-content error in the browser.

Another side-effect is that the bucket name used in the signature request is "http". A workaround for that is to set it explicitly in objectProperties.

[rnicholus]

Thanks for the report. If you could fix this in a pull request w/ matching tests, I'd be happy to look it over and release the fix as a hotfix.