alt svc issue #126 clarify invalidation rules wrt altsvc frame

On 2015-12-10 22:24, Martin Thomson wrote:
> ...
>>> 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.
> ...

Now tracked as <https://github.com/httpwg/http-extensions/issues/126>.

Maybe:

"Receiving 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. Note that it would 
be unwise to mix use of Alt-Svc header fields with the use of ALTSVC 
frames, as the sequence of receipt might be hard to predict."

Best regards, Julian

Received on Sunday, 13 December 2015 17:42:17 UTC