- From: <Ed_Batutis/CAM/Lotus@crd.lotus.com>
- Date: Fri, 3 Jan 1997 11:33:32 -0400
- To: www-international@www10.w3.org
To: www-international@www10.w3.org cc: From: Ed Batutis/CAM/Lotus @ LOTUS@MTA Date: 01/03/97 11:33:32 AM mduerst wrote: >> 5) Send an Accept-Charset on the POST >Either you mean send Accept-Charset in the FORM, or you have forgotten something. > >The I18N HTML spec proposes that an attribute Accept-Charset be used >on textual input fields of forms. > >The main case where this could be used is where the server sends >out the document in a well-known encoding (for efficiency reasons), >but expects the FORM answer to come back as UTF-8 (because a single encoding is easier to deal with). > >In the long run, UTF-8 is the encoding of choice for (short) form submissions. > >Regards, Martin. Maybe I misunderstood what someone from a major vendor suggested to me offline. I understood them to say that they were considering sending an Accept-charset from the client to the server at POST time in the HTTP header, essentially saying "please accept the data in this character encoding". Maybe I'm misunderstanding it however. It seems workable in theory, but not compatible with any other ideas that have been discussed. In any case, I think the best idea is to move away from x-www-form-urlencoded as quickly as possible, patching it up with a "hidden charset field" in the near term. Using application/form-data seems like the best way. What implementations support form-data? Who has plans to do so? =Ed Batutis ebatutis@lotus.com
Received on Friday, 3 January 1997 11:33:26 UTC