All right. We did talk about different things. Now I see the problem. Whoever initially programmed PostMethod did not take content encoding into consideration when performing URL encoding, and I blundered by failing to properly audit that bit of code.
I'll fix it right away Thanks for pinning it down for me Cheers Oleg >Let me make some definitions to ensure we are talking about the same >thing. There are two encodings envolved: > > Enc 1 Enc 2 >[unicode string] ----------> URL encoded form --------> byte[] > "�" URLEnc w/ UTF-8 %C3%B6 ASCII 0x25, 0x43 ... > "�" URLEnc w/ ISO-8859-1 %F6 ASCII 0x25, 0x46 ... > >The focus is on Enc 1 and NOT on Enc 2. > >[EMAIL PROTECTED] wrote: >> Odi, GET is an entirely different ball game. RFC is quite explicit >> about it: it's US-ASCII all over the place, except for > >Sure, it's ASCII for what actually goes over the wire (enc 2). But >wether (how's that damn word spelt??) I encode � as %C3%B6 or %F6 in the >request parameter (enc 1) is quite different and *both* versions do >completely comply with the RFC, since the RFC only specifies enc 2 and >not enc 1. Correct me if I am wrong. > >> request/response body. That's why it takes URL-encoding in the very >> first place in order to comply with the spec. Only request/response >> body may be encoded with a different encoding > >You are talking about encoding 2 here. > >> It still does not make URIUtil#toUsingCharset make any sense, as far >> as I can see. > >Of course not. I was only trying to figure out what was going on in >Sung-Gu's mind :-) > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
