- From: Erik van der Poel <erik@netscape.com>
- Date: Sun, 31 May 1998 08:33:03 -0700
- To: Dan Kegel <dank@alumni.caltech.edu>
- Cc: MURATA Makoto <murata@apsdc.ksp.fujixerox.co.jp>, Harald Alvestrand <Harald.Alvestrand@maxware.no>, Chris Newman <Chris.Newman@INNOSOFT.COM>, "Martin J. Duerst" <duerst@w3.org>, ietf-charsets@ISI.EDU, murata@fxis.fujixerox.co.jp, Tatsuo_Kobayashi@justsystem.co.jp
Dan Kegel wrote: > > In the case of HTTP headers, we can probably consider the > entire HTTP header stream as a single message, and only require > the BOM at the beginning of the stream, e.g. the client and server > would each send the BOM as the first two bytes after opening the > socket. No, HTTP headers are always encoded with one octet per character, even if the body is UCS-2 or UCS-4 (or UTF-16). You would have interoperability problems if you tried to send the headers themselves in UTF-16. A client could only send UTF-16 headers if it knew beforehand that the server could deal with it. For example, if the link that the user clicked on had an HREF with "whttp://...", where "whttp" is some new protocol that accepts UTF-16, then the client could safely send UTF-16 headers. (Note: I'm not proposing to create a new protocol called whttp. I'm just saying that the current HTTP cannot deal with UTF-16 headers.) Erik --Boundary (ID uEbHHWxWEwCKT9wM3evJ5w)
Received on Sunday, 31 May 1998 08:39:04 UTC