1734924 - Page Info: General: field "Modified:" may show misleading date time information, more fields required

Status: NEW

(Firefox :: Page Info Window, defect)

Description

[A.D.F.]

In Page Info: General tab, window field "Modified:" is not handled properly and besides this it is not enough information, see also bug 1196500 and bug 1703342.

Here I'll try to summarize how that field (Modified:) should be managed and why a new window field (Retrieved: or Accessed:) would be very useful.

Window field "Modified:" should show the value of "Last-Modified:" HTTP header but if that header is not found in server response then it show date and time of the opening of Page Info window.

IMHO this is wrong because if you open ten times the Page Info Window you see that date and time is updated even if the web page has not been reloaded.

How to reproduce:

1. access a dynamic web page that has no "Last-Modified:" HTTP header in server response;
2. open a few times Page Info window and see that "Modified:" date and time value is updated everytime the window is opened even if web page has not changed.

All this is misleading and incomplete information so, as wished by many Firefox users, here it is a proposal to show separate information in different window fields.

As stated by RFC 7232, this "Last-Modified:" HTTP header should always be present in HTTP/1.1 and later versions, even if there is an "ETag:" header (unfortunately this directive is rarely followed by web servers and application programs).

"Last-Modified:" header exists since HTTP/1.0 so the following criteria could be adopted (just a few hints):

1. if a "Last-Modified:" HTTP header was found in server response for the web page then use that value in "Modified:" date time (just like it happens now);

2. if a "Last-Modified:" HTTP header was NOT found in server response then use a placeholder like Modified: "Unknown" (or something like that) as date time value; of course this value should be updated whenever a dynamic page that can grow when scrolled down is changed by making new HTTP request to server (OK, this might be tricky);

3. add a new window field named "Served:" using "Date:" HTTP header or "Unknown" if "Date:" header was not found (this should never happen but you may never know);

4. add a new window field named "Retrieved:" or "Accessed:" using local date and time of when the web page was retrieved (maybe the start time or the completion time of the network response of the web page or something like that); indeed if a web page changes soon after a server response started then this should not affect the content being retrieved so the local "start time" of the response could be a proper choice;

5. if the retrieval of the web page / web object was not completed (i.e. it was interrupted, etc.), Firefox could add this kind of string: "(interrupted / not completed)" after the date time value of "Retrieve:" field;

NOTE: maybe for the status information of the page / object retrieved, it would be better to add another window field named "Completion status:" with one of these values: "OK", "(interrupted)" (by user), "(not completed)" (interrupted by server or because of other causes).

Comment 1

[A.D.F.]

Of course if an object (web page, image, etc.) is read from a local file, "Modified:" field should show the modified date time value of the file just as it happens now, whereas the field "Retrieved:" should show the time when that page / object was read from local file.

Comment 2

[Timea Cernea [:tbabos][inactive]]

Hey A.D.F

I see that this issue was reported several times from the bugs you linked and from the discussion it also comes from a spec file that is not so convenient. One of the developers already tried to modify the spec file, please check out the discussion from https://www.w3.org/Bugs/Public/show_bug.cgi?id=27817 and the outcome was not positive.

So, I will set up this issue as a Defect, although it also contains improvement ideas and duplicate the older one since this one contains more information. If this remains as a Defect report or it will be further modified and considered as an enhancement is not up to me to call at the end, but thank you for taking the time to structure the issue arguments and proposed solutions.

Comment 4

[A.D.F.]

(In reply to Timea Cernea [:tbabos] from comment #2)

Hey A.D.F

I see that this issue was reported several times from the bugs you linked and from the discussion it also comes from a spec file that is not so convenient. One of the developers already tried to modify the spec file, please check out the discussion from https://www.w3.org/Bugs/Public/show_bug.cgi?id=27817 and the outcome was not positive.

So, I will set up this issue as a Defect, although it also contains improvement ideas and duplicate the older one since this one contains more information. If this remains as a Defect report or it will be further modified and considered as an enhancement is not up to me to call at the end, but thank you for taking the time to structure the issue arguments and proposed solutions.

OK, thank you for your explanations.

In the description of the bug (comment #c0) only the first part of point number 2. is valid, so I rewrite it below as it should be read:

2. if a "Last-Modified:" HTTP header was NOT found in server response then use a placeholder like Modified: "Unknown" (or something like that) as date time value (using a placeholder like "Unknown" would be coherent with those used in Media item list when object size is not known, etc.);

NOTE: Modified: date-time field should always refer to the modification time of the object downloaded from server or to the modification time of the file read from disk, not the time of when a dynamic html page changed its resulting html code (which is seen only internally by Firefox).

Showing above mentioned three fields (Modifed, Served, Retrieved) would give these advantages:

• Modified datetime, if present, should always be <= Served datetime, otherwise current datetime clock on server computer would not be right;
• Served datetime and Retrieved datetime may differ because Served datetime is the datetime of the computer where server is being executed, whereas Retrieved: datetime is the local datetime of when browser got server response; in theory, the difference between Served: datetime and Retrieved: datetime would give the difference to apply to Modified: datetime to have the last modification datetime of the object in local time (that of the PC of the browser);
• when the object is a file read from disk, Served and Retrieved could be the same value or Served field may not be shown;
• if three fields were considered too many, then showing only Modified datetime and Retrieved datetime would be sufficient.