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

Re: Rechartering HTTPbis

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 26 Jan 2012 11:53:45 +1300
To: <ietf-http-wg@w3.org>
Message-ID: <3242f7d9fe2f4046819ab4fcbafab251@treenet.co.nz>
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


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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC