Last modified: 2014-08-27 13:45:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 34779 - add timestamp near cache key (JS/CSS minify)
add timestamp near cache key (JS/CSS minify)
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.19
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-28 21:03 UTC by db [inactive,noenotif]
Modified: 2014-08-27 13:45 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description db [inactive,noenotif] 2012-02-28 21:03:54 UTC
It is helpful for debugging, when near to the cache key of a minified CSS/JS the timestamp of the minifikation is printed (like information by parser cache <!--Saved in parser cache with key ? and timestamp ? generated by ?-->. Thanks.
Comment 1 Krinkle 2012-12-03 16:26:17 UTC
* The timestamp of when a module was last modified is available as real data in the startup module.
* For HTTP requests this timestamp is passed in the query string.
* For HTTP responses the known timestamp is in the 304/Last-Modified header.

Adding it to the content as well would increase the payload O*N for each section for each module in a bundled ResourceLoader request. Not sure if that's worth the payload.

What do you need it for exactly? Can you use one of the above 3 pieces of information instead?
Comment 2 db [inactive,noenotif] 2012-12-06 20:31:26 UTC
(In reply to comment #1)
> * The timestamp of when a module was last modified is available as real data
> in the startup module.

In practical that must not the same timestamp, when it was saved in the cache

> * For HTTP requests this timestamp is passed in the query string.
> * For HTTP responses the known timestamp is in the 304/Last-Modified header.

Not all people have FireBug to see header information. When looking at the html source of a page or download the script itself/through the debugger, it is easy there to look at.

When this gets expensive, than it is bad and need some refactoring or so. But feel free to close as WONTFIX
Comment 3 Krinkle 2012-12-06 22:11:53 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > * The timestamp of when a module was last modified is available as real data
> > in the startup module.
> 
> In practical that must not the same timestamp, when it was saved in the cache
> 
> > * For HTTP requests this timestamp is passed in the query string.
> > * For HTTP responses the known timestamp is in the 304/Last-Modified header.
> 
> Not all people have FireBug to see header information. When looking at the
> html
> source of a page or download the script itself/through the debugger, it is
> easy
> there to look at.
> 
> When this gets expensive, than it is bad and need some refactoring or so. But
> feel free to close as WONTFIX


The first point (data in the startup module) is accessible from the console (mw.loader.getVersion).

It is also accessible in more places I haven't mentioned above (such as the HTML source of the active DOM state, the timestamps are in the URLs, in the <script> tags).

Sure someone who looks at the raw source will not see these, but I think this data isn't relevant for that audience. I see no point in putting timestamps in the html output there for each module.

Feel free to re-open with a use case, but afaik the data is easily available to any developer in many different places.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links