New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 755997 link

Starred by 4 users

Issue metadata

Status: Duplicate
Merged: issue 766715
Owner:
Last visit > 30 days ago
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Blocked on:
issue 760924



Sign in to add a comment

Missing form-data when response is 302 redirect

Reported by j0hn.com...@gmail.com, Aug 16 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce the problem:
1. Open the web developer tools
2. Go to the network tab and check the preserve log option
3. Submit a post form to and endpoint that processes it and returns a redirection.
4. Check the first request, which is the POST to the endpoint and look for the form-data information. It's not there if the response of the request is a 302 redirect.

What is the expected behavior?
The form data sent on the POST request should be visible on that request so i can check what did the form sent

What went wrong?
I cannot see the form data sent on the request.

Did this work before? N/A 

Chrome version: 60.0.3112.90  Channel: stable
OS Version: OS X 10.12.6
Flash Version:
 

Comment 1 by l...@chromium.org, Aug 16 2017

Owner: allada@chromium.org
allada@, could you please take a look?
FYI this could be related to  Issue 747812 

Comment 3 by hdodda@chromium.org, Aug 23 2017

Cc: jam@chromium.org hdodda@chromium.org
Labels: Needs-Feedback
@jam -- Could you please confirm if this is related to  issue 747812  and provide us any update on this.

Thanks!
I'm seeing this after Chrome updated to Version 61.0.3163.91. Previous Version 60.0.3112.113 confirmed working (was seeing form data on the same POST that is now broken in 61). I can also confirm form data appears fine when the POST returns 200, and the bug is at least affecting POST responses with 302, where the form data disappears from network tab response (confirmed on the same endpoint using Charles to modify the status code in the response). This is rather troublesome considering 302 is not abnormal on a POST response.
Screen Shot 2017-09-19 at 9.40.43 AM.png
33.3 KB View Download
Screen Shot 2017-09-19 at 10.23.50 AM.png
179 KB View Download

Comment 5 by jam@chromium.org, Sep 20 2017

Cc: clamy@chromium.org arthurso...@chromium.org nasko@chromium.org
Camille: can you ptal?

Comment 6 by clamy@chromium.org, Sep 20 2017

So I don't have time to look at it today but I have an idea about what happens. My guess is this happens because the 302 turns the request into a GET. In that case we delete the post data associated with the request (https://cs.chromium.org/chromium/src/content/browser/frame_host/navigation_request.cc?dr=CSs&l=576). Since DevTools only hears about the request when the request is ready to commit, it doesn't have access to the post data anymore. This would make it a duplicate of  issue 760924 .
Blockedon: 760924
I agree with Camille's initial guess.

1) common_params.post_data is reset here:
https://cs.chromium.org/chromium/src/content/browser/frame_host/navigation_request.cc?dr=CSs&q=%22common_params_.post_data+%3D+nullptr%22&l=576

2) After the navigation commits in the browser, it is sent back to the renderer process:
https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?type=cs&q=%22request.SetHTTPBody(GetWebHTTPBodyForRequestBody(common_params.post_data)%22&l=6128

3) Then the InspectorNetworkAgent make use of it. It is sent to the javascript frontend. See Network.requestWillBeSent

The problem is that InspectorNetworkAgent::WillSendRequest is called after the request has been sent, the redirects made and the response received.
So fixing  issue 760924  will solve this one too.

Comment 8 by allada@chromium.org, Nov 15 2017

Mergedinto: 766715
Status: Duplicate (was: Unconfirmed)

Sign in to add a comment