Re: Rechartering HTTPbis

On Thu, Jan 26, 2012 at 11:53:45AM +1300, Amos Jeffries wrote:
> 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

+2, I would even like to see this as a proposed addition to 1.1. Technically
speaking, nothing prevents this, we just have to define how the proxy must
act upon various issues (eg: invalid certificate, etc...). As it was already
pointed by someone here, there's no place for this in the current draft since
it's not used today, but it would be a cheap and very useful extension.

Willy

Received on Wednesday, 25 January 2012 23:14:34 UTC