114106 - multipart form submission should not need a temp file.

Status: VERIFIED FIXED

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

Description

[Darin Fisher]

multipart form submission should not need a temp file.  the fix for bug 15320
made sure this temp file does not outlast the browser, and the fix for bug 76463
made sure the temp files are created with the proper permissions.  however these
were really just bandaid fixes... the temp file should not be necessary.

not only is the temp file unnecessary, it is also costly to create when the file
to upload is large.

Comment 1

[Bradley Baetz (:bbaetz)]

Yeah, I was discussing a 'multiplexingInputStream' with sicking a couple of
months ago (IIRC). But it needs handle rewinding, and so on, although we could
only support rewinding to the beginning, I guess.

Such a stream would be made up of other streams (string and file, in this case),
and treat them as one stream. Either the multiplexing stream could handle a
separator, or the forms code could just insert the multipart boundary as an
extra entry.

Comment 2

[Darin Fisher]

right... this shouldn't be too hard to do... though i probably won't get around
to fixing this any time soon.

-> future

Comment 3

[John Keiser (jkeiser)]

The more I think about this, the more I think we need to bite the bullet and use
Necko to grab the file (and consequently get an nsIRequest).  This would solve
(or make easy to solve) three problems:

- bug 61855 (file type scanning--our existing file type scanner takes nsIRequest)
- bug 121059 (allow URLs in file input field)
- Necko becomes unusable while uploading large files because we are hogging the
event queue while we create that datastream.

Comment 4

[John Keiser (jkeiser)]

I hastily add that the nsIRequest solution is going to require some
restructuring of form submit itself into chunks, so the multiplexing input
stream is a good solution for a while :)

Comment 5

[Tom Mraz]

Nominating. If possible...

Comment 6

[John Keiser (jkeiser)]

It's highly likely, in fact.  sicking is working on that multiplexing input
stream, which will solve the problem.

Comment 7

[Darin Fisher]

yeah, best not to go down the road of trying to write out the temp file
asynchronously.  that just sounds like more pain to me than generating code for
a multiplexing input stream.

should someone else own this bug?

Comment 8

[John Keiser (jkeiser)]

Sure, I'll take it.

Comment 9

[Vladimir Ermakov]

Is there still temp files? If so where are they created, because I tried
uploading files on Linux and there was no temp file in /tmp directory...

Comment 10

[Boris Zbarsky [:bzbarsky]]

They get deleted immediately after creation on Linux so they're never visible in
the filesystem.

This is going to need code-level verification at this point.... :)

Comment 11

[John Keiser (jkeiser)]

Yes, bug 120682 does in fact solve this problem.  No temp files for you!

Comment 12

[John Keiser (jkeiser)]

Fix checked in.

Comment 13

[Vladimir Ermakov]

verifying per developer's coments... 

Comment 14

[Mudi Obada]

This bug is not fixed. I still get formpost files.
The file I'm looking at right now is from sourceforge
tracker which I think was submitted over SSL...
I just can't stand seeing FIXED in every related bug
and still haveing those silly files arround.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Mudi, which build are you using?

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Are you sure you're using build from after this bug was fixed? And that that 
file isn't an old one from before the bug was fixed? I would be very suprpriced 
if we still create the tempfile since all of that code should be removed 
(unless there's something in necko).

If you are sure you're using a nightly from after 2002-02-17 then please submit 
the exact steps to reproduce.

Comment 17

[Mudi Obada]

Sorry, I messed up. 0.9.8 was still being started when I launched moz from the
command line (didn't set my path to point to daily build) so that file was
probably not created by the build it thought.