Closed
Bug 901342
Opened 12 years ago
Closed 1 year ago
XMLHttpRequest fails to send files when authentication is required
Categories
(Core :: DOM: Networking, defect, P5)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bugs-mozilla, Unassigned)
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
|
1.38 KB,
text/plain
|
Details |
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>
<html>
<head>
<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;
req.open('PUT', "./x/file", true);
req.send(file);
}
//-->
</script>
</head>
<body>
<input id='file' type='file'/>
<input type="submit"
onClick="try { send_file(this); } catch (e) {} return false;"/>
</body>
</html>
------------------------
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
</Limit>
</Directory>
---------
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.
| Reporter | ||
Comment 1•12 years ago
|
||
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)
Comment 3•12 years ago
|
||
Online test at http://www.cvg.de/test/putfile.html
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)
Updated•12 years ago
|
Attachment #785722 -
Attachment mime type: application/octet-stream → text/plain
Comment 4•12 years ago
|
||
still with Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0
Comment 5•12 years ago
|
||
Enrico, would you be able to check whether this is reproducible in previous versions of Firefox as well? You can find old versions at ftp://ftp.mozilla.org/pub/firefox/releases/.
Flags: needinfo?(enrico.scholz)
Comment 6•12 years ago
|
||
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)
Comment 7•12 years ago
|
||
Still with Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0
Comment 8•12 years ago
|
||
Still with Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0
Comment 9•12 years ago
|
||
Still with Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0
Comment 10•11 years ago
|
||
Still with Mozilla/5.0 (Windows NT 5.1; rv:29.0) Gecko/20100101 Firefox/29.0
Comment 11•7 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046
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
| Assignee | ||
Updated•7 years ago
|
Component: DOM → DOM: Core & HTML
Updated•3 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Component: DOM: Core & HTML → DOM: Networking
Comment 12•1 year ago
|
||
I am not sure if this is a bug anymore given our changes we have done in the necko and dom code around xhr in the last few years.
I will try to recreate the scenario and see if this is a bug.
Flags: needinfo?(smayya)
Whiteboard: [necko-triaged]
Comment 13•1 year ago
|
||
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Flags: needinfo?(smayya)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•