Oleg Kalnichevski wrote:
Some of the stuff now in encodingUtil is dependent on HttpClient
NameValuePair etc. and seems specifically for managing the
encoding/building of query strings.
The ASCII stuff is just dependent in that it throws HttpclientError's
I suspect the later will be usefull to
> Some of the stuff now in encodingUtil is dependent on HttpClient
> NameValuePair etc. and seems specifically for managing the
> encoding/building of query strings.
>
> The ASCII stuff is just dependent in that it throws HttpclientError's
>
> I suspect the later will be usefull to move out, wh
Another feature of interest is the ContentType class in contributions, I
suspect this should be more dependent on some general mimetype
resolution functionality possibly via JAF or some comparable standard
mimetype mapping library. This is something I'm researching as well for
codec or lang (or
Lol, I was trying to catch up with you...
Some of the stuff now in encodingUtil is dependent on HttpClient
NameValuePair etc. and seems specifically for managing the
encoding/building of query strings.
The ASCII stuff is just dependent in that it throws HttpclientError's
I suspect the later wi
Mark,
Ironically, I just responded to your message on the commons-dev mailing
list. I do think that EncodingUtil would fit quite well in codec
Cheers,
Oleg
On Tue, 2004-01-13 at 20:19, Mark R. Diggory wrote:
> Hey Guys, I didn't realize you were already doing this,
>
> http://nagoya.apache.org/
Hey Guys, I didn't realize you were already doing this,
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25431
I should pay more attention to the bugzilla. I posted a message eariler
today approaching the issues of HttpConstants encoding methods and there
usefullness outside of HttpClient on t
