Re: Issue 128574 in chromium: Fileupload using html fileupload control fails in Chrome 19.0.1084.46 m with Windows Authentication

95 views
Skip to first unread message

chro...@googlecode.com

unread,
May 21, 2012, 12:09:17 AM5/21/12
to chromi...@chromium.org
Updates:
Summary: Fileupload using html fileupload control fails in Chrome
19.0.1084.46 m with Windows Authentication

Comment #15 on issue 128574 by tk...@chromium.org: Fileupload using html
fileupload control fails in Chrome 19.0.1084.46 m with Windows
Authentication
http://code.google.com/p/chromium/issues/detail?id=128574

(No comment was entered for this change.)

chro...@googlecode.com

unread,
May 21, 2012, 1:39:36 AM5/21/12
to chromi...@chromium.org

Comment #16 on issue 128574 by sato...@chromium.org: Fileupload using html
fileupload control fails in Chrome 19.0.1084.46 m with Windows
Authentication
http://code.google.com/p/chromium/issues/detail?id=128574

Hmm, the code I touched (net/base/upload_data.cc etc.) was nothing to deal
with windows authentication so I have no idea why uploading is failing with
windows authentication. Who'd be most familiar with windows authentication?

FWIW, the comment in the original report "But when I copy the Inputstream
to a byte array, all the bytes have zero value." reminded me of a code in
upload_data.cc where the data was padded with zero, if the file was shorter
than originally observed:

if (num_bytes_consumed <= 0) {
// If there's less data to read than we initially observed, then
// pad with zero. Otherwise the server will hang waiting for the
// rest of the data.
memset(buf, 0, num_bytes_to_read);
}


chro...@googlecode.com

unread,
May 21, 2012, 5:31:27 AM5/21/12
to chromi...@chromium.org

Comment #17 on issue 128574 by vittalai...@gmail.com: Fileupload using html
fileupload control fails in Chrome 19.0.1084.46 m with Windows
Authentication
http://code.google.com/p/chromium/issues/detail?id=128574

I am seeing the same behaviour with:

OS: Win 7
Chrome: 19.0.1084.46
Server: Apache 2.2.3 with mod_auth_kerb for authentication

I see the following traffic:

1) Chrome sends the POST with the form data but without the Authorization
header
2) Server responds with a 401 and "WWW-Authenticate: Negotiate" header
3) Chrome resends the post with an appropriate Authorization header, but
the upload is composed entirely of null bytes (though the same byte size as
the intended file).

Disabling the negotiate and ntlm authentication schemes in Chrome and
re-trying the upload succeeds.

Regards
Vittal

chro...@googlecode.com

unread,
May 21, 2012, 6:44:15 AM5/21/12
to chromi...@chromium.org
Updates:
Owner: asa...@chromium.org
Cc: -asa...@chromium.org sato...@chromium.org r...@chromium.org

Comment #18 on issue 128574 by cben...@chromium.org: Fileupload using html
fileupload control fails in Chrome 19.0.1084.46 m with Windows
Authentication
http://code.google.com/p/chromium/issues/detail?id=128574

OK, assigning to Asanka for now since this looks related to Negotiate/NTLM
auth only. That being said, I don't really know of many changes there
recently.

chro...@googlecode.com

unread,
May 21, 2012, 8:23:35 AM5/21/12
to chromi...@chromium.org

Comment #19 on issue 128574 by vittalai...@gmail.com: Fileupload using html
fileupload control fails in Chrome 19.0.1084.46 m with Windows
Authentication
http://code.google.com/p/chromium/issues/detail?id=128574

Attached is a dump of the HTTP request/response session showing this
problem in action.

Attachments:
chrome-upload-dump.zip 15.1 KB

chro...@googlecode.com

unread,
May 21, 2012, 9:12:06 AM5/21/12
to chromi...@chromium.org

Comment #20 on issue 128574 by thomas.t...@gmail.com: Fileupload using html
fileupload control fails in Chrome 19.0.1084.46 m with Windows
Authentication
http://code.google.com/p/chromium/issues/detail?id=128574

Same issue. net-internals dump attached. I have verified in Wireshark that
Chrome actually posts all NULL bytes on the second attempt, as per comment
#17.

Attachments:
net-internals-log (1).json 165 KB

chro...@googlecode.com

unread,
May 21, 2012, 10:49:08 AM5/21/12
to chromi...@chromium.org

Comment #21 on issue 128574 by thomas.t...@gmail.com: Fileupload using html
fileupload control fails in Chrome 19.0.1084.46 m with Windows
Authentication
http://code.google.com/p/chromium/issues/detail?id=128574

Could someone with an existing build environment try backing out r123677?
Specifically, I strongly suspect that the file stream is not properly
rewound there (should probably either happen in
UploadData::Element::ReadFromFileSync or in
UploadData::Element::ResetOffset) when ReadFromFileSync is called
repeatedly.

