load balancers aren't meant to just be "HTTP routers". they can definitely be used as such for smaller applications and do a good job at it, but a real load balancer needs to be quite complex, being able to adapt to the underlying applications that make use of it.
if your goal is to only route HTTP requests, then you're only solving the first step of an increasingly complicated field of computer science (namely, web applications).
Cookies aren't going to go away. if you want to improve the protocol to deal with cookies better, that makes sense, but acting like they are some kind of evil on the internet that should be forgotten isn't going to work. it's a bit self-defeating to argue that some protocols failed because of failure to provide new benefits and then argue against Cookies in HTTP!
load balancers aren't meant to just be "HTTP routers". they can definitely be used as such for smaller applications and do a good job at it, but a real load balancer needs to be quite complex, being able to adapt to the underlying applications that make use of it
I think Poul-Henning Kamp is fairly well qualified to discuss what load balancers do.
(And yes, load balancer are fundamentally HTTP Routers. Yes, sometimes they do content manipulation etc, but all those features are add-ons to the basic use-case)
Perhaps Kamp is qualified to discuss what some 'load-balancers' do...
The proxy developers have always had their doubts about SPDY (you can see them when @mnot first proposed it as a starting point)
Terminating SPDY at the HTTP Router makes a lot of sense architecturally but I know some orgs don't terminate SSL at the load-balancer due to the licensing costs.
Ultimately we need load-balancing options and someone to develop the opensource proxies (haproxy, varnish etc.) into more sophisticated offerings.
Perhaps they'll be a SPDY module for Traffic Server
I don't see the issue with doing away with cookies. Cookies sucks for so many reasons. A natively handled session is just fine. Oh yes, it means also you can't be easily tracked, because that's the other purpose of cookies. Well too bad. You can still track through other means.
If you wanna store stuff, there's HTML5. Cookies are really just tracking and session.
As for the router, what he says makes complete sense, but, if there is more to it, then, what are you thinking about? Personally I think the host header is the most important thing to parse, for, well, routing, termination, etc. I'm not certain what else is needed beyond that point.
Although I think he should further consider why many websites are using cookies at all or even cryptographically secure cookies, I think he makes a good point about caching and cookies. Websites with large amounts of traffic often move their static content to separate domains to avoid clients sending cookies headers on every request to static/forever-cacheable assets.
if your goal is to only route HTTP requests, then you're only solving the first step of an increasingly complicated field of computer science (namely, web applications).
Cookies aren't going to go away. if you want to improve the protocol to deal with cookies better, that makes sense, but acting like they are some kind of evil on the internet that should be forgotten isn't going to work. it's a bit self-defeating to argue that some protocols failed because of failure to provide new benefits and then argue against Cookies in HTTP!