Provide a facility to send Last-Modified time when you upload a file.




10 years ago
4 months ago


(Reporter: BijuMailList, Unassigned)


({helpwanted, student-project})


Firefox Tracking Flags

(Not tracked)


Thanks for bug 178506 fix, 
now we can maintain the last modified time when we download and save a file.
But, still we dont have a facility to do the same when we upload a file.

If possible, please provide a "Last-Modified" header when user upload a file so that at sever we can use it to set the modified time of the uploaded file.

Sure, the server programing language or modules need to be enhanced to achieve that.

We should also provide an about:config item to enable/disable this feature as some have concerns. see bug 390776 Comment 6, a bug to provide ability in JavaScript to get the files last modified time among other things.
Severity: normal → enhancement
This has nothing to do with file handling.  Is this bug about form submission, ftp upload, or something else?
(In reply to comment #1)
> Is this bug about form submission
Yes. I changed component, if it is still not right pl. change to the right one.

> ftp upload
Can we upload file to ftp site with firefox?
Component: File Handling → Layout: Form Controls
QA Contact: file-handling → layout.form-controls
> Can we upload file to ftp site with firefox?

There's backend code for it, yes.  I have no idea whether it's exposed in the UI.

For form submission, sending this by default is a non-option, I suspect; it would break too many sites due to their use of broken MIME parsers.  If it's going to be off by default, is it worth doing?
Component: Layout: Form Controls → HTML: Form Submission
QA Contact: layout.form-controls → form-submission
If at least we can get it with default as off, I will be able to submit enhancement request to org.apache.commons.fileupload java classes. 
And same for PHP and .Net

Other wise it will be a chicken and egg problem.
It's not clear to me that this is a chicken we actually want to hatch, of course....

Under what conditions do you see it ever being enabled by default on our end and usable on the server end?  And over what timeframe?  And why is it desirable to do this at all?
(In reply to comment #3)
> it would break too many sites due to their use of broken MIME parsers.

Maybe it is possible to introduce a new attribute to the filechooser like the "multiple" attribute for uploading multiple files at once. This way it would not break anything and we do not need any client-side options.
That could be done, yes.  I'd be in favor of that, especially if the privacy implications are sorted out.
I like this idea.
I don't care about Firefox, but FTP capabilities were restored in SeaMonkey. When you load an FTP site such as you will see a "Upload File..." under the File menu, and you can change the default login by changing the URL like

There is a method for setting the header in nsIHttpChannel which is setRequestHeader() [I assume, I haven't done any XPCOM].

In JavaScript you can use XMLHttpRequest and set a header with setRequestHeader(), which I have done. Many browsers support this in different ways.

I have no idea how the browser would get the file's modified date - bug 390776 I assume. It should be no problem getting HTTP headers at the server. See: I don't know about FTP servers, but you can take a look at for example.
If you're worried about privacy, why are you uploading files?

Seriously, under what possible circumstance is mtime a privacy issue? Beyond accessing the site in the first place and uploading a file, and logging the time you uploaded it?

It boggles my mind. If you're some kind of CIA spy, or a freedom fighter in an oppressive regime, then yes maybe you should consider touching all your files to Jan 1 1970 before transferring them anywhere. What about the rest of us?

Personally, I have files on floppy disks dating back to the 80's, where the mtime is the only documentation that exists as to when exactly something was written. I wasn't exactly thinking of the future when I was, say, six years old writing my first BASIC programs and writing school assignments in Appleworks. But now I'm glad those mtimes are there.

But now we're in an environment where the leading interfaces to our *entire lives*, can't be bothered to preserve this information. Information is being LOST forever.
Providing any information about the user that the user did not explicitly opt in to providing is a privacy issue.

It'd be different if we knew we can trust the website, but we can't.  It'd also be different if we knew a lot more about the user (e.g. knew that they aren't a freedom fighter in an oppressive regime), but we don't.

An interesting question is whether more users care about mtime than are freedom fighters in oppressive regimes....
Uploading a file is opting in to providing that file, don't you think? Who DOESN'T consider the mtime as a intrinsic element of any given file?

Consider the perverse situation of a whole generation has grown up with web browsers carelessly discarding mtimes. You're going to be guided by these people's expectations? That's circular logic.

Also consider how people blindly upload jpeg photos all over the net, absolutely FULL of info in their EXIF tags. And we're worried about mtimes?

Also consider the nature of the web nowdays. People are posting every little bit of information about themselves all over Facebook, all day long. We're in a time of services such as Google Latitude, where people's smartphones broadcast their EXACT location to all their friends and family, in real time, and thus implicitly to Google as well.

Privacy is dead. The vast majority of social users don't care. (Maybe they should, but they don't) They're too busy reaping the benefits of an open book. They have safety in numbers.

And we're worried about mtimes?

You know, there's a reason browsers have private/incognito modes. Presumably, our hypothetical freedom fighter would be running in private mode when uploading to an "untrusted" site. (Why would they even go anywhere near an "untrusted" site?) Hide mtimes in private mode, otherwise don't. Pretty obvious solution to me.
> Uploading a file is opting in to providing that file

The file's _data_.

Note that we don't even send the file's _name_ to the server, which is much more of an intrinsic element of a file to most people than the mtime.
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.