- From: Dan Kegel <dank@alumni.caltech.edu>
- Date: Sun, 31 May 1998 09:00:08 -0700
- To: erik@netscape.com
- 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
Right, I was thinking of a hypothetical future protocol like http or smtp but based on UTF-16, not the current http or smtp. - Dan At 08:33 AM 5/31/98 -0700, Erik van der Poel wrote: >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 09:08:08 UTC