This seems to be also related with these reports on Stack Overflow:
https://stackoverflow.com/questions/46311968/google-chrome-network-developer-tools-form-data-is-missing-from-headers-tabs-o
https://stackoverflow.com/questions/46237449/chrome-developer-tools-do-not-show-form-data-on-windows-server-2012

Same issue on OSX too with 302 request

Tested on Chrome Stable #61.0.3163.91, Canary #63.0.3220.0 and Chrome #50.0.2624.0 on Windows 10, Mac 10.12.6, Ubuntu 14.04 and able to reproduce the issue. Screenshot is attached for reference.

This is a non-regression issue and able to reproduce from M-50 #50.0.2624.0. Marking it as untriaged so that issue gets addressed.

Thanks.

Deleted: 766715.PNG 285 KB

	766715.PNG 285 KB View Download

Same here, when the POST request resulted in a status 302, the form data for the POST request is *not* showing. Form data is showing when it is a 200.

MacOS High Sierra 10.13, Chrome 61

 Issue 770130  has been merged into this issue.

This is an important feature for developers. We're experiencing the problem on Windows 10 64 bit with Chrome 61.0.3163.100.

I do not think this should be marked as a non-regression issue.  We have multiple developers working in our team who utilize this feature and it worked until recently.  They are currently having to use FireFox to view the POST data.

I agree. This is a regression and should be marked as such. It's one of the main features in Chrome Developer Tools that my development team uses. It was working before and now it isn't, must be a regression.

Hi guys, I got the exactly same issue here: For 302 POST, no form data is displayed in Network Tab. I am using the Version 63.0.3229.0 (Official Build) canary (64-bit)

Issue seen in Version 61.0.3163.100 (Official Build) (64-bit)
MacOS Sierra v10.12.6

Issue present in Chrome 61.0.3163.100 and not present in Chrome 49.0.2623.112

Serious bug - Please fix ASAP.  This made SAMLResponse POST not show up for debugging.

Serious bug.
Present in Version 61.0.3163.100 (Official Build) (64-bit) on Mac OSX

The problem happens as well with "204 No-Content" response code. 
Tested Chrome version 61.0.3163.100 on Mac OSX.

Our dev team is also finding that 500 response XMLHTTPRequests are not showing responses in dev tools.  This means it is not possible to read the exception message if it is returned with a 500 status.  These were visible in previous versions.

@allada Any updates on the issue from Chromium? 

Issue present in Chrome 61.0.3163.100 and not present in Chrome 58.0.3029.110

Any updates?

This is a killer issue for enterprise app teams working on SAML integrations. Any updates?

I'm guessing it will take a while till this bug gets fixed. I am using Firefox' developer console in the meantime

who need chrome with working feature https://browser.yandex.com

While waiting for the bug fix you can use Fiddler https://www.telerik.com/fiddler

It's been two weeks since the bug was assigned. Is there any update/progress on this?

Same issue with newest version chrome on Windows 7. I think this priority should be highest.

Ironically this works fine in the current version of Opera (48.0.2685.52)

This should not be a low bug. this bug is making me use firefox due to not giving me the form data please increase from low to high and fix asap :)

The request payload is not shown also when the request is blocked using `Request blocking`.

Ironically I can see the request payload fine using a Vivaldi build based on Chrome/61.0.3163.102

This is a major bug for my team.  We are being forced to use other browsers in order to debug.

I hope this isn't done on purpose to avoid unauthorized users to read the passwords saved in the browser (that is indeed a security issue, but this is the wrong way to address it)

To all the need-to-comment-with-my-pain-fix-ASAP people. Please just use the freaking star option! :D

Note: Its open source if you want to speed things up make a PR

Best from 
A happy developer only interested in when the issue is fixed and not pain comments emails :D

The irony is also - this is a pain comment to :D

Serious bug.

I have to switch to firefox to get the request playload

This was caused by plznavigate. It appears that when the renderer submits a navigation request to browser the renderer gets notified of the request but somewhere it drops the request's HTTPBody.

eostroukhov@ is looking into it.

