[Webkit-unassigned] [Bug 94490] New: Web Inspector: After overriding user-agent via dev-tools, some resources still communicate using the default one

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=94490

           Summary: Web Inspector: After overriding user-agent via
                    dev-tools, some resources still communicate using the
                    default one
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Web Inspector
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: myok12 at yahoo.com
                CC: timothy at apple.com, rik at webkit.org, keishi at webkit.org,
                    pmuellr at yahoo.com, joepeck at webkit.org,
                    pfeldman at chromium.org, yurys at chromium.org,
                    bweinstein at apple.com, apavlov at chromium.org,
                    loislo at chromium.org


Created an attachment (id=159456)
 --> (https://bugs.webkit.org/attachment.cgi?id=159456&action=review)
An example of the bug, using node and npm

When overriding the default user-agent via developer tools, all resources being requested from the HTML page are using the specified user-agent.
However, if the page uses the offline web application feature (aka cache.manifest - http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html), then cache updates, which are triggered automatically with every launch of the page, use the default user-agent, both for retrieving the cache.manifest file and the other resources (HTML, CSS, JS, Fonts, etc.). Also, the favicon.ico is being fetched using the default user-agent.
This is important to fix for when debugging mobile sites: you change your user-agent to get to a mobile site, but then the cache.manifest check and all related resources are using the desktop user-agent for fetching updates, which might get a different result (302 rather than 200, or simply a desktop site's resource as oppose to a mobile site's one). This might cause a cache update for a cached app to fail in scenarios where 302 is returned or when different resources exist for the desktop site.
When overriding the user-agent, all resources should use it.

A work around for upgrading a cached app is to simply clear the cache, although this inhibit from debugging the upgrade sequence.

The attachment is a node project designed to help troubleshoot this issue. You'll need to have node and npm installed. Then, run "npm start" to kick-off the server on port 8088. Then browse to either http://localhost:8088/cache.html to get a cache.manifest driven HTML file or http://localhost:8088/no_cache.html to get a normal page. For each hit, the server spits out the user-agent used in the request. You can try hitting both URLs with and without DevTools' user-agent override and see the behavior. If you want to "push an update" to the cached app, run "./update_files.sh".

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.