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
Lack of Internationalisation in HTTP Authentication | wayland's Computer Stuff

Lack of Internationalisation in HTTP Authentication

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.

Lack of internationalisation has caused problems in HTTP Authentication. This article discusses how to work around that.

The Problem

The problem is that ASCII seems to be the only character set that works universally with HTTP Authentication. Internet Explorer seems to use ISO-8859-1 and Windows-1252. Firefox seems to use UTF-8 and Windows-1252, and Opera seems to use UTF-8 universally.

The Solution

Short-term: use ASCII

Fairly self-explanatory, really. This is the soft option.

Short-term: Make the server interpretation browser-dependant

Not a wonderful idea, but better than nothing. To implement something like this, you'll need to know what the different browsers do. Fortunately, Mr. Bjoern Hoehrmann has already done some investgation of which browsers support which character set.

Medium-term: Change the software to support RFC 2047

RFC 2047, MIME Part Three: Message Header Extensions for Non-ASCII Text specifies how UTF-8 should be encoded in headers. When the software actually supports this, it will be wonderful. This also isn't a wonderful long-term solution, because it assumes that the web is basically iso-8859-1; see Mr. Martin J. Düerst's post.

Long-term: Change the RFC

You're probably familiar with the solution by now; change the RFC to explicitly mandate that encoding be supported for HTTP Authentication. There was discussion of this in September and October 2006 which can be found in the IETF HTTP Auth Archives.