I noticed that the non-ajax forms in the CMS cause the browser to send a request without a specified charset in the "Content-Type:" header. I tried the following to try to get "charset=utf-8" part on the request:
- configure accept-charset="utf-8" on the <form> element : CHECK - configure enctype="application/x-www-form-urlencoded; charset=UTF-8" : CHECK - check if <META http-equiv="Content-Type" content="text/html; charset=UTF-8"/> is in html <head> section : CHECK - check if Content-Type: response header for the html that contains the form is set to charset = utf-8 : CHECK My browser (Firefox) just doesn't want to set the charset to utf-8 in the content-type request header! I get the feeling that the browser is not able to determine the encoding of the form (or whole page?), and then decides to send the form using ISO-8859-1. I'm out of ideas, who can help me out ? It must be some basic html thing :) Ofcourse I can fix it with a workaround: implement a filter that converts only POST parameters, if the incoming encoding is NULL or anything else than utf-8. But I'd rather like to solve the cause of the problem :) regards Dennis On Wed, Oct 7, 2009 at 2:24 PM, Dennis Dam <[email protected]> wrote: > > > On Wed, Oct 7, 2009 at 2:09 PM, Bartosz Oudekerk > <[email protected]>wrote: > >> Ard Schrijvers wrote: >> >>> 1. added system property -Dfile.encoding=UTF-8 to catalina.sh >>>> 2. added URIEncoding=utf-8 to the 8080 connector in conf/server.xml >>>> 3. the container-encoding init parameter for the Cocoon servlet is set >>>> to >>>> "ISO-8859-1". >>>> 4. the form-encoding init parameter for the Cocoon servlet is set to >>>> "utf-8" >>>> >>> >>> why is (3) not utf-8?? >>> >> >> Because if it's set to UTF-8, then things tend to get doubly encoded. >> > > > not exactly.. it depends on the value of "form-encoding", if > container-encoding + form-encoding are identical (e.g. both set to utf-8), > then Cocoon does not perform encoding conversions. > > Why is (3) not set to UTF-8?? Because then the form POST encoding is broken > :)) With ISO the form GETs are broken .. :) > > >> Regards, >> -- >> Bartosz Oudekerk >> .---------------------------------.-----------------------------------. >> | Hippo B.V. | Hippo USA Inc. | >> | Oosteinde 11 | 101 H Street, suite Q Petaluma CA | >> | 1017 WT Amsterdam | 94952-5100 San Francisco | >> | The Netherlands | United States | >> | Tel +31 (0)20 5224466 | +1 (707) 773-4646 | >> +---------------------------------+-----------------------------------+ >> | [email protected] | http://www.onehippo.com | >> >> `---------------------------------^-----------------------------------' >> ******************************************** >> Hippocms-dev: Hippo CMS development public mailinglist >> >> Searchable archives can be found at: >> MarkMail: http://hippocms-dev.markmail.org >> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html >> >> > > > -- > Hippo B.V. - Amsterdam > Oosteinde 11, 1017 WT, Amsterdam, +31(0)20-5224466 > > Hippo USA Inc. - San Francisco > 101 H Street, Suite Q, Petaluma CA, 94952-3329, +1 (707) 773-4646 > ----------------------------------------------------------------- > http://www.onehippo.com - [email protected] > ----------------------------------------------------------------- > > -- Hippo B.V. - Amsterdam Oosteinde 11, 1017 WT, Amsterdam, +31(0)20-5224466 Hippo USA Inc. - San Francisco 101 H Street, Suite Q, Petaluma CA, 94952-3329, +1 (707) 773-4646 ----------------------------------------------------------------- http://www.onehippo.com - [email protected] ----------------------------------------------------------------- ******************************************** Hippocms-dev: Hippo CMS development public mailinglist Searchable archives can be found at: MarkMail: http://hippocms-dev.markmail.org Nabble: http://www.nabble.com/Hippo-CMS-f26633.html
