Channel may not have local and remote addresses accessible during nsISocketTransport::STATUS_WAITING_FOR
Categories
(Core :: Networking: HTTP, defect, P5)
Tracking
()
People
(Reporter: mayhemer, Unassigned)
References
Details
(Whiteboard: [necko-would-take])
- first, we post an event to distributor observers from the network thread (in nsHttpTransaction::OnTransportStatus) - second, we post an event to the channel (again, in nsHttpTransaction::OnTransportStatus) - if we reuse a connection for that channel, there is no STATUS_CONNECTED_TO sent to the channel - therefor the channel grabs addresses from the transport in STATUS_WAITING_FOR event first - this event is delivered to distributor observers sooner then to the channel -> when observers call on the channel it doesn't have the address yet I propose to reverse order of posts to distributor and to the channel (transport sink) from nsHttpTransaction::OnTransportStatus.
Reporter | ||
Comment 1•12 years ago
|
||
Fixed as part of bug 648878.
Comment 2•12 years ago
|
||
Honza, are you sure this is a dupe of 648878? That bug was 1) fixed 3 months before you reported this, and 2) seems to be not something that would fix your issue here (it's a local/remote address bug, but only for e10s, and this sounds like a main process issue). On the plus side, you've made me realize that we never closed up the followup to bug 648878--bug 664163. Thanks! :)
Reporter | ||
Comment 3•12 years ago
|
||
You are right, thanks. I forgot the details of this bug. The problem is elsewhere.
Reporter | ||
Updated•12 years ago
|
Updated•8 years ago
|
Comment 4•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Comment 5•3 years ago
|
||
I believe I may be encountering this issue in the WebExtensions API when utilizing browser.webRequest.onResponseStarted.addListener()
.
Not yet sure about a shorter way to reproduce, but here's how I've been consistently seeing an issue so far:
- open about:debugging, load an addon which registers
onResponseStarted
listener to simply log the received parameters - open a second tab and load any website. For instance, https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/extensions/ext-toolkit.json -- in the logs you'll be able see the IP address in the
ip
field (as expected) - close the browser and reopen it so that it restores the previous browsing session and shows you about:debugging as an active tab
- load the same addon again (since temporary addons are removed at the end of session)
- ...
Now go to the second tab, this will trigger its loading. After this in the addon logs you'll consistently see ip
field represented as null
.
I was suspecting that it might be the case if the response was coming from cache, but I've noticed fromCache
is usually set to false
when ip === null
in this case.
This behaviour is inconsistent with the Chromium implementation at the moment where it always returns the IP address to chrome.webRequest.onResponseStarted
and other webRequest
listeners.
If my hunch is right and this issue is the root cause this bug may need a higher priority.
Updated•2 years ago
|
Description
•