cc: clamy@ (just in case she knows exactly where it does this, otherwise we'll find it).

Yes this happens here: https://cs.chromium.org/chromium/src/content/browser/frame_host/navigation_request.cc?q=navigationrequest&dr=CSs&l=617.

+creis who reviewed the CL where we introduced this. This was a deliberate choice not to transmit the POST data to the renderer process if the request was redirected to a GET.

The main issue here is that DevTools only hears from the navigation after it is ready to commit.

 Issue 784928  has been merged into this issue.

 Issue 768906  has been merged into this issue.

 Issue 755997  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/649cc21a76d5e7e6dba6077b8013d3b8bf4ccc2d

commit 649cc21a76d5e7e6dba6077b8013d3b8bf4ccc2d
Author: Nathan Bruer <allada@chromium.org>
Date: Tue Nov 21 04:31:34 2017

Allows renderer gets post data if devtools attached w/ plzNavigate

Adds a temporary fix to allow devtools to get the post data of
navigation request if the renderer has devtools attached.

R=caseq,clamy
BUG= 766715 

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I875ea05e778fc431b6073a6fb6b1c393bcc904be
Reviewed-on: https://chromium-review.googlesource.com/770490
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Blaise Bruer <allada@google.com>
Commit-Queue: Blaise Bruer <allada@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518109}
[modify] https://crrev.com/649cc21a76d5e7e6dba6077b8013d3b8bf4ccc2d/content/browser/frame_host/navigation_request.cc
[add] https://crrev.com/649cc21a76d5e7e6dba6077b8013d3b8bf4ccc2d/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/redirect-302-with-post-expected.txt
[add] https://crrev.com/649cc21a76d5e7e6dba6077b8013d3b8bf4ccc2d/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/redirect-302-with-post.js

This bug requires manual review: We are only 13 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been exists since M61 and we're very close to M63 stable promotion. Issue listed at #40 is not yet baked/verified in Canary/dev, so I'm afraid it is too late for M63 as at this point as we're only taking absolutely critical and safe merges in.

@govind: the fix looks safe to me and 114 stars is on the higher end of our bug spectrum.

let's see how it behaves on Canary vs how close M63 promotion actually is. If M63 requires another set of fixes, we could try merging this one in as well.

Ok, pls update the bug with canary result. 
If canary result looks good and merge is approved, merge has to happen latest by 11:30 AM on 11/28 in order to make it to last M63 Beta release. Thank you.

When will this fix be added to Canary?  I just installed Canary (Version 64.0.3273.3) and the problem still happens.  I am willing to help test it.

Thanks.

There should be a new canary build now,. You can go ahead and test it.

Since this issue is not a regression in M63, I wonder if you have considered letting it bake longer and release it with M64 instead.

Enthusiastically confirming fixed in 64.0.3275.0. Would be awesome if this could get into M63. Thanks!

I can also confirm that it is fixed in 64.0.3275.0.

@cmasso: Why do you say that this is not a regression in M63?

I can confirm that this issue happens in (63.0.3239.59 (Official Build) beta (64-bit)).

allada@/ pfeldman@, how is the change looking in Canary so far?

Note: 
We're cutting M63 last Beta tomorrow. So if change looks good in canary and approved, pls plan to merge your change to M63 branch 3239 before 12:30 PM, Tuesday (11/28/17) so we can take it in for this week last Beta release.

govind@ Yes confirming it has not been giving issues in canary. I'll merge today pending your approval.

Approving merge to M63 branch 3239 based on comments #44, #48 and #52. Please merge ASAP. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/34b7aa1d2a17995423a3e4a68215a3ce6ab9008c

commit 34b7aa1d2a17995423a3e4a68215a3ce6ab9008c
Author: Nathan Bruer <allada@chromium.org>
Date: Tue Nov 28 19:26:04 2017

Allows renderer gets post data if devtools attached w/ plzNavigate

Adds a temporary fix to allow devtools to get the post data of
navigation request if the renderer has devtools attached.

TBR=pfeldman,govind
R=caseq,clamy
BUG= 766715 

(cherry picked from commit 649cc21a76d5e7e6dba6077b8013d3b8bf4ccc2d)

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I875ea05e778fc431b6073a6fb6b1c393bcc904be
Reviewed-on: https://chromium-review.googlesource.com/770490
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Blaise Bruer <allada@google.com>
Commit-Queue: Blaise Bruer <allada@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#518109}
Reviewed-on: https://chromium-review.googlesource.com/794342
Reviewed-by: Blaise Bruer <allada@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#585}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/34b7aa1d2a17995423a3e4a68215a3ce6ab9008c/content/browser/frame_host/navigation_request.cc
[add] https://crrev.com/34b7aa1d2a17995423a3e4a68215a3ce6ab9008c/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/redirect-302-with-post-expected.txt
[add] https://crrev.com/34b7aa1d2a17995423a3e4a68215a3ce6ab9008c/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/redirect-302-with-post.js

Everything should have landed and be present on stable soon. Thanks!

Closing bug.

Hi,

I'm on Mac OSX and using Google Chrome Version 67.0.3396.99 (Official Build) (64-bit) and this bug still seems to exists.

@atif089: please file a new bug including reproduction steps and a net-log (http://dev.chromium.org/for-testers/providing-network-details) and referencing this bug.