1466099 - Update details for DNS resolution of webrequest.onBeforeRequest or other events in Webrequest

Status: RESOLVED WORKSFORME

(Developer Documentation Graveyard :: Add-ons, defect, P3)

Description

[gokulakrishnaks]

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

Comment 1

[Timea Cernea [:tbabos][inactive]]

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.

Comment 2

[Will Bamberg [:wbamberg]]

Shane, could you answer this question so this person can update the docs? Thanks!

Comment 3

[Shane Caraveo (:mixedpuppy)]

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.

Comment 4

[Kris Maglione [:kmag]]

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.

Comment 5

[Shane Caraveo (:mixedpuppy)]

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.

Comment 6

[Kris Maglione [:kmag]]

See the various variants of Services.io.speculativeConnect, and the network predictor.

Comment 7

[Will Bamberg [:wbamberg]]

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)

Comment 8

[Kris Maglione [:kmag]]

We should probably at least document the fact that speculation may cause requests to be initiated before any webRequest listeners are notified.

Comment 9

[gokulakrishnaks]

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)

Comment 10

[gokulakrishnaks]

Added this under Compatibility table here:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onBeforeRequest