UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce the problem:
1. visit a page such as http://whatever.com which responds with a 302, and whose response headers are such that neither the redirect nor the final content should be cached
2. visit it again with the developer tools open to verify that all the requests are done again and nothing is served from disc cache
3. do "view page source"
4. Now refresh the view-source:http://whatever.com page, and/or copy the url and paste it in the address bar again, with the devtools open

What is the expected behavior?
Just like the regular visit to the page doesn't caches anything, so shouldn't the visit to view-source:...
Particularly the 302 redirect shouldn't be cached.

What went wrong?
both the 302 response and the source content are served from cached, which can be verified by (a) looking at the devtools (it reads "from disk cache"), and (b) by having the server no longer respond with a redirect and change the contents of the response, and observe that Chrome still follows the bogus cached redirect and serves the old cached content.

Did this work before? N/A 

Chrome version: 55.0.2883.87  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 24.0 r0