Warning: Table './jdarx_drupal/sessions' is marked as crashed and should be repaired query: SELECT u.*, s.* FROM users u INNER JOIN sessions s ON u.uid = s.uid WHERE s.sid = 'aafaa27f09a6e8a5c161b32e501e300c' in /f2/jdarx/public/includes/database.mysql.inc on line 172

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /f2/jdarx/public/includes/database.mysql.inc:172) in /f2/jdarx/public/includes/bootstrap.inc on line 899

Warning: Cannot modify header information - headers already sent by (output started at /f2/jdarx/public/includes/database.mysql.inc:172) in /f2/jdarx/public/includes/bootstrap.inc on line 531

Warning: Cannot modify header information - headers already sent by (output started at /f2/jdarx/public/includes/database.mysql.inc:172) in /f2/jdarx/public/includes/bootstrap.inc on line 532

Warning: Cannot modify header information - headers already sent by (output started at /f2/jdarx/public/includes/database.mysql.inc:172) in /f2/jdarx/public/includes/bootstrap.inc on line 533

Warning: Cannot modify header information - headers already sent by (output started at /f2/jdarx/public/includes/database.mysql.inc:172) in /f2/jdarx/public/includes/bootstrap.inc on line 534
HTTP 1.2 -- What it needs | wayland's Computer Stuff

HTTP 1.2 -- What it needs

warning: Cannot modify header information - headers already sent by (output started at /f2/jdarx/public/includes/database.mysql.inc:172) in /f2/jdarx/public/includes/common.inc on line 141.

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 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:

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:

The server MAY include a WWW-Authenticate header (as defined in RFC2617) with any successfully retrieved (2xx response code) document. This header denotes that the document was retrieved, but further information may be available if the user authenticates to the realm provided in the header.

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:

The exact definition of idleness is left to the user-agent, but is roughly defined as the amount of time since the user last interacted with a page that required authentication to that particular realm. If timeout is zero, or this field is not provided, the login is assumed to never time out.

I'd also recommend the additional text:

If the timeout is negative, then it is assumed to be immediate, and the credentials should be expired immediately.

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.