Closed Bug 1542170 Opened 1 year ago Closed 1 year ago

Map HTTP upgrade request to WS connection/frames

Categories

(Core :: Networking: WebSockets, enhancement, P2)

67 Branch
enhancement

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox68 --- fixed

People

(Reporter: tanhengyeow, Assigned: baku)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36

Steps to reproduce:

When a new HTTP request is created, it is assigned a channel with a channelId as seen here.

Description of the spec can be seen here.

As an initiative to support Bug 885508, the plan is to show WS frames for upgraded HTTP requests in Netmonitor. As such, we might want to have platform support available to map upgraded HTTP requests with the WS frames under the same channel.

One possible approach is to accept another parameter (possibly the channelId of the upgraded HTTP request) in functions of the interface nsIWebSocketEventListener e.g. webSocketCreated.

Through this way, DevTools would be able to correlate the upgraded HTTP request with its associated WS frames and show them accordingly.

:baku, this bug report is related to my question I sent on Slack.

Honza

Flags: needinfo?(amarchesini)
Status: UNCONFIRMED → NEW
Type: defect → enhancement
Ever confirmed: true
Priority: -- → P2

From comment #0

One possible approach is to accept another parameter (possibly the channelId of the upgraded HTTP request) in functions of the interface nsIWebSocketEventListener e.g. webSocketCreated.

This looks promising.

I was quickly looking at the code base and found this place:
https://searchfox.org/mozilla-central/rev/dd7e27f4a805e4115d0dbee70e1220b23b23c567/dom/websocket/WebSocket.cpp#1395

// Let's inform devtools about this new active WebSocket.
webSocket->mImpl->mService->WebSocketCreated(
    webSocket->mImpl->mChannel->Serial(), webSocket->mImpl->mInnerWindowID,
    webSocket->mURI, webSocket->mImpl->mRequestedProtocolList);

It looks like we could use mHttpChannel from webSocket->mImpl.

mHttpChannel is defined here:
https://searchfox.org/mozilla-central/rev/dd7e27f4a805e4115d0dbee70e1220b23b23c567/netwerk/protocol/websocket/WebSocketChannel.h#199

So, something like as follows:

// Let's inform devtools about this new active WebSocket.
webSocket->mImpl->mService->WebSocketCreated(
    webSocket->mImpl->mChannel->Serial(), webSocket->mImpl->mInnerWindowID,
    webSocket->mURI, webSocket->mImpl->mRequestedProtocolList,
    webSocket->mImpl->mHttpChannel->channelId);

Does that make sense?

Honza

Yes, this is correct. Honza, do you know who can work on this? I don't have time to work on this at the moment.
How urgent is it?

Flags: needinfo?(amarchesini) → needinfo?(odvarko)

This is needed for GSoC 2019 project, so it should ideally land in 69 Nightly around May 6
(the merge date is May 13, so could be one week later for 69)

Would that be enough time for you?

Honza

Flags: needinfo?(odvarko) → needinfo?(amarchesini)

Changing the target component.

Honza

Component: Netmonitor → Networking: WebSockets
Product: DevTools → Core
Assignee: nobody → amarchesini
Flags: needinfo?(amarchesini)
Whiteboard: [necko-triaged]
Duplicate of this bug: WSFrameInspection
Pushed by amarchesini@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/24a453261a2e
Introduce nsIWebSocketChannel.httpChannelId, r=valentin
https://hg.mozilla.org/integration/autoland/rev/87fbdfa81895
Expose http channel Id to WebSocketEvent listeners, r=valentin
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.