Weblog
I read an interesting article at Slashdot about HTTP/2.
As you can read in earlier posts, I don't like SPDY. It's a protocol by Google, for Google. Unless you are doing the same as Google, you won't benefit much from it. The main reason SPDY was taken as a base for HTTP/2 is because the W3C was too indolent to do its job. Many things that are wrong with HTTP/1.x are not solved in HTTP/2. Specially all the things that make a webserver unnecessarily complex.
For example, the feature called pathinfo. URL's are still ugly and it requires the webserver to search for the actual CGI script. A better solution is URL rewriting, but using regular expressions for it is also not very efficient. Many CMS's and frameworks require a long list of rewrite rules while they should all be replaced with three simple rules:
- If the file exists, serve it.
- Does the URL start with a specific part, for example /images, /css or /js, then return a 404.
- Use a specific URL instead, like /index.php, /default.aspx or /index.py.
These simple rules allow you to use clean URL's and are very easy and fast to implement.
I know HTTP was meant to be stateless, but all webbrowsers use a separate connection for every website. Even if those websites are served by the same webserver. Therefor, a lot of the same HTTP headers are sent over and over again. This can be improved. Also, why send a separate request for every file? Why not let the browser specify a list of files which the server can then send in one stream?
We have CGI, FastCGI, SCGI, WSGI, etc, all doing the same thing. Why not choose one as standard and drop the others?
Take a look at all the modules available for Apache. The amount of crap that many web developers want to put in their web application are not going to be fixed by SPDY. The only reason Hiawatha offers reverse proxy functionality is because several web application developers thought it was a good idea to make their application speak HTTP instead of (Fast)CGI and users wanted to run that shit with Hiawatha. You want things to be faster? Start by making things more simple.
Anyway, I think we don't need a new protocol like SPDY. What we need is HTTP/1.2 in which the unnecessary junk is removed, the gaps are filled and things are made more easy.
Built upon the Banshee PHP framework.
It is the facebook principle taken over to technology: The customer is the product.
Thanks Hugo, for pointing out the SPDY shit.
1. HTTP/2.0 and SPDY exist because egos are involved. Whether or not the previous specification is adequate and/or intelligently used, someone is going to step up with complexity-adding "improvements".
2. These evolutions raise new privacy challenges, including but not limited to a connection that closes when the user leaves a web page. I have to wonder also (and simply don't know) if TLS will facilitate new kinds of tracking.
3. In light of last week's announcements about the discrete logarithm problem, I am naturally skeptical of all asymmetric cryptography. Actually, I always was. Mandating a cipher that is about to be broken is foolhardy.
4. Supporting many evolutions and experiments is contributing to permanent browser bloat, like all the HTML dialects have done and continue to do.
5. Hiawatha is stable, mature code. HTTP/2.0 and SPDY are in a relatively weak position. In your place I would retain and capitalize on my strong position, and not follow the HTTP/2.0 and SPDY roller coaster. Wait to implement either until either (a) you absolutely have to, or (b) when you have the time and resources to do it right. Let other projects make the mistakes and shake the bugs out. It's up to you whether or not you want to be in this niche.
6. Standardization is not the final say. You're an implementer, and there also are users and site administrators. We all get a vote in this. Use yours in the best interests of the web.
Marc
Andreas