Re: Rechartering HTTPbis

On 26/01/2012 5:10 a.m., Poul-Henning Kamp wrote:
> In message<4F2023BD.8040408@treenet.co.nz>, Amos Jeffries writes:
>
>> The main point was to embed length details for the headers early, rather
>> than semantics.
> I'll agree to that.
>
> * Content metadata firmly removed from transport metadata.
>
> * Length of metadata sections part of initial fixed-length header.
>
> * Option for specifying preliminary metadata in front of content and
>    update it to final values after content.  This allows a server to
>    Say this looks like "200=OK, 1Mbyte long, text/html, but hold on..."
>    then send the object and update with "I was wrong, it was only 800k.",
>    "Ohh, and btw, it expires in 4 seconds", "my disk failed, sorry: 206".

that will make life really hard for intermediaries.  When can you write 
your cache index information, if information will be countermanded.

>
> And to that you can add gzipping the entire connection, headers included
> (jpegs can be zip'ed at level zero to not waste time).
>
> And obviously, a sensible handling of crypto, that allows tunneling
> through gateways, load-balancers etc, unto final decrypting host.

I would argue to deprecate tunnelling.

yes deprecate.

It's a major nightmare to lock down.  Crypto should be done with the 
knowledge of the intermediary.

the requirement for scanning content for malware at a gateway is not 
going away, it's getting bigger.

So, I would propose

a) support for SSL/TLS connections to the proxy
b) support for directing the proxy to make an upstream SSL/TLS 
connection, e.g.

GET https://www.wingate.com/secure/ HTTP/x.x

Adrien

>
> ... and so on.
>
> But rather that sit and design it here, lets do a call for proposals
> and see who can come up with the best and simplest ideas.
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Wednesday, 25 January 2012 19:43:22 UTC