Open Bug 901342 Opened 7 years ago Updated 2 years ago

XMLHttpRequest fails to send files when authentication is required


(Core :: DOM: Core & HTML, defect, P5)

22 Branch





(Reporter: bugs-mozilla, Unassigned)



(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130624104218

Steps to reproduce:

Firefox fails to send a file (select by user through <input type='file'>)
via PUT method to a server which requires authentification.  Things are
fine, plain data (e.g. a string) are sent, or when the server does not
require authentication.

I am using the following html code:

----------------- /srv/www/test/test.html -----
<!DOCTYPE html>
    <title>File upload</title>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
    <script type="text/javascript">
function send_file(btn) {
var req = new XMLHttpRequest();
var file = document.getElementById('file').files[0];
req.withCredentials = true;'PUT', "./x/file", true);

    <input id='file' type='file'/>
    <input type="submit"
           onClick="try { send_file(this); } catch (e) {} return false;"/>

Apache httpd (2.2.3) is configured as

ScriptAlias /test/x	/srv/www/test/x
<Directory /srv/www/test>
    Script PUT	/srv/www/test/x

    <Limit PUT>
               AuthType            Kerberos
               KrbAuthRealms       ....q
               Krb5Keytab          /etc/pki/httpd/key/krb5.keytab
               Require valid-user

E.g. when using 'req.send("aaaa")' instead of 'req.send(file)' or
invalidating the '<Limit PUT>', content is put as expected.

Actual results:

With firebug I see on both cases (working/non working) two requests:

1. 'PUT http:..../x/file' which gets a '401 Unauthorized' response
2. 'PUT http:..../x/file' with Authorization header

Sniffing on the network shows, that the second request never arrives at the server in the non-working case.
I have to correct the "Actual results" information.

Mentioned requests were seen with 'Web-Developer' plugin.

Surprisingly, with enabled 'network' module of 'Firebug' plugin, things are working as expected.

Problems still persist when firefox is started in safe-mode (e.g. neither 'Web-Developer' nor 'firebug' plugins are active).
Could you provide a living testcase (online html webpage showing the issue), please.
Flags: needinfo?(enrico.scholz)
Component: Untriaged → DOM
Product: Firefox → Core
Online test at

But problem can be seen only on server side (no second request), sniffing network traffic or with debugging.

Attached script might be more helpful.  It is to be used like

 socat TCP4-LISTEN:8001,fork,reuseaddr EXEC:"`pwd`/test-put"

and pointing firefox to http://localhost:8001

Script should show three requests (GET, PUT (401) and final PUT (201)), but firefox is missing the last one.
Flags: needinfo?(enrico.scholz)
Attachment #785722 - Attachment mime type: application/octet-stream → text/plain
still with Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0
Enrico, would you be able to check whether this is reproducible in previous versions of Firefox as well? You can find old versions at
Flags: needinfo?(enrico.scholz)
Firefox 3.6.18 (WinXP 32bit) shows the error when using GSSAPI/SPNEGO auth; basic auth seems to work with this version.

Firefox 17.0.8 (RHEL6.4, 64bit) fails with basic auth

[AppleWebKit/534.34 (KHTML, like Gecko) konqueror/4.10.5 Safari/534.34 and
 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36 work both with GSSAPI and basic auth]
Flags: needinfo?(enrico.scholz)
Still with Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0
Still with Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0
Still with Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0
Still with Mozilla/5.0 (Windows NT 5.1; rv:29.0) Gecko/20100101 Firefox/29.0

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.