Issue metadata
Sign in to add a comment
|
Cannot see "form data" for some form post urls in Network tab under headers sub-tab
Reported by
abhilash...@gmail.com,
Sep 26 2017
|
||||||||||||||||||||||||
Issue descriptionChrome Version : Version 61.0.3163.100 (Official Build) (64-bit) URLs (if applicable) : www.att.com Other browsers tested: Add OK or FAIL, along with the version, after other browsers where you have tested this issue: Safari:NA Firefox:tested with HTTP fox addon, works IE:NA What steps will reproduce the problem? Please go to developer tools and check preserve log to capture the requests and proceed with following steps: (1)Go to https://www.att.com/ and click login on top right corner. (2)Enter some dummy credentials and click login button. (3) Check the form post request to **.att.com/commonLogin/igate_wam/multiLogin.do, form data in Headers sub-tab under Network tab. What is the expected result? Form data entered in step 2 should be visible in headers tab What happens instead? Cannot see form data Attaching screenshots of chrome and firefox. In firefox tested with httpfox addon where i can see form post data @URL : **/commonLogin/igate_wam/multiLogin.do
,
Oct 4 2017
I'm too facing the same issue in chrome 61.0.3163.100 (OS X - 10.12.6) Basically our page redirects (302) after POST and couldn't see form data in the headers whereas it works fine in Firefox 55.03 (shows in params tab)
,
Oct 6 2017
Unable to triage this issue from TE as there is no access for www.att.com in India, hence adding TE-NeedsTriageFromMTV label for further triage Could someone from MTV team please take a look into this issue. Thanks..!!
,
Oct 10 2017
,
Oct 11 2017
Seeing the same issue, it appears to happen on any page that redirects (302) after form data is POSTed. Using Version 61.0.3163.100 (Official Build) (64-bit) on Mac OS X 10.12.6
,
Oct 24 2017
Same issue in version 62.0.3202.62 Also, the POST request that triggers a 302 redirect used to persist in the log until the next page navigation, even when preserve log was switched off. This was a very useful feature! Can we get that back too?
,
Oct 25 2017
Here is a simple nodejs server that will show the issue. Just turn it on and go to localhost:8080.
The form data should be "something=10"
var http = require('http');
var server = http.createServer(function(req, res){
console.log(req.method, req.url);
if(req.method == 'POST'){
res.writeHead(302, { 'Location': '/elsewhere/' });
} else if (req.url.match(/favicon/)){
res.writeHead(404);
} else if(!req.url.match(/elsewhere/g)) {
res.write('<html><form action="/elsewhere/" method="post">' +
'<input name="something" value="10"/><br>' +
'<button>Post!</button>' +
'</form></html>');
}
res.end('');
});
server.listen(8080);
,
Oct 27 2017
Any update on this ? You don't need access to att.com try checking any 302 POST request as many said.
,
Nov 7 2017
Any update on this ?
,
Nov 15 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ligim...@chromium.org
, Sep 26 2017