Re: handling multi-request fetches in Nav & Resource Timing

On Wed, Feb 18, 2015 at 12:08 PM, Patrick Meenan <pmeenan@webpagetest.org>
wrote:

> Would unique request ID's work better for tracking the sequence (knowing
> that some of the ID's may no longer actually be in the buffer)?
> Only other thing that comes to mind is also including requests for
> OCSP/CRL validation and how those would get folded in since they aren't
> sequential but rather a list of requests needed to complete the negotiation
> before the first request could complete.
>

Thinking about this some more, there is another pitfall with relying on
"name": we can't resolve the case where multiple multi-request (or mix of
multi-request + single request) fetches are made against the same URL (in
parallel or sequentially) -- e.g. the application fires multiple uploads
against the same URL, where the first one triggers a preflight, and the
upload itself may be split across multiple requests with different byte
offsets. Using just "name" doesn't allow us to distinguish which requests
are tied to which sequence.

What if we introduced the concept of a "fetch group": a sequence of one or
more requests required to fulfill the fetch?

a) http://example.com > https: (OCSP) > //example.com --- a fetch group of
three requests.
b) (preflight) > http://other.com/thing.js -- a fetch group of two requests.
c) PUT http://example.com/upload -> (resume) PUT http://example.com/upload
--- a fetch group of two requests.

If we had such a thing, plus a "getEntriesByGroup()", then I think we could
even get away without "nextName". The application workflow would be:

req = performance.getEntriesByName(<url>)
reqs = perfomance.getEntriesByGroup(req.group) // returns an Array of
requests sorted by request start time.

Alternatively, we could only expose group for 1+ request sequences,
allowing apps to know when they should look for more than one request. E.g.

req = performance.getEntriesByName(<url>)
if (req.group) {
  reqs = perfomance.getEntriesByGroup(parent.group)
}

Above workflow doesn't address the case where some requests may have been
kicked out from the buffer, but on the plus side it allows any request to
identify itself as a member of a group - i.e. you don't have to follow a
strict parent --> child chain, you can pick any child and retrieve the full
group.

WDYT?

For (d) would that include something like a progressive video playback
> handled by range requests?  Any way to also expose the ranges?


Perhaps, but I think this is a separate discussion.