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.
Version: 1.23.0
Severity: normal