- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 17 Mar 2015 16:42:41 +1100
- To: Erik Nygren <erik@nygren.org>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
I’m not hearing any pushback on this, so I’ve marked #16 as editor-ready, with this note:
“””
Discussed on-list. Cache invalidation is to be scoped to a specific discovery mechanism; e.g., the alternatives you discover via the response header will be invalidated when you see a new response header, while those that were discovered via the frame will be invalidated only when a new frame is received.
This means each mechanism needs to define its own exact invalidation semantics, and probably needs to be capable of carrying multiple alternatives.
“””
Cheers,
> On 20 Feb 2015, at 3:24 pm, Mark Nottingham <mnot@mnot.net> wrote:
>
> Reading the thread again -- AIUI the intent is for invalidation to be scoped to a single discovery mechanism (the frame, a header, whatever).
>
> If that's the case, the use cases below will work, because they both use different mechanisms.
>
> So, I'm OK with this. We will need to be *very* careful to scope the invalidations, however.
>
> Cheers,
>
>
>> On 25 Aug 2014, at 10:30 am, Mark Nottingham <mnot@mnot.net> wrote:
>>
>> So, to be clear, you're suggesting that both the Alt-Svc header field and the ALTSVC frame type have the side effect of cache invalidation?
>>
>> Personally -- I'm not sure that's a good idea.
>>
>> For example, imagine a http:// service that a) wants to use Opp-Sec and b) the alternate wants to do some load balancing, etc.
>>
>> The http:// service sets an Alt-Svc header field with a very long lifetime, so that Opp-Sec is as sticky as possible.
>>
>> The alternate, OTOH, uses a fairly short lifetime for load balancing.
>>
>> With cache invalidation, the alternate doing load balancing is going to clear the cache of the Opp-Sec hint, thereby forcing the client to go back to the http:// origin once the (short lifetime) load balancing policy expires.
>>
>> Without invalidation, it'd fall back to the original Opp-Sec alternative.
>>
>> Likewise for the SNI segmentation use case.
>>
>> Regards,
>>
>>
>> On 24 Aug 2014, at 11:30 am, Erik Nygren <erik@nygren.org> wrote:
>>
>>> On Fri, Aug 22, 2014 at 7:50 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>>> On 22 August 2014 14:53, Erik Nygren <erik@nygren.org> wrote:
>>>> but does not define anything similar for the ALTSVC frame. Aligning the
>>>> frame and the
>>>> header would allow this to apply to both.
>>>
>>> I think that we would want to move the Origin field up to the header
>>> with Max-Age. Logically, you store alternatives for different origins
>>> separately, so requiring different frames makes sense there. It also
>>> removes any potential for duplication.
>>>
>>> Also 8 bits of length is not sufficient for an HTTP origin if the name
>>> is maximum size. I'd assume that the same applies to authority.
>>>
>>>
>>> Agreed on both counts. What about this, then:
>>>
>>> 0 1 2 3
>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> | Max-Age (32) |
>>> +---------------+---------------+-------------------------------+
>>> | Origin-Len (16) | Origin? (*) ...
>>> +---------------------------------------------------------------+
>>> |Num-Alt-Auth(8)|
>>> +---------------+---------------+-------------------------------+
>>> | Proto-Len(8) | Protocol-ID (*) |
>>> +---------------+-----------------------------------------------+
>>> | Alt-Auth-Len (16) | Alt-Auth (*) ...
>>> +---------------+-----------------------------------------------+
>>> | Ext-Param? (*) ...
>>> +---------------------------------------------------------------+
>>>
>>> where Origin-Len=0 would be used in the case where this was part of a Stream != 0
>>> and Num-Alt-Auth>=1. The {Proto-Len, Protocol-ID, Alt-Auth-Len, Alt-Auth} would be
>>> repeated Num-Alt-Auth times. Alt-Auth is a string such as "server.example.com:443"
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Mark Nottingham https://www.mnot.net/
>>
>>
>
> --
> Mark Nottingham https://www.mnot.net/
>
>
--
Mark Nottingham https://www.mnot.net/
Received on Tuesday, 17 March 2015 05:43:11 UTC