147022 2015-07-16 15:17:55 -0700 Cached XHR requests are not shown in the web inspector 2026-01-12 09:08:46 -0800 1 1 1 Unclassified WebKit Web Inspector 528+ (Nightly build) Unspecified Unspecified NEW InRadar P2 Normal --- 1 sam webkit-unassigned andre graouts inspector-bugzilla-changes joepeck jonowells koivisto webkit-bug-importer oldest_to_newest 1109998 0 256932 sam 2015-07-16 15:17:55 -0700 Created attachment 256932 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. 1110000 1 webkit-bug-importer 2015-07-16 15:18:21 -0700 <rdar://problem/21864126> 1110001 2 sam 2015-07-16 15:18:27 -0700 <rdar://problem/21859864> 1110005 3 joepeck 2015-07-16 15:26:20 -0700 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. 1290708 4 joepeck 2017-03-23 19:39:07 -0700 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. 1290711 5 joepeck 2017-03-23 19:42:54 -0700 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. 1302421 6 sam 2017-04-27 17:38:51 -0700 (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. 256932 2015-07-16 15:17:55 -0700 2015-07-16 15:17:55 -0700 Test Case cache-bug.html text/html 618 sam PCFET0NUWVBFIGh0bWw+Cgo8aHRtbD4KPGhlYWQ+CiAgICA8c2NyaXB0IHNyYz0iaHR0cHM6Ly9h amF4Lmdvb2dsZWFwaXMuY29tL2FqYXgvbGlicy9qcXVlcnkvMS4xMS4zL2pxdWVyeS5taW4uanMi Pjwvc2NyaXB0PgogICAgPHNjcmlwdD4KICAgICAgICBmdW5jdGlvbiBkb1Rlc3QoKQogICAgICAg IHsKICAgICAgICAgICAgZm9yKHZhciBpPTA7aTwxMDtpKyspIHsKICAgICAgICAgICAgICAgICQu YWpheCh7CiAgICAgICAgICAgICAgICAgIHVybDogJ2h0dHA6Ly9hcGkucmFuZG9tdXNlci5tZS8n LAogICAgICAgICAgICAgICAgICBkYXRhVHlwZTogJ2pzb24nLAogICAgICAgICAgICAgICAgICBz dWNjZXNzOiBmdW5jdGlvbihkYXRhKXsKICAgICAgICAgICAgICAgICAgICBjb25zb2xlLmxvZyhK U09OLnN0cmluZ2lmeShkYXRhLnJlc3VsdHNbMF0udXNlci5uYW1lKSk7CiAgICAgICAgICAgICAg ICAgIH0KICAgICAgICAgICAgICAgIH0pOwoKICAgICAgICAgICAgfQogICAgICAgIH0KICAgICAg ICAKICAgICAgICB3aW5kb3cuYWRkRXZlbnRMaXN0ZW5lcignbG9hZCcsIGRvVGVzdCwgZmFsc2Up OwogICAgPC9zY3JpcHQ+CjwvaGVhZD4KPGJvZHk+Cgo8L2JvZHk+CjwvaHRtbD4K