Trying to upload the contents of a local file using <form enctype="multipart/form-data"> and <input type=file> only works if the file is of record format streamLF. A good example of this is when you attach a file to a bug in Bugzilla. This problem is in all releases up to and including M18 and M0.6.

Well, the reason its not working right is because in nsFormFrame::ProcessAsMultipart where we calculate the overall size, we use GetFileSize to obtain the size of the file we want to send. There are certain file formats on VMS where stat() doesn't (and can't) return the correct file length, and under these circumstances, GetFileSize returns an error. Now, ProcessAsMultipart just silently ignores this error and continues with the incorrect content length. So, I've discovered this problem on VMS, but I'm not convinced that other platforms can't also be bitten by this. In fact, and time GetFileSize returns an error we'll see this problem. So when can GetFileSize return an error on UNIX platforms? What about if the user specifies the console as the file to transfer? Doug, I'm looking for some guidance here. Is this a VMS specific problem, or can other platforms sometimes not return a correct/meaningful number on a stat call?

Hmm. I can stat("/dev/tty") on Linux. It returns with 0 (success) and st_size is zero. I can also specify /dev/tty in a <type input=file> and have it transfer whatever I type in on the console (up to ^D). Only in this case the transmitted content length is wrong. So I guess this isn't a VMS-specific problem. What's the right thing to do when the file content length isn't known? Can we just not send the content length under these circumstances? Is that a valid thing to do?

Doug, looking for some input here. Please re-assign back to me once you've given me some direction! Thanks, Colin.

HTTP 1.0 says that we must include a valid content length. So I guess we need to read the file first BEFORE sending the header. Its the only way we can get the correct size of something like "/dev/tty" or a pipe (and its the only way that certain file formats on OpenVMS can be sized). Doug, you agree with this?

what do we do when stat() doesn't return the correct file length? Can we determine these condition prior to calling stat? Trying to post a file, but we do not know the content length of this file? can we just lie about the length?? any ideas from the folks I just cc'ed?

If you're going to send Content-Length, it had better be correct! And it seems we must send that header, for Keep-Connection and other good reasons I suspect. I don't know what can be done for GetFileSize on OpenVMS, but I agree that there is a general, cross-OS problem: some special files do not report a useful size via stat- or getattr-type operations. We can special case these file types at stat time (on Unix, they're not regular files). Through a distinguished failure code (or a better way to signal the GetFileSize caller), we can leave it up to the file upload code to read the whole damn "file" (special device, whatever), compute the content-length, and then send. This will require a tmp file, it seems to me. Does this sound right? /be

This sounds good. Whatever mechanism you use to signify that the size is unknown on Unix, I'll use the same on OpenVMS when I get one of these file formats where stat doesn't/can't give the correct length. In fact, we already have a mechanism, and I already have a hook into it. http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileUnix.cpp#931 GetFileSize returns an error if it can't determine the file size. Then all we need to do is ensure that all callers of GetFileSize check the return and do something sensible if they get an error. In this particular case I think the correct thing to do is to copy to a temporary file. Ugly and slow, but what choice do we have? We have to report the content length, and we have to report is correctly.

Anyone have any thoughts on this? I don't mind doing the work (for <input type=file> if its the right thing to do.

I think it's the right thing. Thanks for stepping up; feel free to hash out any code issues in the newsgroups (m.layout? hmm, maybe m.xpcom!). /be

According to (the rather old) bug 22317, all this code is going to be rewritten anyway, so I guess its not worth my time trying to fix it. Note to whoever does the rewrite: please make sure that the new code will work even if the stat returns 0 (0 doesn't always mean no bytes to read!). Should this be marked WONTFIX, or should be leave it open until after the rewrite and then verify that its fixed? I think the latter is better.

Its not 22317, its 15320. Sorry about that.

reassigning to pollmann@netscape.com.

Bulk reassigning form bugs to Alex

Bug 15320 is resolved, but this problem isn't. We still don't handle the case where we can't get the file size (via stat) of a file to upload. Removing the depend.

Yuck. So file streams need not be seekable, right? This is a problem, since the post data stream _must_ be seekable for proper functioning (we need to rewind it for repost and other such things). Our current method of creating a temp file with all the data allows this to happen, but we're trying to eliminate the temp file and just do some sort of multipart stream.... It looks like we'll need to special-case temp files for the sort of files this bug is about even if we don't use them in general....

bz: xpcom and necko file stream impls all support nsISeekableStream

*** Bug 205175 has been marked as a duplicate of this bug. ***

Is DEC/OpenVMS still a supported platform on trunk?

Nope.

Uh... Since when are we wontfixing bugs just because something is not tier1? Or is this completely unsupported (like we don't compile on it)?

vax is completely unsupported. I'm assuming the linux /dev/tty case is not enough to keep this open?

Or the linux named pipe case, for that matter.... Probably not, no.