Re: alt-svc WG Last Call comments

On 10 December 2015 at 22:58, Julian Reschke <julian.reschke@gmx.de> wrote:
>> So if you have Origin -> alt1 -> alt2, then you keep only alt2 and don't
>> have a list.
>> I therefore propose to remove the "or, an alternative service might
>> itself advertise an alternative".
>
>
> Sounds right to me. What do the others think?

I agree, the context for the statement is wrong, so it becomes misleading.

I think that the intent of the statement is important to preserve
somehow.  Just looking, the second paragraph of 2.4 might be a better
home:

Therefore, if a client becomes aware of an alternative service, the
client SHOULD use that alternative service for all requests to the
associated origin as soon as it is available, provided the alternative
service information is fresh (Section 2.2) and the security properties
of the alternative service protocol are desirable, as compared to the
existing connection.

ADD: An viable alternative service is then treated in every way as the
origin; this includes the ability to advertise alternative services.

>> Section 3.1 defines the rule for invalidation. However, in my sense it
>> is not crystal clear that it applies also to alternatives discovered
>> through the ALTSVC frame.
>> I'd suggest adding that the ALTSVC frame is just another way of
>> transmitting an Alt-SVC header field, and therefore all the rules
>> applying to the header field also apply to the frame.
>> We may want to go a step further and say the rules defined for the
>> Alt-SVC header field apply to any other possibility of discovering
>> alternative services (including those not supported).
>
>
> Sounds right as well. Any concrete suggestion about what exactly to say and
> where to put it?

Section 4 seems right:

An ALTSVC frame is semantically equivalent to receiving an Alt-Svc
header field.  As a result, the ALTSVC frame causes alternative
services for the corresponding origin to be replaced.

Or something like that.  I note that this introduces the question of
ordering guarantees: a header field carried in a HEADERS frame might
not be strictly ordered in relation to the ALTSVC frame that appears
on Stream 0, HTTP/2 being as it is.  That implies a race condition.  I
don't think that it's an important one - anyone who advertises in this
fashion gets what they deserve - but it's something to ponder.

Received on Thursday, 10 December 2015 21:25:00 UTC