Are Your CGIs Ready For HTTP 1.1 CONTENT_TYPE?

Friday July 30th, 1999

Eric Krock of Netscape has a second piece of news to pass along:

"The HTTP 1.0 CONTENT_TYPE line looked like this:

Content-Type: application/x-www-form-urlencoded

The HTTP 1.1 CONTENT_TYPE line looks like this:

Content-Type: application/x-www-form-urlencoded; charset=ISO-8859-1

In the interest of being standards-compliant and supporting multiple languages, Navigator 5 will support this feature of HTTP 1.1. Improperly designed CGI scripts that aren't forward-compatible with this change to the HTTP protocol will need to be fixed to support HTTP 1.1. Make sure your CGI scripts are ready for the HTTP 1.1 CONTENT_TYPE header. Read this new View Source article to find out how!"

#7 Charsets of Query Strings

by Anon

Sunday August 1st, 1999 3:52 AM

You are replying to this message

I once messed around with IE4 beta and read a bit about UTF-8 in URLs (not just the query string). This is what I've learned:

The problem is, that UTF-8 is incompatible with the old encoding wich said convert everything (8bit) to %xx (not regarding the charset!). For 7bit chars this is ok, and old style and new style encoding are jsut the same. This is of course not true for "real" 8bit chars or unicode chars. Eg. every umlaut of latin1 becomes a two byte char in UTF-8.

The suggested way to handle this problem, was to let the server check if the URL is valid UTF-8 (can be done, semi-heuristically) and then check the local filesystem for the resource being UTF-8 encoding and, if it was not found, being encoded in the old style.

So, much for new standards and backward compatibility.

Masi (<>)