- From: Garret Rieger <grieger@google.com>
- Date: Thu, 11 May 2023 12:04:56 -0600
- To: Skef Iterum <siterum@adobe.com>
- Cc: "w3c-webfonts-wg (public-webfonts-wg@w3.org)" <public-webfonts-wg@w3.org>
Received on Thursday, 11 May 2023 18:05:18 UTC
This: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests is a good summary of what won't trigger preflights. That does in fact claim that only simple range requests are allowed. One strategy to avoid preflight requests is to have the initial request be made in a way that avoids a preflight and have the initial response set the appropriate CORS allow headers (specifically Access-Control-Allow-Headers <https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers> so that follow up requests can be made without preflight). The existing range request spec I believe doesn't make use of ranges on the initial request as it's looking to just grab the front of the font file. On Tue, May 9, 2023 at 6:13 PM Skef Iterum <siterum@adobe.com> wrote: > Someone has pointed me to some documentation indicating that while a > request for a single range using the Range header is de jure simple, a > request for multiple ranges is not, and therefore will/should trigger a > CORS preflight request. We've had a number of discussions about the > undesirability of preflight requests in the context of the patch IFT spec > but I don't remember seeing anything about this for the range-request spec. > > It seems like this would add a significant cost to any mechanism relying > on range request for multiple ranges. Do we know if its true? > > Skef >
Received on Thursday, 11 May 2023 18:05:18 UTC