The browser vendors need to catch up with the rest of the devices and applications out there which speak fluent HTTP 1.1
I should clarify this statement: From an internal perspective, very few web browsers don't speak fluent HTTP 1.1. They may each interpret the spec just a tad bit differently, and they've certainly been known to leave out support for critical pieces such as -- oh, I don't know, ETags for example! ;-)
Where they fall short is exposing that support at the API level in a consistent, cross browser manner.
This is just my own opinion, of course, but if the HTML5 WG /REALLY/ wanted to make a difference they'd stop trying to agree upon defining element names and definitions which can just as easily be implemented via the 'object/@type' element/attribute combination** , and instead use their time to first, come to terms with how to expose full client/server support for the HTTP 1.1 spec to the developer such that each node on the net is both a client /AND/ a server, to then establish a formalized process for introducing additional protocols into the mix that have proven to be of value to a broader swath of developers (XMPP anyone? BitTorrent? AtomPub? Kermit? ;-)) and are therefore candidates for finding their way into the toolbags of /ALL/ developers and usable by /ALL/ folks who just so happen to have a communication protocol standards compliant web browser installed on their machine.
A man can dream, can't he! ;-)
** okay, that's obviously a stretch, but what's the difference between agreeing upon a common set of
param/@name child elements and defining attribute names for a 'video' element? Answer: One less element to have to kill off in 10 years when holograms become all the rage and the video element goes the way of the blink element. ;-)