Issue 731157 has been merged into this issue.

Sorry, it's not clear to me what the issue is. What does a HEAD request have to do with the images? Could you perhaps make a public page that demonstrates this issue for me to look at?

Also, if you could record a netlog and attach it to this bug it could help me to diagnose the issue. See https://dev.chromium.org/for-testers/providing-network-details for instructions on gathering a netlog.

The cross-origin HEAD requests are used to get the Content-Type header, since that's all we really need. The original HEAD requests have the Access-Control-* headers on them. On refresh, the cached HEAD requests do not contain the Access-Control headers, so Chrome blocks the request with a 403, as seen in the gif.

I'll see what I can do about getting a netlog for ya.

So is the ordering:

Okay, so to clarify, you get the image originally using an <img> tag. Then you XHR (CORS+HEAD) to check the content type. Then, the next time you try to XHR (CORS+HEAD) it fails because the headers were stripped. Is that right? 

Scratch the first line in the above comment, sloppy editing.

The use case is the following:

Get a list of URLs to render on the page via a backend call to a server.
Loop through the list and perform HEAD requests to determine the Content-Type
Use the Content-Type header to determine what type of file it is, and then render the image based off of that.

The problem is, the URLs are mostly static.ziftsolutions.com requests, and the page that's making the requests is a different one, and since it's cross origin, the request requires the Access-Control headers. These headers are present on the initial non-cached call, but on refresh, Chrome hits its cache (in the network tab, it even says "Cached from Disk") and gets the request out, but the Access-Control headers are no longer present.

If there is no disk cache entry, a HEAD request won't be stored to disk. If there is an existing cache entry (e.g., from a previous GET), a HEAD request will update the response headers on disk.

Please do send the netlog, it should help.

Here you go. Thank you!

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

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

Unable to test this issue, as we need credentials to the link provided above.
As per comment 10,

@jkarlin: Requesting you to help in further investigating the issue by the net-export-log provided.

Thanks!

@rkalavakuntla I’m setting you up with credentials to one of our testing environments. You should be receiving an e-mail from notification@ziftsolutions.com with your login information and password.  

Click the link in the e-mail to activate your account. Make sure you’ve unchecked the Cache storage flag in your browser and then access this link:

https://staging.ziftmarcom.com/ng.html?tab=library#/content/ff8081815cc51042015cc5e3ba270049?cache=true

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

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