HTTP 1.2 -- What it needs
HTTP 1.2 needs a number of things to make the web better. This article discusses some of them.
Table of Contents
Better DNS Usage
HTTP would be better if HTTP used SRV records. This would allow for better load balancing, and would mean that it would be possible to just use domains for the web as well as e-mail. For instance, example.com at the moment would probably use user@example.com as their e-mail, and www.example.com as their website. With SRV records, it's possible to just use example.com for all these things. You can read more about SRV records at:
- Wikipedia's SRV record page
- Rick van Rein's page Take a minute to improve the Internet!
HTTP would also be better if IPv6 support were mandated. IPv6, in spite of its slow deployment to date, is expected to become quite common sometime between 2010 and 2012.
Better HTTP Authentication
HTTP 1.2 needs better built-in authentication. This is covered in a series, the main article of which is HTTP Authentication: Solutions and Futures, so I won't rehash all of that here. I will, however, summarise the changes that need to be made to the RFC:
Better support for optional HTTP Authentication
I quote Mr. Charles Miller, in his article Saving HTTP Authentication. He suggests that the section on the WWW-Authenticate header include the following text:
On receiving a WWW-Authenticate header with a 2xx response, any user-agent that has credentials cached for the realm SHOULD repeat the request, including those credentials. If the user-agent has no credentials cached for the given realm, it SHOULD NOT interrupt the delivery of the response to the user, but MAY provide some indication that the page accepts authentication, and some mechanism to enter credentials.
As in RFC2617, the user-agent MAY preemptively send the same credentials for any resource located at a URI beneath the one at which the WWW-Authenticate header was received.
Support for better user interface in HTTP Authentication
I'm unsure whether the more secure improvement should be chosen or the more flexible, but HTTP Authentication User Interface documents both solutions.
Support adequate logout facilities
There are a number of things needed to support adequate logout facilities (documented in Inadequate Logout functionality in HTTP Authentication). As far as changes to the HTTP standard, in addition to those mentioned in the section above, I also mention the idea of a timeout being sent from the server to the client; I quote again Mr. Charles Miller's Saving HTTP Authentication:I'd also recommend the additional text:
User agents must support a facility to log out at the user's command, such as a "Log out" button.
Digest Wildcards
Digest authentication supports the submission of multiple domains. Digest wildcards (such as *.blogs.example.com, which matches john.blogs.example.com and fred.blogs.example.com) should be added as an optional facility. Naturally, these should fall under the same restrictions as cookie wildcards. Support for this should be added to the appropriate RFC.
Better support for internationalisation
The consensus on the IETF HTTP Authentication mailing list seemed to be that UTF-8 should be used, but there was no consensus at the time to update the appropriate RFC. Hopefully this problem will be included as something to be updated in HTTP 1.2.Possibly Extensibility
The Wikipedia article on HTTP points out that there was a brief attempt at HTTP 1.2. This attempted to add an extension mechanism to HTTP. This is documented in RFC 2774. This was never adopted as an official internet standard because, to quote the RFC, "there is a more general concern about whether this document actually represents community consensus regarding the evolution of HTTP. Additional study and discussion are needed before this can be determined." Unfortuantely I've been unable to find any information as to whether additional study and discussion occured, and what it brought about. But the idea is worth revisiting.
- wayland's blog
- Login or register to post comments
- Printer-friendly version
Delicious
Digg
StumbleUpon
Propeller
Reddit
Magnoliacom
Newsvine
Furl
Facebook
Google
Yahoo
Technorati
Icerocket