From : Yoav Nir < : Yoav Nir < ynir.ietf@gmail.com



Cc : HTTP Working Group < : HTTP Working Group < ietf-http-wg@w3.org

Message-Id : <B5F8AB8E-6AE0-47A8-9563-471827297D9A@gmail.com>

To : Poul-Henning Kamp < : Poul-Henning Kamp < phk@phk.freebsd.dk



On May 26, 2014, at 9:34 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > Wouldn't it be faster to go straight after the real goal, an > protocol which CAN replace HTTP/1.1 in all scenarios and be > an improvement in ALL scenarios ? Hi I think that would be a fool’s errand. If SPDY has shown us anything, it is that HTTP/1.1 was not optimized for the web(*). Neither SPDY nor HTTP/2 provide much advantage to the numerous other uses that have cropped up for HTTP: file transfer, web services, streaming media. In the old days we had different protocols for different use cases. We had FTP and SSH and various protocols for RPC. Placing all our networking needs over HTTP was driven by the ubiquitous availability of HTTP stacks, and the need to circumvent firewalls. I don’t believe a single protocol can be optimal in all scenarios. So I believe we should work on the one where the pain is most obvious - the web - and avoid trying to solve everybody else’s problem. If HTTP/1.1 is not optimal for downloading 4 GB OS updates, let them create their own successor to HTTP/1.1, or use FTP, or use HTTP/2 even though it’s not optimal, just like they do today. You can’t optimize for everything at once. Yoav (*) I’m using “web” here in the narrow sense that involves a user and a browser, not an application that uses a web service to guess my location and get a weather report in JSON so it can display a picture of some flowers in the rain as a background for my phone.