Sounds good. But making HTTP faster is somewhat less of a concern to
me than making it easier to make it more robust. And the big problem
in all these schemes has been how to detect that there is a speedier
option and WHICH ONE TO CHOOSE.
Anyone can make a 'negotiation' mechanism that allows you to choose
between existing HTTP and their scheme du jour. Thats not really
architecture in my view, you have to solve for the rather more general
case without having code of this type
if (token1 = frobble)
protocol = speedy
elseif (token2 = magicQ)
protocol= m12
elseif (token3 = ei3ir)
protocol = jeie
else
protocol = http
This approach works only so long as you have code to support. It tends
to assume we are surfing not web servicing.
We have this SRV header that has some really useful mechanism to help
provide reliable service. As a side benefit it also allows us to avoid
the need to always use port 80. That could be an important factor in
conserving IPv4 addresses
We need a general purpose signalling mechanism that is DNS based and
applicable to any protocol negotiation of this sort.
On Thu, Nov 12, 2009 at 4:24 PM, Mark Nottingham <mnot(_at_)mnot(_dot_)net>
wrote:
Chromium has been experimenting with speeding up HTTP using a new protocol,
SPDY.
See:
http://blog.chromium.org/2009/11/2x-faster-web.html
http://dev.chromium.org/spdy/spdy-whitepaper
My (personal) take:
http://www.mnot.net/blog/2009/11/13/flip
Interesting times.
Cheers,
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
--
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf