lighthouse
lighthouse copied to clipboard
GoogleChrome
Support Network requestWillBeSentExtraInfo and responseReceivedExtraInfo events
Network.requestWillBeSentExtraInfo
Network.responseReceivedExtraInfo
Added in July. From the change (https://chromium-review.googlesource.com/c/chromium/src/+/1592771), looks like it was to include updated information about blocked cookies and for better dealing with request information coming from outside of the renderer process. See also e.g. previous issues like https://github.com/GoogleChrome/puppeteer/issues/487#issuecomment-324237551
One real example already is my confusion in https://github.com/GoogleChrome/lighthouse/pull/9731#issuecomment-535163364 :)
Biggest pain adapting our current setup will be the event ordering, since "there is no guarantee whether requestWillBeSent or requestWillBeSentExtraInfo will be fired first for the same request" (and same for responseReceivedExtraInfo)
Biggest pain adapting our current setup will be the event ordering
and I guess how to resolve conflicting information. e.g. DevTools still shows a 200 status for me in https://github.com/GoogleChrome/lighthouse/pull/9731#issuecomment-535163364 even though the Network.responseReceivedExtraInfo brings in a later 304 status (so extra info might not always be intended to win?). @josepharhar might be able to help.
Ah yes I was wondering if lighthouse would be interested in the new events!
Reconciling the different events is complicated due to redirects and due to the fact that you can't know for sure if you will get ExtraInfo events because you don't know if a request will actually make it to the network stack, hence the exposure of that issue in the protocol events :( I would recommend looking at my frontend patch for the events to see how to deal with redirects properly: https://chromium-review.googlesource.com/c/chromium/src/+/1639277
As for the status, the DevTools frontend only looks at the status number in Network.responseReceived to populate status code information. I suppose the status should be present in the first line of headersText in responseReceivedExtraInfo. I never knew there was an issue where the renderer (or InspectorNetworkAgent) thinks that the response code was different than what was actually received over the wire. If that's the case, it should definitely be a crbug.
this is certainly more correct. unclear what issues this incorrectness currently pose
at some point a redirectHasExtraInfo property was added to Network.requestWillBeSent and hasExtraInfo was added to Network.responseReceived, which seem like they could be very helpful to making handling of these easier.