I was looking at some traffic differences between one of
my browsers going through squid and going direct (via masquerade).
The protocol usage in the 2nd case used 'http2' -- which started me
wondering what the heck that was...so googled around and
found it is an optimized http/1.1 mostly meant for packing
a website and streaming the whole thing as a byte-stream
to the client.
Interestingly, a few things are starting to support it:
nginx, chrome, MS(w/partial support), later firefox
versions... and several others.
In the http2-working (ietf) group, webpage loading
was about 50% faster (obviously depending on number
of items). Supposedly it has to be 'encrypted' w/
TLS2, BUT I see nothing in spec that requires that.
Notably google was talking about http2 support on
their website, and the availability of businesses
with web-proxys to request that their clients not
use the bump to TLS2, but still allow the main
things that speed things up -- appending multiple
web items in 1 binary stream and using both
header and body compression.
I could see several ways/levels of squid supporting
this, but looking through my local mail archives,
I didn't see 'http2' mentioned once --either
on the users or the dev list and this complete
lack of its mention is leading me to think of the
that there is no ongoing work for it or future
plans at this point?
I think it is partly being supported through the current
squid by encapsulating a http2 session in a
http1.1 "tunnel" -- which raises some problems.
All the kinks aren't worked out yet, but
Proxy-Users scenarios are shown at:
https://github.com/http2/http2-spec/wiki/Proxy-User-Stories
Are the impacts or implementation details
being thought about in squid?, since if it comes
down to it only being supported by encrypted
TUNNELS, its not only going to be hard to cache,
but also makes it a pain to implement http/browsing
controls on content -- since it would all
be encrypted and and compressed and impossible
to directly use in companies that need to filter
web-content as it comes in.
A bit concerned...
linda
(p.s. -- also sent to "-dev" group, but directed replies
to the user group -- feel free to reply as wanted, if
you feel it is needed, but didn't want to overload
dev list with something they may not be working on
yet and would just waste reading and 'discussion'
bandwidth)
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users