ensure fetch/ajax image requests accept webp when supported

[andrewharvey]

Launch Checklist

fixes #8261

• briefly describe the changes in this PR
  See further detail at ensure image requests send an accept header #8261 , but in essence this PR ensures image requests from GL JS to servers, include accepts image/webp where supported, so the server knows if it can respond with a webp image or not
• write tests for all new functionality
• document any changes to public APIs
• post benchmark scores
• check this webp support test is only run once, instead of at each tile request, and what impact it has on performance tested, only run once
• manually test the debug page
  tested

[asheemmamoowala]

@andrewharvey Are you still working on this PR? The change itself looks fine to accept, but I want to understand how this affects the serving of non-tile resources if webp is added to the accept header, before moving forward with it.

@samanpwbb @jseppi Would the sprite images endpoint be affected by the addition of an accepts header with image/webp?

[andrewharvey]

@andrewharvey Are you still working on this PR? The change itself looks fine to accept, but I want to understand how this affects the serving of non-tile resources if webp is added to the accept header, before moving forward with it.

Yes, I can pick this up again.

@samanpwbb @jseppi Would the sprite images endpoint be affected by the addition of an accepts header with image/webp?

For more context, GL JS will always request a sprite image with the extension .png:

mapbox-gl-js/src/style/load_sprite.js

Line 28 in 87cac3b

let imageRequest = getImage(requestManager.transformRequest(requestManager.normalizeSpriteURL(baseURL, format, '.png'), ResourceType.SpriteImage), (err, img) => {

However as explained at #8261, when making a Fetch or XMLHttpRequest, the browser will pass / as the accept header and hence the server won't be able to detect if the client supports webp or not.

I tested Mapbox's API requesting the sprite.png with accepts: image/webp and there was no difference, the response was still the PNG sprite, which is fine. So it doesn't look like this breaks anything for sprites. Even if the server was smart and detected the accepts header and returned a webp sprite in spite of the .png extension that should also be fine, it should work.

[andrewharvey]

(edited)

I did further testing,

It does only test for webp once at the start (checking of one of the things I noted to test).

• On Chrome, it works fine.
• On Firefox, there was a lag for the webp support check coming back positive, so the first few requests wouldn't pass the accepts webp header but later requests would. It looks like this issue stems from the webp support check.

[asheemmamoowala]

On Firefox, there was a lag for the webp support check coming back positive, so the first few requests wouldn't pass the accepts webp header but later requests would. It looks like this issue stems from the webp support check.

@andrewharvey how much of an issue is this? Does it matter if a few requests don't use webp images, or should the requests be blocked until the check is completed?

[andrewharvey]

@andrewharvey how much of an issue is this? Does it matter if a few requests don't use webp images, or should the requests be blocked until the check is completed?

Nothing more than a minor annoyance. I wouldn't hold up the requests because of this.

[asheemmamoowala]

These changes are ✅. Can be merged with a unit test.

[ryanhamley]

@andrewharvey Are you still working on this? I think we just need a unit test to merge it.

[andrewharvey]

@andrewharvey Are you still working on this? I think we just need a unit test to merge it.

@ryanhamley yes! unit test committed ✔️