Re: Rechartering HTTPbis

On 26.01.2012 08:42, Adrien de Croy wrote:
> On 26/01/2012 5:10 a.m., Poul-Henning Kamp wrote:
>> In message, 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).

So how would compression type be embeded in the request-line in a way 
not to break HTTP/1.1 servers receiving it?
or were you thinking mandating a gzip wrapper inside each chunk right 
after the chunk intro?
Seems to me this re-introduces the problem SPDY has with sending 
compressed data straight to existing HTTP/1.1 servers.

>>
>> 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.

I've been wondering about the logistics and benefits of deprecating 
CONNECT style tunnels into Upgrade: header style tunnels. The 
requirement that the protocol being upgraded to be a known registered 
one middleware gets the option to permit or deny based on its own parser 
support and/or configuration settings.
No more of this blind pushing bytes for secure IMAP over port 443 
business, unless the middleware/admin has authorised it to be so.

>
> 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
>

+1.

AYJ

Received on Wednesday, 25 January 2012 22:54:10 UTC