chro...@googlecode.com

unread,
May 21, 2012, 12:31:56 PM5/21/12
to chromi...@chromium.org
Updates:
Owner: sato...@chromium.org
Cc: asa...@chromium.org

Comment #22 on issue 128574 by sato...@chromium.org: Fileupload using html
fileupload control fails in Chrome 19.0.1084.46 m with Windows
Authentication
http://code.google.com/p/chromium/issues/detail?id=128574

The theory in comment 21 sounds correct. UploadData::Element::ResetOffset()
is just setting the offset to 0, but we should probably close the stream
too, so we can read the file from the beginning again.

Can anyone in MTV reproduce this issue? I'm guessing that the fix is easy
as long as we can reproduce this locally.

chro...@googlecode.com

unread,
May 21, 2012, 1:04:59 PM5/21/12
to chromi...@chromium.org

Comment #23 on issue 128574 by thomas.t...@gmail.com: Fileupload using html
fileupload control fails in Chrome 19.0.1084.46 m with Windows
Authentication
http://code.google.com/p/chromium/issues/detail?id=128574

FWIW, this also crops up with basic authentication. I've set up a very
simple demo at
http://www.themel.com/chromium-128574/ - user name and password is
test/test.

If you submit the form with Chrome 19, submitted file content will be all
zeroes and the CGI will respond "All zeroes, meh".

Source attached, should run on any post-1995 Apache/Perl combo.

Attachments:
chromium-128574.tar.gz 797 bytes

chro...@googlecode.com

unread,
May 21, 2012, 1:15:59 PM5/21/12
to chromi...@chromium.org
Updates:
Status: Started

Comment #24 on issue 128574 by sato...@chromium.org: Fileupload using html
fileupload control fails in Chrome 19.0.1084.46 m with Windows
Authentication
http://code.google.com/p/chromium/issues/detail?id=128574

thomas, thank you for setting this up! I was able to reproduce the issue
and got "All zeroes, meh" with

Google Chrome 19.0.1084.46 (Official Build 135956) beta
OS Linux

I'm going to create a patch shortly.

chro...@googlecode.com

unread,
May 21, 2012, 1:25:59 PM5/21/12
to chromi...@chromium.org
Updates:
Cc: w...@chromium.org j...@chromium.org m...@chromium.org
lafo...@chromium.org
Labels: -Pri-1 Pri-0

Comment #25 on issue 128574 by j...@chromium.org: Fileupload using html
fileupload control fails in Chrome 19.0.1084.46 m with Windows
Authentication
http://code.google.com/p/chromium/issues/detail?id=128574

Adding Wan Teh, as I've had discussion about this code recently (re:
comment 16, and NULL padding code), and he's also possibly most expert on
the authentication negotiation.

I'm also upping the priority to P0, as this seems extremely important to
resolve ASAP.

chro...@googlecode.com

unread,
May 21, 2012, 1:42:01 PM5/21/12
to chromi...@chromium.org

Comment #26 on issue 128574 by sato...@chromium.org: Fileupload using html
fileupload control fails in Chrome 19.0.1084.46 m with Windows
Authentication
http://code.google.com/p/chromium/issues/detail?id=128574

I created a patch for the fix, and got this now: "Yay, non-zero" from
thomas's server. Now working on a test...


% git diff
diff --git a/net/base/upload_data.cc b/net/base/upload_data.cc
index 71d77ae..1c7ee20 100644
--- a/net/base/upload_data.cc
+++ b/net/base/upload_data.cc
@@ -114,6 +114,17 @@ uint64 UploadData::Element::BytesRemaining() {
return GetContentLength() - offset_;
}

+void UploadData::Element::ResetOffset() {
+ if (file_stream_) {
+ // Temporarily allow until fix: http://crbug.com/72001.
+ base::ThreadRestrictions::ScopedAllowIO allow_io;
+ file_stream_->CloseSync();
+ delete file_stream_;
+ file_stream_ = NULL;
+ }
+ offset_ = 0;
+}
+
FileStream* UploadData::Element::OpenFileStream() {
scoped_ptr<FileStream> file(new FileStream(NULL));
int64 rv = file->OpenSync(
diff --git a/net/base/upload_data.h b/net/base/upload_data.h
index c9796ac..9212625 100644
--- a/net/base/upload_data.h
+++ b/net/base/upload_data.h
@@ -130,7 +130,7 @@ class NET_EXPORT UploadData
uint64 BytesRemaining();

// Resets the offset to zero, so that the element can be reread.
- void ResetOffset() { offset_ = 0; }
+ void ResetOffset();

private:
// Returns a FileStream opened for reading for this element, positioned


Reply all
Reply to author
Forward
0 new messages