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

+1

Do you consider any error tracking features on this API? In this use case,
developers want to know like 'session timeout error', 'connection closed by
server' or else. Right?


On Fri, Feb 20, 2015 at 2:44 AM, Ilya Grigorik <igrigorik@google.com> wrote:

>
> 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.
>
>
>
>
>


-- 
KAWADA Hiroshi
Web Developer (JPN)
http://hiroshik.info/