sitespeed.io icon indicating copy to clipboard operation
sitespeed.io copied to clipboard
verified publisher icon sitespeedio

Unexpected preflight OPTIONS requests when using --browsertime.requestheader

Open eserte opened this issue 4 years ago • 4 comments

Starting with sitespeed.io:12.5.0 the bundled chrome browser makes preflight OPTIONS requests for resources like fonts or external json data if --browsertime.requestheader is used. Depending on the server configuration, these requests may fail, which is causing the resource to not be loaded at all.

Steps to reproduce the problem:

A sitespeed run without --browersertime.requestheader is not problematic: docker run --name=sitespeed --rm -v /tmp/sitespeed:/sitespeed.io sitespeedio/sitespeed.io:16.8.0 --browsertime.iterations 1 -b chrome https://dasauge.de/aktuell/design/e1548

The same run with a random custom HTTP header set is problematic: docker run --name=sitespeed --rm -v /tmp/sitespeed:/sitespeed.io sitespeedio/sitespeed.io:16.8.0 --browsertime.iterations 1 -b chrome --browsertime.requestheader Foo:Bar https://dasauge.de/aktuell/design/e1548

This one causes a number of log messages like: [2021-02-09 08:32:33] INFO: The server responded with a 405 status code for https://cdn.dasauge.net/gfx/wf/Roboto-Light-webfont.woff

Looking on the waterfall page in the result pages one can see the failing OPTIONS requests. The screenshot also shows that a fallback font is used for the page, and some symbols are rendered as boxes (probably a missing icon font).

Some additional notes:

  • With sitespeedio:12.5.0 the error messages do not appear. Also the waterfall page does not show any error requests. However, the font requests are completely missing here. It looks like in earlier chrome versions the preflight OPTIONS requests were done, but not logged properly.
  • There are different server errors possible here. Some servers don't respond with a 405, but a 501. Some servers respond with a 200 to the OPTIONS request, but fail to accept the custom HTTP header (the response should contain access-control-allow-headers: foo in this case).
  • The first problematic chrome version seems to be 81. Version 80 (included in sitespeed.io:12.4.0) is not affected.
  • Possibly relevant links:
    • https://www.chromium.org/Home/chromium-security/extension-content-script-fetches
    • https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests

eserte avatar Feb 09 '21 09:02 eserte

This is an issue for Chrome right, there's been a change in Chrome that causing it?

soulgalore avatar Apr 13 '21 18:04 soulgalore

@soulgalore : Yes, it seems that it's caused by a change between Chrome 80 and 81.

eserte avatar Apr 14 '21 09:04 eserte

Any update?

pan-alexey avatar Jul 06 '21 08:07 pan-alexey

I haven't looked. I would create an upstream issue for Chrome and ask there.

soulgalore avatar Jul 06 '21 20:07 soulgalore

Closing since it seems to be a Chrome issue.

soulgalore avatar Dec 29 '23 06:12 soulgalore