为什么某些iOS设备使用Origin：null发送OPTIONS请求？

Question

On a website I'm working on, we're seeing quite a few OPTIONS requests from iOS devices that look like CORS preflight checks , but which have Origin: null . Does anyone know what might be causing such requests to be sent with Origin: null rather than the correct origin?

The user agents that I've seen exhibiting this behaviour are:

Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206
Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3
Mozilla/5.0 (iPod; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206
Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3
Mozilla/5.0 (iPod; CPU iPhone OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B176 Safari/7534.48.3
Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3
Mozilla/5.0 (iPad; CPU OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3

In practice, it's not a problem to deal with these requests (just refuse them), but I'm curious to know if there's some particular set of circumstances that is causing this. The only situation I've seen described where the Origin header might be set to null is when the origin is a file:/// URL, and that seems very unlikely - the referer in each of these cases looks like a normal page view of the site.

Answer 1

This question is related but this blog post explains the problem and solution.

If you've seen this behavior in your application, you should be able to fix it by using “Content-Disposition: inline” and not “Content-Disposition: attachment”.