HTTP Future Features
I have no idea what’s in store for HTTP 1.2 and beyond, or if there’s even any work being done on it. But here’s one feature I’d like to see.
In general, an HTTP request is made to be secure or non-secure by the scheme used in the URL sent by the user agent (https: or http:, respectively). However, this puts a burden on the developer of the website (usually a webapp) to ensure that URLs get written correctly.
This is a consequence of the use of SSL for HTTP security. SSL happens at a protocol layer below that of HTTP. The secure connection is established first, then the HTTP protocol is layered on top of that. By the time the server gets a chance to determine what resource is being requested, the SSL connection must have already been established.
It makes much more sense for an HTTP request to be made, and if the server determines that the requested resource is secure, that the connection then become secure. In other words, the requested resource should be able to dictate whether or not it needs to be secure.
This means we need a way to transparently make secure a connection that began unsecure.
There are complications with this, of course. Many times, information needs to be sent as part of the request in a secure fashion (your login and password information, for example). A way to handle this needs to be devised, of course.
Even the specific URL might need to be secure. That’s what HTTP currently does. The only thing you can’t keep from prying eyes is the IP address and port to which the request is being sent.
There are ways to mimic this behavior. For example, an unsecure request to a secure resource can cause a secure redirect. But redirects cause problems in the user agents, most notably involving the back button.
Okay, that’s all I can write for now, but I’ll try to get back to this subject later&hellpi;