Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Subject: Re: POST method - Default content encoding
From: Oleg Kalnichevski <o.kalnichevski@dplanet.ch>
To: Commons HttpClient Project <commons-httpclient-dev@jakarta.apache.org>
Cc: mathis@vtg.at
In-Reply-To: <318499930.1044297666937.JavaMail.luser@dubb11h05-0.dplanet.ch>
References: <318499930.1044297666937.JavaMail.luser@dubb11h05-0.dplanet.ch>
Content-Type: text/plain; charset=ISO-8859-1
Organization: 
Message-Id: <1044307578.4039.73.camel@kczrh-okt22.corp.bearingpoint.com>
Mime-Version: 1.0
Date: 03 Feb 2003 22:26:19 +0100
Content-Transfer-Encoding: 8bit

Patch applied.
Thomas, please let me know if that fixes the problem for you

Cheers

Oleg 
PS: my apologies for mixing up your first and last name

On Mon, 2003-02-03 at 19:41, o.kalnichevski@dplanet.ch wrote:
> 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.
> >
> >o.kalnichevski@dplanet.ch 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>