LPardue
commented
5 years ago Thanks @rmarx, I need some time to digest before a considered response. However, you've reminded me of another proposal from Mike West- Fetch Metadata Request Headers
This document defines a set of Fetch metadata request headers that aim to provide servers with enough information to make a priori decisions about whether or not to service a request based on the way it was made, and the context in which it will be used.
While that proposal is focused on security, the general ethos has some overlap with this draft.
kazuho
The current draft (-00) only supports a limited set of header fields and values (urgency, with 3 possible values and progressive, a boolean). Several comments have indicated that urgency should probably need at least 2 extra values (deferred and background).
I take some issue with this, because the current discourse seems to be mostly "we need 5 because Chrome uses 5" and I see some comments from @kazuho that discuss how these values can be mapped to bandwidth distributions (and, in my interpretation then, because bandwidth can only be distributed a limited number of ways, we don't need many header fields/values).
The way I see it, this part of the proposal should be general-purpose, communicating plenty of resource metadata to the server so more complex/fine-grained setups are possible if the server so desires. It can be debated how plentiful this should be, but imo, more flexible than what we have now. I feel that, in deciding which metadata to send and at which granularity, we should not just be looking at how this can concretely impact the bandwidth distribution (or how this maps to current browser approaches) but from a higher-level.
A strawman proposal for this would be to map html-parser level semantics (currently used by browsers to build their heuristics) semi-directly onto the headers. Some of this directly reflects/echos back metadata set in the HTML (e.g., whether something comes from a preload element or whether a JS file had the "async" attribute), while some come from internal browser implementation specifics (e.g., parser/render-blocking, whether a resource can be processed/parsed incrementally, ...).
This would lead to (semi-verbose) lists of "aspects" to be set for each resource. For example, if we assume the defaults of:
aspects=non-blocking,non-incremental,immediate,bodyaspects=render-blocking,headaspects=incremental,visible(below the fold would loose 'visible')aspects=preload,visible(preload implies 'delayed' vs the default 'immediate')aspects=defer,non-immediate(a JS tagged as async would beaspects=async)The nice thing about this approach is that it prevents us from having to re-define anything semantically: the mapping from inherent browser semantics, known by most developers (see #27), is kept intact. This makes the header values easy to follow/understand/manipulate for both browser implementers and end-users/web developers, leaving less room for errors/footguns.
The main downsides I can see are:
All in all, even if the "aspects" proposal is not to everyone's liking, I still feel we need to support more types of metadata and look further than what we're currently doing with HTTP/2 to determine which use cases to support.