Surface requests for multi-request fetches (redirects, preflights, etc)

[igrigorik]

Some fetches incur multiple requests before they are fulfilled - e.g. redirects, permission preflights, resumed upload/downloads, etc. Today, these are hidden and not observable (although sometimes you can infer that a redirect happened based on type of response you get), and we need a mechanism to make them observable, such that they can be measured and accounted for -- this is a common issue and request filed against Nav and Resource timing.

We already have Timing-Allow-Origin to signal that timing data is allowed to be shared with particular origins. Perhaps we need a similar header to "reveal" the intermediate requests? Or, perhaps we can extend TAO to allow this?

1. As of today TAO is a no-op for same-origin requests. We could extend it to act as a signal for same- and third-party origins that intermediate requests are allowed to be surfaced.
2. We could add a separate header with similar definition and semantics as TAO. This would allow behavior where you can allow intermediate requests to be surfaced but opt out from providing detailed timing data. This offers more granular control but at the cost of yet another response header (overhead).

Thoughts?

[annevk]

As suggested in #66, I think we want something like CORS, but for redirects (either same or cross-origin). Perhaps TAO needs to be layered on top of that though for timing-specific stuff.

[igrigorik]

Speaking of CORS, what about preflights? Any reason why you're scoping it to redirects?

[annevk]

The redirects thing was mostly about being able to get to the contents of a redirect. Such a thing doesn't make much sense for a CORS preflight I think. We could probably expose details from a CORS preflight without additional protocol (other than TAO).

[igrigorik]

@annevk what exactly is "contents of a redirect"? The URL during that hop? 3XX's don't carry a response payload. Also, note that for the purpose of Nav and Resource Timing we're not after payloads, headers, or response codes. Rather, we want to surface that a redirect hop / preflight occurred, plus some timing metrics around it.

Actually, thinking out loud... Are there any issues with simply surfacing the fact that a redirect happened without disclosing any other information? For example, say I fetch A, which bounces me to B and that reroutes me to C. If I query via Resource Timing (performance.getEntriesByName("A")), I'd see:

[
PerformanceResourceTiming{ name: A }, 
PerformanceResourceTiming{ name: A },
PerformanceResourceTiming{ name: A, duration: X, domainLookupStart: ..., ... }
]

• We surface redirects as "empty" ResourceTiming events.
• If redirect URL provides TAO header, we could also surface timing metrics for that hop.
• All events have same name (resolved URL that was originally requested); optionally we can figure out if/how we could allow surfacing the hop URL?

Lots of details to think through here, but to start, thoughts on disclosing the request without providing any detailed information about it?

/cc @mikewest

[annevk]

@igrigorik any header of the 3xx and any body it may have (it's not forbidden). As for your proposal, I think I would prefer redirects to clearly opt-in even for that, since they've been so protected.

[annevk]

I'm going to close this as it's been five years. If this is still something that's desired a concrete proposal would help. (#601 tracks the opt-in for redirect idea and I'll keep that open as it's reasonably concrete. Mainly lacks implementer interest at this point in time.)