W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: Ascii-based SPDY "compression" idea

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Mon, 02 Apr 2012 14:36:33 +0000
To: ifette@google.com
cc: (wrong string) ™ˆ™˜Œ) <willchan@chromium.org>, ietf-http-wg@w3.org, Peter Lepeska <bizzbyster@gmail.com>
Message-ID: <3188.1333377393@critter.freebsd.dk>
In message <CAF4kx8cqCiBWZz4sbXqShDzTdgggSgprdLpF3_5Beg+gQf4cFw@mail.gmail.com>
, =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= writes:

>I'm curious if under your definition of "http router" that box is
>terminating the ssl connection and forwarding to different backends or if
>you are speaking about the non-ssl case.

That's actually an interesting question.

One option, which I personally really like, is that we use a toplevel
"container" format to do multiplexing (and possibly routing), and
allow the channels to be individually TLS protected.

The nice thing about this is that we can do the upgrade to TLS using
the same TCP connection.

A mockup would look something like:

C->S	GET / HTTP/1.1
	Upgrade: http-20-tls

S->C	HTTP/1.1 101 Switching Protocols

S->C	[chan=1,msg=HTTP20-REPONSE,len=X] {200|OK|Set-Cookie: blablabla...}
S->C	[chan=1,msg=HTTP20-BODY,len=X] {<HTML>yaddayadda...}
S->C	[chan=1,msg=HTTP20-BODY,flag=FINAL,len=X] {..yaddayadda</HTML>}

C->S	[chan=2,MSG=TLS-SETUP,len=X] {start TLS negotiation}
S->C	[chan=3,MSG=TLS-SETUP,len=X] {TLS negotiation reply}
...TLS negotiation completes for chan=2 

... more unprotected objects may be pulled over chan=1 in the meantime

C->S	[chan=2,msg=HTTP20-REQUEST,flag=TLS,len=X] {TLS(request)}
S->C	[chan=2,msg=HTTP20-REPONSE,flag=TLS,len=X] {TLS(reponse)}
S->C	[chan=2,msg=HTTP20-BODY,flag=TLS,len=X] {TLS(body part 1)}
S->C	[chan=2,msg=HTTP20-BODY,flag=TLS,FINAL,len=X] {TLS(body part 2)}

If we do something like that, the HTTP-router does not have to terminate
the TLS in order to route the traffic, provided the routing criteria
is available outside the TLS protection.

But of course it is still possible to terminate the HTTP at the
HTTP router if that is desirable.

A variation of the above is to do the TLS setup on channel=0 and
allow all channels to flag individual containers for SSL protection
in that TLS session, simply by setting the TLS flag in the container,
but not mandate that they do so.

This would allow secure sites to limit TLS processing to those
components of the webpage which actually needs it.  (How that
is indicated graphically to the user is also an interesting

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 Monday, 2 April 2012 14:37:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:59 UTC