Forgot the example URL: https://jfr.im/307test/

I can't reproduce this, using that example URL:

First request:
t=128988 [st= 2]        HTTP_TRANSACTION_HTTP2_SEND_REQUEST_HEADERS
                        --> :authority: jfr.im
                            :method: POST
                            :path: /307test/307.php
                            :scheme: https
                            accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                            accept-encoding: gzip, deflate, br
                            accept-language: en-US,en;q=0.9
                            cache-control: max-age=0
                            content-length: 9
                            content-type: application/x-www-form-urlencoded
                            origin: https://jfr.im
                            referer: https://jfr.im/307test/
                            upgrade-insecure-requests: 1
                            user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

After redirect:
t=129010 [st=24]        HTTP_TRANSACTION_HTTP2_SEND_REQUEST_HEADERS
                        --> :authority: jfr.im
                            :method: POST
                            :path: /307test/200.php
                            :scheme: https
                            accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                            accept-encoding: gzip, deflate, br
                            accept-language: en-US,en;q=0.9
                            cache-control: max-age=0
                            content-length: 9
                            content-type: application/x-www-form-urlencoded
                            origin: https://jfr.im
                            referer: https://jfr.im/307test/
                            upgrade-insecure-requests: 1
                            user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Could you disable any extensions, and provide a chrome://net-export/ log of this?  Instructions:  https://dev.chromium.org/for-testers/providing-network-details

Did you refresh after the redirect? That's when the issue occurs.

I'll attach two logs, one from non-incognito, one from incognito. Incognito behaves differently for some reason. The only extension I have installed is "GNOME Shell Integration" which unfortunately Chromium believes was installed by enterprise policy.

Interestingly, in incognito, it asked if I wanted to re-submit the form data when I refreshed. It doesn't do that in a normal window.

Both of these don't seem to have a content-type request header after the refresh at all. The behavior I've normally been seeing in Dev Tools (and saw the first time I did the log) was an empty content-type header being sent.

Deleted: incognito-chrome-net-export-log.json 98.1 KB

incognito-chrome-net-export-log.json 98.1 KB View Download

Deleted: chrome-net-export-log.json 316 KB

chrome-net-export-log.json 316 KB View Download

I take that back - it does ask me to confirm resubmission in a normal window. So incognito and normal appear to be behaving the same.

Sorry, missed the refresh part.  That means this is a navigation issue - for some reason, it's not caching the content-type for use with the re-submission.

Unable to reproduce the issue on reported chrome version 67.0.3396.99 using Ubuntu 17.10 . Attaching screencast for reference.
Steps: 
---------
1. Launched reported chrome 
2. Navigated to given url in the comment #1 ""https://jfr.im/307test/"" and opened Dev tools >Network 
3. Clicked on GO and noticed REQUEST_HEADERS and refreshed page again noticed REQUEST_HEADERS
As we are observed that the same response in the REQUEST_HEADERS both times.

@Reporter: Could you please review the attached screen-cast and confirm if anything being missed here.

Thanks.!

Deleted: 860546.webm 5.8 MB

	860546.webm 5.8 MB View Download

#8 your content-type was blank after refresh as well. Prior to refresh it was properly application/x-www-form-urlencoded

Deleted: Screenshot from 2018-07-11 10-09-36.png 493 KB

	Screenshot from 2018-07-11 10-09-36.png 493 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Able to reproduce the issue on Mac 10.13.3, win-10 and Ubuntu 17.10 using chrome reported version #67.0.3396.99 and latest canary #69.0.3489.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!