https://bugzilla.wikimedia.org/show_bug.cgi?id=59623
Web browser: ---
Bug ID: 59623
Summary: ResourceLoader Timestamp Always Returns Current Time
Product: MediaWiki
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: ResourceLoader
Assignee: wikibugs-l@lists.wikimedia.org
Reporter: ab...@wikimedia.org
CC: krinklem...@gmail.com, roan.katt...@gmail.com,
tpars...@wikimedia.org
Classification: Unclassified
Mobile Platform: ---
ResourceLoaderModule.php's getDefinitionMtime function contains the following:
$data = $cache->get( $key );
if ( is_int( $data ) && $data > 0 ) {
// We've seen this hash before, re-use the timestamp of when we
first saw it.
wfProfileOut( __METHOD__ );
return $data;
}
When the $key's value is, for example,
wiki:resourceloader:moduledefinition:jquery.client:b86c8a395c01a1a635e65f1f03de1194,the
$cache->get( $key ) call returns a string of digits (not an integer primitive).
Thus, $data is never returned. Instead, the function returns a timestamp that's
guaranteed to be late in the future (the current time, as per time()).
$timestamp = time();
$cache->set( $key, $timestamp );
wfProfileOut( __METHOD__ );
return $timestamp;
When ResourceLoaderFileModule.php's getModifiedTime ( ResourceLoaderContext
$context ) relies upon ResourceLoaderModule.php's timestamp comparison
$this->modifiedTime[$context->getHash()] = max(
$filesMtime,
$this->getMsgBlobMtime( $context->getLanguage() ),
$this->getDefinitionMtime( $context )
);
this means that the getDefinitionMtime argument will always win in the max()
determination.
In production, the (far) future dated cache settings on the ResourceLoader
responses mean that in general there shouldn't be lots of unnecessary origin
hits. So even though the current timestamp will version the URL at that very
instant, it doesn't seem to matter too much from what I can tell.
That said, I'm mostly interested in the context of the main startup scripts.
While trying to generate an accurate AppCache that only fluctuates URLs and
datetime stamps when needed, I observed the following behavior.
* Without any filesystem touches, two UAs around the same time get different
URLs:
-http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20131226T231310Z
-http://127.0.0.1:8080/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20131226T231402Z
Look at the last part of the ISO datetime stamp toward the end of the URLs.
Change I7250d819628dfa9ee8c41941d843e9d7bd24bf3f
(https://gerrit.wikimedia.org/r/103407) has been submitted to try to work
around the case where the returned value is int-like. It may make more sense to
look into RedisBagOStuff.php's unserialize ( $data ) function if this behavior
is generally problematic, but I'm not clear on the other non-RL contexts where
messing with RedisBagOStuff.php could have unintended consequences. It seems
that adjusting things in ResourceLoader makes sense in this case, but I'm not
sure.
This currently blocks a dependent change for getting the startup URL for
supporting an HTML5 AppCache concept, which in turn is necessary for offline
back/forward functionality, useful especially on places with connectivity
issues.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
