Closed Bug 1466099 Opened 5 years ago Closed 5 years ago
Update details for DNS resolution of webrequest
.on Before Request or other events in Webrequest
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36 Steps to reproduce: These pages do not explain whether DNS resolution happens before or after webrequest.onBeforeRequest when blockingResponse is used. If someone confirms that DNS resolution happens before or after onBeforeRequest blockingResponse, please let me know so I can update the documentation below. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/onBeforeRequest
Hey gokulakrishnaks, I understand that you need some information regarding request handling. I will set the component to involve the development team in providing the needed details.
Component: Untriaged → WebExtensions: Request Handling
Product: Firefox → Toolkit
Component: WebExtensions: Request Handling → Add-ons
Product: Toolkit → Developer Documentation
Version: 59 Branch → unspecified
Shane, could you answer this question so this person can update the docs? Thanks!
I'm not super familiar with all the DNS code paths, but looking at nsHttpChannel.cpp: When DNS fetch occurs depends on a number of things, so I cant say that it will 100% behave the same in all situations. However, a DNS pre-fetch is generally initiated right after onBeforeRequest is called (assuming a blocking listener the listener would execute before DNS prefetch). That does not happen, for example, if an http proxy is being used. I'm also not sure what happens with DNS over HTTPS, but likely it is handled within the various dns classes in which case it should be the same timing.
That's only sort of true. For pure HTTP requests, I think this is accurate. But for many requests, we speculatively connect before we actually create an HTTP channel, and that requires doing DNS resolution much earlier.
Yeah, per my superfluous caveats, I knew there were probably other paths. Forgot about speculative connections. However, onBeforeRequest does happen prior to speculative connect (the one in http channel). It used to not, or at least used to probably not, but that was because channel.suspend was not respected. I specifically added the http-on-before-connect notification prior to speculative connect. If there is some other speculative connect path otherwise, I haven't looked at it.
See the various variants of Services.io.speculativeConnect, and the network predictor.
Thanks both. From your comments it sounds like this ordering is a thing that an extension developer ought not to rely on, and we therefore should not document it as such? (including cross-browser, and from one browser version to another, let alone one request to another)
We should probably at least document the fact that speculation may cause requests to be initiated before any webRequest listeners are notified.
Thank you, @Shane, @Christ and @Will. I will update the documentation with this: Regarding DNS resolution when BlockingResponse is used with OnBeforeRequest: In HTTP Channel, onBeforeRequest with blocking response does happen prior to DNS resolution and also prior to speculative connect. For other channels, speculative connect may cause DNS requests to happen before onBeforeRequest. This ordering is not something an extension developer ought to rely on as it may vary across browsers, and from one browser version to another, let alone one request channel to another)
Added this under Compatibility table here: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onBeforeRequest
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.