1

I am testing the performance of adding the crossorigin attribute to images.

It seems that there are different observable CORS image request behaviors in Chrome and Firefox, also differences on Windows and Linux.

I normally use Chrome on Linux, and as can be observed on an example page where the images are served from a correctly configured CORS proxy, there are no indications in devtools that the OPTIONS method is being used. However, the requests look like CORS requests as they include the Origin header.

I have noticed a difference in the request headers if the server does not support the OPTIONS method, here for example, which leads me to suspect that the browser does do a preflight, but it may not be logged in Chrome or Firefox devtools.

Strangely, Chrome DevTools on Windows logs the warning "Provisional headers are shown" for the same example, but also does not indicate that OPTIONS requests are used.

One other question, is there a negative impact on performance if an OPTIONS response includes a body? For images, it seems advisable that the OPTIONS response should have a Content-Length of 0.

Christopher Johnson
  • 302
  • 4
  • 12
  • 1
    Browsers never do a preflight for images with the crossorigin attribute. The spec details are at https://html.spec.whatwg.org/multipage/images.html#updating-the-image-data:attr-img-crossorigin-3 and https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request and while it’s not immediately obvious from reading those that it means there’s no preflight, the gist of it is that the request is a simple GET request with no custom headers added, so nothing ever ends up being in there that can trigger a preflight. – sideshowbarker Oct 14 '18 at 16:57
  • 1
    An OPTIONS response should never have any response body. If an OPTIONS response does have a body, I guess whatever impact on performance that might result from that depends on the client code consuming it. The semantics of a non-empty response body are undefined — not specified in any HTTP spec. So I’d think in practice most clients don’t expect to receive a non-empty body from OPTIONS response — & so if they do receive one, the behavior might end up following some unexpected code path. Or something. So anyway, it seems prudent to avoid sending a non-empty response body in responses to OPTIONS – sideshowbarker Oct 14 '18 at 17:04
  • 1
    I think the "Provisional headers are shown" devtools message is unrelated to the whether or not it’s a crossorigin-attribute case. There are a number of reasons that browsers will log that message. See https://stackoverflow.com/q/21177387/441757. But the simplest case when they do is just when the browser has cached a resource and is loading it from its cache rather than actually (re)fetching it over the network. – sideshowbarker Oct 14 '18 at 17:14
  • Thanks. Those are good references. I remain puzzled by the "opaque response" scenario. Is a crossorigin image response still opaque since there is no preflight? – Christopher Johnson Oct 14 '18 at 18:22
  • Actually, I can answer that as no, because an opaque response will not have a status, and these image responses are 200. On a related issue, for certain image requests, the service worker returns a 0 status. I wanted to believe that this was related to the image server not supporting OPTIONS, but your answer puts this theory in question. – Christopher Johnson Oct 14 '18 at 18:33
  • 1
    A response for an image without the crossorigin attribute is always opaque, because the request mode for that case is 'no-cors'. But a response for an image with the crossorigin attribute is not opaque. If the response has the Access-Control-Allow-Origin header, then the browser won’t block you from accessing the response properties (e.g., the HTTP status code of the response). – sideshowbarker Oct 14 '18 at 18:36
  • I think that the [Fetch spec](https://fetch.spec.whatwg.org/#general) should be modified to include as an exception to preflight per your answer. "For requests that are more involved than what is possible with HTML’s form element [or img element], ..." – Christopher Johnson Oct 14 '18 at 18:54

0 Answers0