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
    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,
$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(
            $this->getMsgBlobMtime( $context->getLanguage() ),
            $this->getDefinitionMtime( $context )

this means that the getDefinitionMtime argument will always win in the max()

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

Look at the last part of the ISO datetime stamp toward the end of the URLs.

Change I7250d819628dfa9ee8c41941d843e9d7bd24bf3f
( 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

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

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

Reply via email to