Re: Introducing a Session header...

I have seen that kind tight-loop often enough, and I suggest to consider
any loop like that as SPDY in the manner one-step ahead.

In that sense, I can then say we can use Microsoft's post about the
Multi-Legged authentication scheme and consider SPDY as one of the options
along with Kerberos (and others).

For the political mode, later, it wraps client-server technology into
HTTP/2 that was not so wrapped in HTTP/1.x

On Friday, July 20, 2012, James M Snell wrote:

>
>
> On Fri, Jul 20, 2012 at 3:41 AM, Poul-Henning Kamp <phk@phk.freebsd.dk<javascript:_e({}, 'cvml', 'phk@phk.freebsd.dk');>
> > wrote:
>
>> In message <9c4a1f3bd08bf10c608b2c01f01440b2.squirrel@arekh.dyndns.org<javascript:_e({}, 'cvml',
>> '9c4a1f3bd08bf10c608b2c01f01440b2.squirrel@arekh.dyndns.org');>>, "Nicol
>> as Mailhot" writes:
>>
>> >1. at the start of a stateful interaction the server (only actor that
>> >knows it will need state) challenges the user agent for a new unique id,
>> >and provides a unique state tag (short so it can not be abused for
>> >anything else)
>>
>> I think we can speed up this safely by allowing the client to always
>> offer a unique ID without being asked.  If the server doesn't need it,
>> it will just ignore it.
>>
>>
> Again, just brainstorming on this.... not sure if this works..
>
> Client                 Server
>   |                      |
>   |=====================>|
>   |1)KEY_NEGO            |
>   | id=1                 |
>   | alg=session_key      |
>   | params=...           |
>   |                      |
>   |=====================>|
>   |2)SYN_STREAM          |
>   | id=1                 |
>   | method=GET           |
>   | session_key=1        |
>   |                      |
>
>
>>  >I'm quite sure that if such a mechanism existed today the EU would have
>> >just banned cookie use altogether.
>>
>> Indeed.
>>
>> --
>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> phk@FreeBSD.ORG         | TCP/IP since RFC 956
>> FreeBSD committer       | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by
>> incompetence.
>>
>>
>

Received on Friday, 20 July 2012 17:19:34 UTC