Closed Bug 684806 Opened 9 years ago Closed 8 years ago

Unable to upload 0KB file if an observer reads the upload stream and rewinds it


(Core :: Networking, defect, P2)

5 Branch





(Reporter: ssetty_ndo, Assigned: bzbarsky)


(Keywords: testcase)


(5 files, 6 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
Build ID: 20110830092941

Steps to reproduce:

i am trying to upload a zero kb file using basic form.

Actual results:

i am unable to upload zero kb file in Firefox 5 but same file upload works on Firefox 3.6

Expected results:

it should submit the form irrespective of the size of the file.
Can you provide a page where this happens?
I just checked and I can upload a 0 bytes file to my webmail into a message and it accepts it and sends the email. Using FF6 on Win XP, 32bit. This bugzilla system does not accept empty files, but that is analyzed on the server after the upload succeeds.
hi aceman,
     i have just created simple file upload form using html and tried to upload a 0kb file. when i submit it. it just doesn't do any thing and even i have tried with file more than 0 kb file then it is successfully submitting it. webemail may be using flash object for upload.
My webmail does not use flash. Can you post an URL to your form? Or can you attach the source html so we can try it?
Attached file file upload form (obsolete) —
this file has upload dorm
Comment on attachment 558518 [details]
file upload form

this file is file upload form
Attached file it just says file uploaded (obsolete) —
it just says file uploaded
please find attachment fileupload.html and result.html.

fileupload.html form will submit to result.html file.

i am using tomcat server.
Ok, on the attached testcase I can reproduce the problem. I do not see any obvious bug in your html. I tested on apache server with FF 6 and 8. Both have the problem. The Web console shows a HTTP POST request for the result.html file, however the server is never contacted (according to its log) and no reply is received by FF.
Component: General → HTML: Form Submission
Ever confirmed: true
OS: Windows 7 → All
Product: Firefox → Core
QA Contact: general → form-submission
Hardware: x86_64 → All
ssety and aceman, one of you could host those file somewhere and make a test case?
Keywords: testcase-wanted
The attached testcase worksforme on Mac, posting to

aceman, if you use that url as the action, do things work for you?  If not, is this Windows-only?
Updated the testcase to use that echo script and also fixed the HTML (strict mode, comments with 2 dashes (w3c validator complained), etc.)
Attachment #558518 - Attachment is obsolete: true
Attachment #558519 - Attachment is obsolete: true
I used the attached form using your echo script. The screenshot shows there is no reply from (I assume it was never contacted). It is from Win XP.
Comment 9 is made on Linux, that is why I changed the platform fields.
The testcase works fine in Safe mode. Must be some extension. Sorry about that :(
ssetty, can you post your list of extensions? You can find it in about:support. We can compare them to mine.
I'm able to reproduce this with yesterday trunk in debug on GNU/Linux.
Version: 5 Branch → Trunk
(In reply to Mounir Lamouri (:volkmar) from comment #16)
> I'm able to reproduce this with yesterday trunk in debug on GNU/Linux.

Goes without saying: no extensions and no plugins.
Oh, ignore comment 16 and comment 17. I was using an invalid file :(

aceman, do you use NoScript? I believe the issue you see can come from NoScript.
Could you do this and try againg:
1. Go to NoScript preferences;
2. 'Advanced' tab;
3. 'XSS' tab;
4. Uncheck "Turn cross-site POST requests [...]";
5. Click 'OK';

On a Firefox 5 clean profile with only NoScript, I had the same issue. Doing that fixed it.
Version: Trunk → 5 Branch
Yes, I also found out it is due to noscript (by disabling it).
Unchecking the feature you say fixes the problem too.
However, shy would it only stop empty files and it doesn't seem to convert the requests to GET (webconsole still shows POST).
And also, when I tested the original testcase (in obsoleted attachments) on my local server, the request was not cross-site. The feature seems to be broken and interfere wrongly. I'll contact noscript author.
I'm traveling and commenting here from my smartphone, but the data gathered so far seems to hint at an edge case mishandling in the injection checks on cross-site POST requests. Will check as soon as I'm back (tomorrow).
Attached file about:support
below is the list of my extension in firefox
Name               Version  Enabled  ID  
DownThemAll!       2.0.7    true {DDC359D1-844A-42a7-9AA1-88A850A938A8} 
FiddlerHook  true 
Firebug            1.8.1    true 
Flash Video        2.0.29   true 
Downloader Youtube Downloader Facebook
Flashbug           1.8.0    true 
Live HTTP headers  0.17     true {8f8fe09b-0bd3-4470-bc1b-8cad42b8203a} 
Page Speed         1.12     true {e3f6c2cc-d8db-498c-af6c-499fb211db97} 
WOT                20110704 true {a0d7ccb3-214d-498b-b4aa-0e8fda9a7bf7} 
YSlow              3.0.4    true 
Click to call false {82AF8DCA-6DE9-405D-BD5E-43525BDAD38A} 
with Skype
HttpWatch          7.0.23   false {1E2593B2-E106-4697-BCE7-A9D30DE05D73}
Professional Edition 
Java Console       6.0.24   false {CAFEEFAC-0016-0000-0024-ABCDEFFEDCBA} 
Java Console       6.0.26   false {CAFEEFAC-0016-0000-0026-ABCDEFFEDCBA} 
Leak Monitor       0.4.6    false {1ed6b678-1f93-4660-a9c5-01af87b323d3} 
Prism for Firefox  1.0b3    false 
RapidShare         1.0      false 
Veoh Video Compass 1.5.2    false
No Noscript??? Can you confirm the problem doesn't happen in Firefox safe mode?
i am unable to reproduce problem in Firefox safe mode.
OK, can you hunt down which extension is causing the problem for you?

HttpWatch would be my first guess to try, followed by Firebug and Live HTTP headers.
okay,i need to disable extension 1 by 1. or should uninstall extensions.
Httpwatch seems disabled in the list.
ssetty: yes try to disable them.
I cannot reproduce on a clean profile with just NoScript installed.

@ssetty: another suspect is Live HTTP Headers, but you seems to have tons of HTTP monitoring/fiddling extensions, and I wouldn't be surprised by multiple conflicts :/
Giorgio, have you enabled the option from comment 18?

These are the extensions I have enabled on one of my machines where I see the problem. Just disabling noscript out of them fixes the problem:
Card Games                  0.98          true
DOM Inspector               2.0.10        true
IE Tab +                    2.04.20110724 true
MinimizeToTray revived (MinTrayR) 1.0     true
Mozilla Archive Format            2.0.1   true  {7f57cf46-4467-4c2d-adfa-0cba7c507e54}
NoScript                 true  {73a6fe31-595d-460b-a920-fcc0f8843232}
Nuke Anything Enhanced      1.0.2         true  {1ced4832-f06e-413f-aa14-9eb63ad40ace}
pdfit                       1.15          true
PrefBar                     6.0.1         true  {8A6C82A1-F6C9-481a-AAE7-C96444C9A754}
printpdf                    0.76          true
Slovníky slovenského pravopisu 2.03.2     true
Web Developer                  1.1.9      true  {c45c406e-ab73-11d8-be73-000a95be3b12}
(In reply to aceman from comment #29)
> Giorgio, have you enabled the option from comment 18?

It is enabled by default.

As I said, looks like a multiple extensions conflict.
Could you try disabling all your extensions except NoScript, then readding them one by one?
Having only noscript enabled with that option enabled is enough to reproduce the problem (WinXP). Turning off that option fixes the problem. Should I attach my noscript configuration? Scripts are currently globally enabled.
Attached file config exported from noscript (obsolete) —
Attached file noscript prefs cut cut out of prefs.js (obsolete) —
Any http-on-modify-request observer which needs to read the upload stream (like NoScript and any HTTP monitoring extension) triggers this bug, which probably consists in the upload stream being left in an inconsistent state when it's read and rewound, but only if a 0-length file is present.

All you need to do to reproduce on a clean profile is running this script from a chrome privileged context (e.g. the Error Console) and using the testcase in attachment 558743 [details] immediately after (the observer gets removed on each upload).
Attachment #559424 - Attachment is obsolete: true
Attachment #559425 - Attachment is obsolete: true
Summary: unable to upload zero kb file → Unable to upload 0KB file if an observer reads the upload stream and rewinds it
i have tested by disabling 1 by 1 is working fine.
DownThemAll!       2.0.7  is extension causing issue for me.
Component: HTML: Form Submission → Networking: HTTP
QA Contact: form-submission → networking.http
Giorgio, thanks.  

Looks like the issue is that Seek() on a buffered stream doesn't pass the seek on to the underlying stream in cases when the seek is to a position that's already in the buffer.  Which means the "reopen on rewind" behavior doesn't kick in, the file stream remains closed, and things fail.

If the file stream is nonzero in size then mBufferStartOffset in the buffered stream ends up nonzero, 0-mBufferStartOffset ends up as a really big number, and hence > mFillPoint and we end up actually doing the seek.
Assignee: nobody → bzbarsky
Component: Networking: HTTP → Networking
Priority: -- → P2
QA Contact: networking.http → networking
Whiteboard: [need review]
Comment on attachment 567002 [details] [diff] [review]
Make sure that zero-size files wrapped in buffered streams are correctly reopened by a seek after EOF.

Review of attachment 567002 [details] [diff] [review]:

You should set mEOF = true also in nsBufferedInputStream::Read when mBufferDisabled == true.  I think for zero-size stream the condition offsetInBuffer <= mFillPoint will pass for disabled buffering.

r=honzab with the comment above

::: netwerk/test/unit/test_filestreams.js
@@ +251,5 @@
> +
> +  // OK, now seek back to start
> +, 0);
> +
> +  // Now check that available() does not throw throw

s/throw throw/throw/
Attachment #567002 - Flags: review?(honzab.moz) → review+
Attached patch Updated to comments (obsolete) — Splinter Review
Good catch on mBufferDisabled.  Added a test for that, which did fail with the original patch, but that needs nsIStreamBufferAccess to be scriptable, which I think is fine anyway.  Going to get sr from bsmedberg on that part.
Attachment #567144 - Flags: review?(honzab.moz)
Attachment #567002 - Attachment is obsolete: true
Comment on attachment 567144 [details] [diff] [review]
Updated to comments

Benajmin, could you just sr the one idl change?
Attachment #567144 - Flags: superreview?(benjamin)
Comment on attachment 567144 [details] [diff] [review]
Updated to comments

Does [notxpcom] in nsIStreamBufferAccess *imply* [noscript], or do you have to add it explicitly to those methods?
Attachment #567144 - Flags: superreview?(benjamin) → superreview+
I think it does at least for xpconnect, but I added it explicitly just to be sure.
Comment on attachment 567144 [details] [diff] [review]
Updated to comments

Review of attachment 567144 [details] [diff] [review]:

You may want to change all places to use bool/true/false consistently, PRBool -> bool is going to happen in few minutes from now.

And I forgot about one more place: not sure what the behavior should be when someone calls SetEOF on the stream.  It looks like some input streams implement that method too.  Maybe if call to the unbuffered stream's method succeeded set mEOF=true too?
Attachment #567464 - Flags: review?(honzab.moz)
Attachment #567144 - Attachment is obsolete: true
Attachment #567144 - Flags: review?(honzab.moz)
Comment on attachment 567464 [details] [diff] [review]
With those changes

Review of attachment 567464 [details] [diff] [review]:


Attachment #567464 - Flags: review?(honzab.moz) → review+
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla10
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.