teo8976@: thanks for reporting potential issues to us.  Could you provide a net-internals dump with this problem?  That would make it much easier for us to figure out what's going on.  See https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details. Thanks!

Can't you do that by yourself? The steps to reproduce are pretty straight-forward.

Thank you for providing more feedback. Adding requester "zhongyi@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Sorry, I should make it more clear. 

To get a 500 response, server code needs to crash. I am assuming you already have the URL to reproduce the issue. If you found it inconvenient to grab net-internals for us, no problem, we can do that. Could you provide the sample URL to reproduce the issue so that we can grab net-internals on our side? 

mmenke@: could you take a look at this issue and see whether we have any server to grab to reproduce the issue and continue investigation? Thanks!

I can't reproduce this.  I have a toy server that returns a page with a form.  When it's submitted with a POST, the server returns a 500 response with a 1-character body.  Pressing F5 or the reload button correctly brings up the resubmit dialog.

Is your server sending a redirect response to the initial POST that converts the POST to a GET?  Could you please provide a net-internals log of this happening?  Instructions:  https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Or by "hitting Refresh", do you mean you're using document.location.reload(), via an in-page button, instead of one of the browser's built-in reload mechanisms?

> When it's submitted with a POST, the server returns a 500 response with a 
> 1-character body

And when you wrote that 1-byte body response, didn't you think for a moment that *maybe* you needed to try with an empty body?
I did the second I read "1-character body", so I built a page that reproduces the issue:

http://matteosistisette.com/test/stupidchrome/500_post_reload/

Apparently it happens when the response is empty. 

You're welcome.

@8 no, I am using the browser's built-in reload button.

I have you a bunch of variations on what you could have been doing that was different - trying every single one of them is not a productive use of time when I could just ask you.  No need to be snippy.

Curiously, a 0-length body isn't enough to repro it either.  It looks like your server is claiming a content-length of 20 (An empty gzip file?) which is not something I would have tried.

But you didn't try even the 0-length body, did you :P

Funny though, this server is not the same where I originally observed the issue.

Can you tell whether the gzip-encoded response is actually 20-byte long, or if the server is "claiming" it's 20 bytes but it's actually 0 even encoded? I don't see a way to check that in the developer tools (such as view the original undecoded response), which by the way is an irritating deficiency in the developer tools.

Well, I checked with curl, the empty gzipped response is actually 20 bytes in size encoded (the overhead of gzip encoding, I guess). It seems to be a perfectly valid response.

When sending a 0-length body, I didn't get the error page, but with the response your test page sends, I do, which is weird.  It looks to me like this broke when we started showing the error page in this case.  We also don't show the reload button when a page fails to commit before we show the error page, so I suspect that's the underlying issue.  Should figure out why we show the error page for some 0-length 500s and not for others, but the primary issue here seems to be not showing the confirmation dialog, not whether or not we show the error page.

So presumably Blink is losing POST data when the page doesn't successfully commit.  Not actually a network stack issue.  Not sure the right person to investigate this, adding the navigation and forms labels.

Adding lukasza@ in case he can help triage, given the various POST bugs he's been working on recently.

Er, "We also don't show the reload button when a page fails to commit before we show the error page, so I suspect that's the underlying issue." should be "We also don't show the reload confirmation when a page fails to commit before we show the error page, so I suspect that's the underlying issue."

One crazy thing:
at http://matteosistisette.com/test/stupidchrome/500_post_reload/

I used to see the error page (the one generated by Chrome, saying "Internal Server Error" or something) when submitting the form. Now I'm not seeing anymore, and nothing has changed on the server.  The behavior on refresh, however, is consistently wrong (I notice it is sending an empty post request, as the other bug describes, not a get request as I said, which I guess I just assumed)

1. This is not a duplicate of 71204. I won't repeat what it's already been said here and in the other issue: just read the descriptions, it's different. Please remove the duplicate status.

2. The response doesn't need to be a 500 in order to reproduce the issue: an empty 200 response (with whatever particular conditions that were found to be necessary) will reproduce the issue too

3. This is a CRITICAL SECURITY ISSUE: how the fuck is it possible that nothing has been done yet??

Also I found out:

The behavior actually changes depending on whether you have the DevTools open or not.

Test page: 
http://matteosistisette.com/test/stupidchrome/500_post_reload/

** Without DevTools **
- visit the above page
- send the form
  => the server returns a 500 response with an empty body
  => Chrome shows a "500 Internal Server Error" error page
- hit Refresh
  => Chrome doesn't prompt for resubmission and sends a GET request without parameters


** With DevTools **
- visit the above page
- send the form
  => the server returns a 500 response with an empty body
  => Chrome shows a COMPLETELY BLANK page
  => Chrome RESENDS the POST request with the form data, without prompting for resubmission.