Re: negotiated protocol in Navigation and Resource Timing

On Thu, Oct 16, 2014 at 12:46 PM,  <bizzbyster@gmail.com> wrote:
> "As such, at a minimum, I think we need to provide protocol info in NT, and
> for consistency and convenience I think we should also surface it in RT.
> That said, curious what others think…”
>
> Needs to be in RT to be able to understand performance characteristics of
> objects fetched from non-same-domain.
>
> Peter
>
> On Oct 16, 2014, at 3:13 PM, Ilya Grigorik <igrigorik@google.com> wrote:
>
> On Thu, Oct 16, 2014 at 10:05 AM, William Chan (陈智昌) <willchan@chromium.org>
> wrote:
>>
>> +tonyg to get his opinion
>>
>> Some questions:
>> * NT/RT is generally used for post-mortem analysis. I believe tonyg@
>> has been opposed to providing guarantees on how quickly it gets
>> populated. Does that limit the usefulness of the protocol here?
>> Suppose you wanted to dynamically change behavior based on protocol
>> used to deliver resources (e.g. a prioritized multiplexing protocol is
>> available, so you can issue resource requests immediately rather than
>> implementing a scheduler in JS). Is this information perhaps better
>> provided in the fetch Response object?
>
>
> It may make sense to provide protocol info on the Response object, but I
> don't think that's a strong argument against exposing the protocol in RT/NT.
> There are some rough plans to allow retrieving Response object from an
> element (e.g. <img>), but that's an involved affair that requires iterating
> over the DOM, and it still doesn't cover the case of the parent page
> (covered by NT) -- i.e. I can't get the Response object for the navigation.

Mostly I'd prefer not to duplicate data in multiple places.

>
> As such, at a minimum, I think we need to provide protocol info in NT, and
> for consistency and convenience I think we should also surface it in RT.
> That said, curious what others think...
>
> Re, changing fetch behavior: I think that's a valid use case. I may indeed
> want to change how I fetch some of my assets based on the protocol of the
> parent page or a particular origin. We should populate the protocol field as
> soon as we know it.
>
>>
>> * How is this property populated when serving from cache?
>
>
> Hmm, good question. Empty value?

Btw, we already leak whether or not a response was cached in other
ways, right? This should be mentioned in the privacy considerations.

>
>>
>> * Are we restricted to ALPN Protocol IDs? What about experimental
>> protocols like QUIC?
>
>
> I'll defer to Mark on this one :)

Well, I'm going to insist on being able to experiment. And ALPN is an
interesting choice since QUIC obviously doesn't get deployed using
ALPN :P

>
>>
>> * Are we potentially revealing more information than we should be
>> about the network configuration? For example, when a proxy is
>> configured.
>
>
> If you have a tunnel connection, we don't expose any extra information. If
> you don't tunnel, then we have no idea what the proxy may be using to talk
> to the server, hence we report the protocol to the proxy (that's all we
> know).
>
> So, yes it would be possible to detect *some* instances where user is routed
> through a proxy. I think that's worth calling out in the privacy/security
> sections, but I don't think that should block us from exposing the protocol.
>
>>
>> * How does this interact with Service Worker resource fabrication?
>> When the SW synthesizes a resource, what value do we report here?
>
>
> I think this falls into same bucket as cached response. Empty value?

I forget how SW interacts with NT/RT, but I sorta view this as a
reason to tag the protocol in the Response object. The SW may be
initiating fetches from the worker context rather than a document
context, so there's no document RT/NT to report the resource fetch.

>
> ig
>
>>
>> On Wed, Oct 15, 2014 at 7:16 PM, Ilya Grigorik <igrigorik@google.com>
>> wrote:
>> > After a few iterations (thanks Mark!), we've arrived at:
>> >
>> > ------- (discussion @ https://github.com/w3c/navigation-timing/issues/2)
>> > ------
>> >
>> > readonly attribute DOMString protocol;
>> >
>> > This attribute must return protocol used to fetch the resource, as
>> > identified by the ALPN Protocol ID (see
>> > https://tools.ietf.org/html/rfc7301). When a proxy is configured, if a
>> > tunnel connection is established then this attribute must return the
>> > ALPN
>> > Protocol ID of the tunneled protocol, otherwise it must return the ALPN
>> > Protocol ID of the first hop to the proxy.
>> >
>> > In order to have precisely one way to represent any ALPN protocol ID,
>> > the
>> > following additional constraints apply: octets in the ALPN protocol must
>> > not
>> > be percent-encoded if they are valid token characters except "%", and
>> > when
>> > using percent-encoding, uppercase hex digits must be used.
>> >
>> > Note that this attribute is intended to identify the protocol in use for
>> > the
>> > fetch regardless of how it was actually negotiated; that is, even if
>> > ALPN is
>> > not used to negotiate the protocol, this attribute still uses the ALPN
>> > Protocol ID's to indicate the protocol in use.
>> >
>> > ----------
>> >
>> > Above would apply to Navigation Timing and Resource Timing - aka, you
>> > can
>> > get the protocol for each resource fetch.
>> >
>> > Tobin: could you run this by the IE networking team for feedback?
>> > Patrick: any feedback from Mozilla side?
>> >
>> > ig
>> >
>> > On Tue, Oct 14, 2014 at 7:47 PM, Ilya Grigorik <igrigorik@google.com>
>> > wrote:
>> >>
>> >>
>> >> On Tue, Oct 14, 2014 at 3:26 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> >>>
>> >>> Gave my feedback on the issue. I think you misunderstand -- ALPN isn't
>> >>> required to be used to use its protocol identifiers as a name space.
>> >>> That's
>> >>> what a lot of protocols are currently doing (e.g., RTC, TURN).
>> >>
>> >>
>> >> Doh, you're right, misread your original proposal. Thanks for the
>> >> clarification!
>> >>
>> >> How about this:
>> >> https://github.com/w3c/navigation-timing/issues/2#issuecomment-59150636
>> >> -
>> >> getting closer?
>> >>
>> >> ig
>> >>
>> >
>
>
>

Received on Thursday, 16 October 2014 22:37:26 UTC