On Wed, Sep 2, 2015 at 7:55 AM, Matt Caswell wrote:
>
>
> On 02/09/15 15:50, Bill Cox wrote:
> > As for the order issue, we parse headers before creating any, so I'll
> > just not add the header in the AddCallback if s->hit is set on the
> > server side. This should behave well long term, I thin
On 02/09/15 15:50, Bill Cox wrote:
> As for the order issue, we parse headers before creating any, so I'll
> just not add the header in the AddCallback if s->hit is set on the
> server side. This should behave well long term, I think.
Except that in master (i.e. version 1.1.0) you will not be a
On Wed, Sep 2, 2015 at 3:00 AM, Bill Cox wrote:
> On Tue, Sep 1, 2015 at 2:50 PM, Emilia Käsper wrote:
>
>> It's not quite clear to me why you'd have to resend parameters on
>> resumption. After all, they are definitive for the session. Best if the
>> draft explicitly specifies resumption behavi
On Fri, Aug 28, 2015 at 2:21 AM, Bill Cox wrote:
> On Thu, Aug 27, 2015 at 5:00 PM, Emilia Käsper wrote:
>
>> A client should (SHOULD) always repeat extensions on resumption though,
>> as it can't know whether the resumption will be accepted.
>>
>> Do you have a specific example where you need t
It's not really a bug. The behaviour upon resumption is extension-specific.
Most extensions are only needed for establishing the session; they're
ignored during resumption, and aren't stored in the session state. So it's
rather that the custom extensions API doesn't support stateful extensions.
A
