HTTP 1.2 needs a number of things to make the web better. This article discusses some of them.

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 [9] as their e-mail, and www.example.com [10] 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 [11] page
• Rick van Rein's page Take a minute to improve the Internet! [12]

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 [13], 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 [14]. He suggests that the section on the WWW-Authenticate header include the following text:

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 [15] 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 [16]). 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 [17]:

I'd also recommend the additional text:

Digest Wildcards

Digest authentication supports the submission of multiple domains. Digest wildcards (such as *.blogs.example.com, which matches john.blogs.example.com [18] 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 [19] 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 [20]. 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.