Query parameters

[mnot]

The IFT spec describes a format for use in query parameters of font URLs.

That's problematic, because it impinges on a server's authority over its own URLs.

The proper way to do this would be with request headers, probably Client Hints. If you don't want to do that, the next best thing would be to allow the site to dictate how to create a URL that contains the query information (e.g., using URI Templates).

[garretrieger]

To explain why we chose the query parameter:

• The most important requirement is that the initial request for a font should receive back the incremental data in only one round trip.
• In the initial request the client doesn't yet know if which variant of incremental transfer the server supports. Because we want the server to respond to the initial request with incremental data to satisfy the one round trip requirement we need to send enough information for either of the two server types to respond.
• Thus we need to ship some binary data (the PatchRequest message) with the first request.
• I considered a few alternative options to send that binary data:
  • Send the data in a header. Unfortunately this isn't an option because if we use any headers other than those that are cors safelisted there's the possibility of incurring a cors preflight request. Violating the one round trip requirement.
  • Send the first request as a POST request. This can be done without a CORS preflight, but isn't an option since a range request server won't necessarily be able to handle POST requests to static asset urls.
  • HTTP Methods other than GET/POST will incur cors preflight requests.

So that only leaves a query parameter on a GET request as a mechanism for passing the request data on the initial request.

Re: client hints, I don't think that helps us as client hints is about discovering client capabilities, where this is about discovering server capabilities and shipping down request data specific to incxfer.

To allow the content author to specify a URL format that would have to be part of the source url in the @font-face declaration. I'll have to look into that a bit more to see if that makes sense to do.

[svgeesus]

On a related note, in the course of link fixing for the upcoming publication of the fully-merged IFT spec, we how hav e defined term query parameter in the list of defined terms.

@mnot the plan is to get network and perf review once that spec is published.

Oh and I also updated the HTTP references so we now cite RFC9110, RFC9111 and RFC9112

[martinthomson]

In addition to what @mnot suggests as alternative, there is also potentially QUERY.

[garretrieger]

Thank you for pointing this out. QUERY is perfect for what we are trying to do. The incxfer server is specified as being stateless so we meet the requirements to use QUERY. I imagine query will be CORS safelisted? Also do you have an idea on the timeline for QUERY to be available?

[martinthomson]

It's available when you turn it on (or maybe when Fetch is updated to allow it, depending on your model).

Why do you need safelisting? Presumably your goal is for the browser to do this work, not the sites themselves.

[garretrieger]

Sorry, by safelisted, I mean will QUERY be considered a simple request (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests) like GET, HEAD, and POST are? This is important to incxfer since we want to avoid making a cors preflight request for performance reasons.

[mnot]

Are you trying to create something here that can be used without modifying browsers?

[garretrieger]

The intention is for browsers to implement this spec, so yes they will need to be modified. However, the spec is designed to not be tied to being implemented in a browser. It's possible that this could be also be implemented in non-browser contexts, for example in a mobile phone OS to incrementally load system fonts. I recently made a change where the http fetch algorithm is passed in as an input to the incxfer algorithm (see #69 for context)

[garretrieger]

The query parameter was removed in #113.