You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@apache.org> on 2008/08/19 18:17:18 UTC

Re: request encoding conundrum

Hi Grzegorz,

Sorry for the delay, but I finally got to look at the Upload Sample in  
CForms.
The simple one, without the progress bar does seem to work in my local  
copy of 2.1.12-dev that I am working on.

I tried the sample string below and it came through correctly.

Does switching ajax on or off make any difference on your setup?

Sorry I could not reproduce your problem :-/

regards Jeremy


On 27 Jul 2008, at 18:51, Grzegorz Kossakowski wrote:

>>>
>>> I've tested it (combined with fix from COCOON-1917) and on the  
>>> server side everything looks correct now.
>> Great !!!
>>> The only problem is that browser sometimes does not behave  
>>> correctly.
>>>
>>> I noticed that sometimes when I enter non-latin characters to the  
>>> text field they get escaped by a browser.
>>>
>>> So when I enter something like:
>>> światło
>>>
>>> the browser posts to the server such value:
>>> &#347;wiat&#322;o
>> Yes, I see this a lot.
>> I also see UTF-8 encoding like this : %E2%82%AC (which is the 3  
>> byte encoding for the Euro symbol).
>> I have not found this encoding to be a problem.
>
> I thought that browser should never escape characters if it's not  
> absolutely necessary. If browser was submitting the data using UTF-8  
> then that wouldn't be necessary right?
>
>> What problem does this cause you?
>
> Our samples are simply broken that's the problem :-)
> If you try to use this upload sample I've already pointed you to  
> then you will see that result page produced after forms is submitted  
> contains escaped characters.
>
>>> (additionally there is parameter: dojo.transport=xmlhttp)
>> This is one of the standard parameters that CForms has to add to  
>> form submits.
>> CForms uses 3 different transports, depending on context:
>> 1) ajax-off : normal whole page submit
>> 2) ajax-on  : xmlhttp
>> 3) ajax-on + form contains a 'file' field : iframe-transport
>> Unfortunately, the response to each of these needs to be serialized  
>> differently, hence the need to a very complicated sitemap for  
>> cforms and this special parameter.
>
> I see. Still I don't understand why our samples are broken.
>
>>> Since I don't know how these things are handled on the client side  
>>> I'm not sure how to fix it.
>>>
>>> Any ideas?
>> I need more details of what problem it causes ....
>
> I hope you can reproduce it with upload sample we have in Cocoon.