Bug 147022 – Cached XHR requests are not shown in the web inspector

• Component: Web Inspector
• Status: NEW

[Sam Weinig]

Created attachment 256932 [details]
Test Case

As reported in http://www.raymondcamden.com/2015/07/16/safari-and-http-caching, cached XHRs are not shown in the web inspector. Test case attached.

[Radar WebKit Bug Importer]

<rdar://problem/21864126>

[Sam Weinig]

<rdar://problem/21859864>

[Joseph Pecoraro]

The Web Inspector frontend is only told about one requestWillBeSent from the backend (followed up by its responseReceived/dataReceived/loadingFinished updates):

    backend: {
        "method": "Network.requestWillBeSent",
        "params": {
            "requestId": "0.15",
            "frameId": "0.1",
            "loaderId": "0.5",
            "documentURL": "file:///Volumes/Data/Users/pecoraro/Desktop/cache-bug.html",
            "request": {
                "url": "http://api.randomuser.me/",
                "method": "GET",
                "headers": {
                    "Accept": "application/json, text/javascript, */*; q=0.01",
                    "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11) AppleWebKit/602.1.1 (KHTML, like Gecko) Version/9.0 Safari/601.1.41",
                    "Cache-Control": "max-age=0"
                }
            },
            "timestamp": 0.045744980983727146,
            "initiator": { ... }
            "type": "XHR"
        }
    }

So from the appearance of the frontend only 1 request was sent. That may in fact be what the engine is doing. The frontend should at least show that >1 XHR was initiated for the same URL, even if only 1 request was actually sent and they are sharing it. It would likely share a lot of timing information.

[Joseph Pecoraro]

In this test (as of today) Safari makes 2 requests. The first has a unique response, the second is shared by the remaining 9 XHRs. This behavior is equivalent to 10 <img src="..."> for the same URL. In that case, we also only see a single Resource in the Network Tab and Resources Tab.

In both cases, WebKit is making a network load, and while that load is in flight new requests are made for the same resource and we've determined that we can use the existing load's results.

Debugging with Antti we saw that we fall under this case in CachedResourceLoader::determineRevalidationPolicy:

>    if (existingResource->isLoading()) {
>        ...
>        // For cached subresources that are still loading we ignore the cache policy.
>        return Use;
>    }

The original article makes the point that:

> Looking at this, you can see Safari made one network request, which I
> suppose makes sense, but here is what ticks me off. Nowhere in this
> panel is any indication that it simply ignored my Ajax calls and used
> a cache result.

This is a fair point. We seem to be looking at two cases concerning the Memory Cache:

    1. A Request for a resource uses a response fully loaded response from our Memory Cache
      => Web Inspector shows this as a resource loaded from the Memory Cache

    2. A Request for a resource uses an ongoing request from our Memory Cache
      => Web Inspector is not informed about it

This is case (2). Possible solutions:

    Approach 1: Inform Web Inspector about Cache Hits for not yet loaded requests
      => We would see many XHR resources and Image resources for the above tests
      * We could show 10 network requests, with 1 a real load and 9 as memory cache.
      * We could do something like show the # of clients an individual response satisfied
        when it completed so we could show one load in the UI but also show that the load
        satisfied (10) clients. That begs the question of who the clients / initiators were.
   
    Approach 2: Do nothing, change XHR loading policy to match other browsers
      => Issue multiple XHR requests, which seems like what the developer expected anyways
      * Funnily enough this would match other browsers the most. Other browsers have the
        same behavior as Safari for the <img> case. They are just different in the XHR
        case because they send multiple requests.

    Approach 3: Special Cases
      => We could treat some subresource types as special to show ALL requests and others
      * This is essentially what other browsers have done at the engine level. Treating
        XHR loads different from Image loads, otherwise they would be seeing the same.

I don't yet have a strong opinion on whether we take approach 1 or 2. Either way it raises the point that if we want to show all of the initiators / requestors of a particular load, that if there are multiple initiators we might want to show them all.

[Joseph Pecoraro]

I should point out the <img> test I'm testing that shows other browsers have the same kind of behavior is just a page like:

    <img src="foo.png">
    <img src="foo.png">
    <img src="foo.png">
    ...

All browsers I've tested only show a single resource in their Network tabs for this.

[Sam Weinig]

(In reply to Joseph Pecoraro from comment #5)
> I should point out the <img> test I'm testing that shows other browsers have
> the same kind of behavior is just a page like:
> 
>     <img src="foo.png">
>     <img src="foo.png">
>     <img src="foo.png">
>     ...
> 
> All browsers I've tested only show a single resource in their Network tabs
> for this.

Oh how I hate to suggest a switch, but it might be nice to have someway to see all resource requests, even ones that hit the cache, for times when that information would be useful.