W3C home > Mailing lists > Public > www-tag@w3.org > November 2011

Re: Web browsers should preserve the file system Last-Modified time of downloaded files

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 13:52:18 +0900
Message-ID: <4EBB5882.80403@it.aoyama.ac.jp>
To: Noah Mendelsohn <nrm@arcanedomain.com>
CC: Larry Masinter <masinter@adobe.com>, Scott Penrose <scottp@dd.com.au>, Karl Dubost <karld@opera.com>, Brolin Empey <brolin@brolin.be>, "www-tag@w3.org List" <www-tag@w3.org>
I very much agree with Noah's last statement: "user agents are free to 
compete on the quality of their file download implementations."

For the case of pictures (mentioned in the first bullet point), I'd like 
to point out that pictures contain a 'created' date/time internally, and 
modern cameras set it correctly (assuming they have their clocks set 
correctly), so somebody downloading the picture should be able to get at 
the time it was created without even having to bother about the Web or 
http or whatever.

Regards,   Martin.

On 2011/11/10 7:35, Noah Mendelsohn wrote:
> Well, my reasons for not wanting to deal with this in the TAG are a bit
> different. Specifically:
>
> * I think that some of the use cases are not affected by time skew. Very
> often, files bounce through the Internet, and people just want to see
> the modified time they started with. Think things like .dll's, photos,
> etc. I don't really care whether the server clock is in sync with
> anyone. If I upload a photo, and you download it, I generally want you
> to get all the timestamps it had when I first put it up. The maintenance
> of creation vs. modification times is a little unclear to me in these
> scenarios, but with the possible exception of warning if a modified time
> winds up "in the future", I can see at least some reasons for just
> preserving it as the file moves through the network. So, I think this
> request has some merit.
>
> * With apologies for the fact that Tim suggested bringing this to the
> TAG, I'm unconvinced it's a TAG-level issue. It seems to me that it's a
> question of how user agents deal with one of the details of implementing
> local file save features, and that seems like something to be settled in
> whatever working group is responsible for the user agent feature (I'm
> guessing HTML WG in practice these days). If there is no such WG, and no
> mandated behavior in RFC 2616 or related header specifications (I
> haven't checked), then I would think user agents are free to compete on
> the quality of their file download implementations.
>
> Noah
>
> On 11/9/2011 4:03 PM, Larry Masinter wrote:
>> I think the time skew is the determining factor for me...
>>
>> When two systems are on the internet communicating, they *might* be in
>> sync but often are not. Maybe their clocks are only seconds apart.
>> Maybe the latency between the two systems is small, but I think it is
>> actually unusual for two systems to be in perfect sync. Whether or not
>> it is unusual, it *does* happen.
>>
>> Then, the "last-modified" time on the server is server-relative. The
>> client writes a file in its local file system, you might even get a
>> file with "last modified" in the future.
>>
>>
>>
>> -----Original Message-----
>> From: Scott Penrose [mailto:scottp@dd.com.au]
>> Sent: Tuesday, November 08, 2011 7:00 PM
>> To: Karl Dubost
>> Cc: Brolin Empey; www-tag@w3.org List
>> Subject: Re: Web browsers should preserve the file system
>> Last-Modified time of downloaded files
>>
>>>
>>> Le 4 nov. 2011 à 19:18, Brolin Empey a écrit :
>>>> The Web browser should preserve the file system last modified time
>>>> by default because this time cannot easily be recovered after it is
>>>> discarded.
>>
>> I have been thinking about this over the last week and which way it
>> should happen.
>> It is interesting to note that many older backup systems use last
>> modified as a method to work out if files need incremental backup.
>>
>> The problem is that once you download a file, they are not linked. The
>> file on your system does not match the remote system. So what does
>> modified mean?
>>
>> Lets put 3 systems into play.
>>
>> * Server1 - file.png, last modified 2010-01-01
>> * Server 2 - file.png downloaded, last modified 2010-01-01
>> * Client 1 - Download file from Server 2, use if mod since
>>
>> Scenario 1 - Server 2 modifies the PNG (maybe a resize). Last modified
>> should change to that day (2011-10-01), Client can download.
>>
>> Scenario 2 - Server 1 had updated the logo in 2011-06-01; now Server 2
>> downloads from Server 1, preserving date modified as 2011-06-01;
>> Client now checks if file has changed since last of 2011-10-01 - it
>> has changed, but now client won't get it. On the other hand, if Server
>> 2 had set last modified to today 2011-11-09 - it would not be an issue.
>>
>> Scenario 3 - A client downloads a file to Download folder, has a look
>> at recent files. User would expect to see newest files downloaded with
>> todays date.
>>
>> I don't think HTTP Clients should preserve modified date time. But
>> there are exceptions - e.g. WebDAV / SVN over HTTP.
>>
>> Scott
>>
>>
>>
>>
>
>
Received on Thursday, 10 November 2011 04:53:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:40 GMT