Hi Vincent HTTP spec defines two types of encoding: HTTP element encoding & content encoding. HTTP elements such as request line, status line, request/response headers must be hard-coded in US-ASCII. Request/response content encoding is not hard-coded and can be specified by the HTTP agent by providing a content type header:
"Content-Type: text/plain; charset=UTF-8" Per default ISO-8859-1 is used if either Content-Type header or charset clause is missing. HttpConstants class defines several constants that may prove of help for you HttpConstants#HTTP_ELEMENT_CHARSET - HTTP element encoding HttpConstants#DEFAULT_CONTENT_CHARSET - Default content encoding I hope this helps Cheers Oleg On Wed, 2003-02-19 at 13:37, Vincent Massol wrote: > Hi, > > In Cactus land (which uses HttpClient), I have received a bug report for > supporting different encodings > (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17077). Up until now, > Cactus was using the default platform encoding for reading data from > streams. However, the bug reporter (Neal) who is developing on z/OS told > me that all the HttpClient code is using a "hardcoded" encoding of ASCII > (I guess 8859-1). > > I now need to modify Cactus so that Cactus plays ball with HttpClient. I > have 2 questions: > > 1/ Is it possible in HttpClient for the user to choose which encoding to > use? > 2/ Is there a HttpClient API I can query from Cactus to know which > encoding is being used by HttpClient? > > Thanks > -Vincent > > > --------------------------------------------------------------------- > 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]
