fix(network): make main-document POST bodies available to getRequestPostData - #230
fix(network): make main-document POST bodies available to getRequestPostData#230BibekPathak wants to merge 1 commit into
Conversation
|
@ldm0 please have look at this!! |
| ) -> MainDocumentBodyProgressSource { | ||
| let session_ids = main_document_network_event_session_ids(conn, state.session_id.as_deref()); | ||
| record_pending_main_document_response_body(conn, state, &session_ids); | ||
| record_main_document_request_body(conn, state, &session_ids); |
There was a problem hiding this comment.
record_main_document_request_body only runs from start_observed_main_document_navigation_progress_background_events, but request-stage Fetch navigations return through the Fetch pause path without entering this function. After Fetch.continueRequest, the navigation is resumed through the normal loader without another request-body capture point.
This means Network.getRequestPostData still has no captured body for main-document POST requests when Fetch interception is enabled, including bodies overridden via Fetch.continueRequest.
Pelease move this capture into a path shared by both normal and Fetch-intercepted main-document requests, or explicitly capture it in the Fetch branch as well.
| let Some(request_id) = state.request_id.clone() else { | ||
| return; | ||
| }; | ||
| let Some(request_body) = state.clone_request_body_bytes() else { |
There was a problem hiding this comment.
clone_request_body_bytes() intentionally prefers request_body_bytes, which may contain binary file payloads for multipart forms. NavigationDispatchState::request_body, on the other hand, is documented as the text projection used by CDP request events and Fetch interception.
CDP Network.getRequestPostData requires multipart file contents to be omitted, but storing the raw transport bytes in the runtime captured-request store means a main-document file upload can return the actual file bytes (or their base64 representation).
Please keep request_body_bytes for the BiDi collector, while storing request_body in the CDP captured-request store. It would also be good to add a multipart file-upload regression test for this distinction.
2 participants
Network.getRequestPostData returned "No post data available" for form-POST
navigations even though Network.requestWillBeSent carried the postData.
The captured-request-body store had a single writer, record_subresource_request_body
(backlog.rs), so only subresource requests were recorded; the main-document
navigation path recorded response bodies but never request bodies.
Record the main-document navigation request body alongside the response body
in start_observed_main_document_navigation_progress_background_events, mirroring
the subresource path: store it in both the collector store (so BiDi
network.getData also works) and the runtime slot's captured-request store
(what getRequestPostData reads). No addDataCollector setup is required to read
it back, matching Chromium's semantics.
Add regression coverage: a focused test driving the main-document progress path
with a POST body, and an end-to-end test submitting a real
and asserting getRequestPostData returns the urlencoded body.