Wire logging revised (attempt 3). Patch committed

I admit this patch is nothing to be extremely proud of, but since it's been hanging in the mailing list for quite a while and there have been no massive protests, I assume it is more or less OK with everyone. Jeff, - Checked copywrite clause. It looks all right to me. - Odi's name should not hav

[PATCH]: Wire logging revised (attempt 2)

Another attempt at cleaning up wire logging in HttpClient based on Jandalf's and Mike's input. I can't say the solution is perfect, but it'd like to hope it'd be a step forward compared to what we have today Cheers Oleg >Haven't had time to review all of this, but I am a bit concerned over >a

Re:AW: MultipartPostMethod

Thomas That would cause the total Content-Length to be miscalculated. Actually, any sane cgi script or servlet *should* ignore Content-Length when parsing multipart/form-data request body. But you never know what side-effects an invalid Content-Length value might cause. So, proceed with caution.

Re:MultipartPostMethod

Thomas Unfortunately it is not possible. The framework is there, though. One only needs to create a class that implements PartSource interface Oleg >I want to create a multipart post with an InputStream instead of a File. >Is that possible? > >Thomas > >--

Re: The use of UTIUtil.toUsingCharset?

>That's the crux of the matter right there. What the >target.getBytes(fromCharset) does is ask the original "target" Unicode >String (presumably containing % escapes) to convert itself to its byte >representation in the original charset. Then "new String(..., >toCharset) creates a new Unicod

Re:HttpMethodBase::ParseResponseHeaders handling of cookies

James, Your patch with some minor tweaks has been applied. I'd like to thank you one more time for having reported the problem and contributing the patch. Please do not hesitate to let me know if you see any other problems related to cookie management in HttpClient Kind regards Oleg >Hello Al

RE: POST to IIS/5.0 responses

Jim Check out the TCPMON tool of Apache Axis project It's been frequently recommended on this mailing list for capturing HTTP traffic http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/docs/user-guide.html#tcpmon http://ws.apache.org/axis/ http://ws.apache.org/axis/dist/1_0/ Please l

RE: POST to IIS/5.0 responses

My pleasure, Jim To help us understand what has been causing the problem in the first place we need to be able to reproduce it in a controlled environment, or simply put, we need to be able to analyze the incoming and outgoing HTTP packets. Being able to hit the problem server is one solution,

Re:EntityEnclosingMethod, 100-continue and 401 Unauthorized

Rob, I think I fixed the problem by making the EntityEnclosingMethod class check for the Expect header and remove it if it is not supposed to be there Could you please take the newest CVS snapshot for a spin and let ke know if the problem persists Cheers Oleg >The new EntityEnclosingMethod i

Re:POST to IIS/5.0 responses

Hi Jim, There's something wrong with chunk-encoded response coming from IIS. It's a bit odd that you seem to be the first person running into this kind of problem. As a quite work-around I can suggest falling back onto HTTP/1.0 protocol, which does not support chunk-encoding. mymethod.setHttp

One more time: UTIUtil.toUsingCharset

Hi Sung-Gu Please take no offense in my posts. I have never questioned sanity of URIUtil.encodeWithinQuery, however, I still have doubts about sanity of UTIUtil.toUsingCharset method. And the fact that you have been ignoring my and Odi's requests to provide a unit test for that method does not r

Re: POST method - Default content encoding

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

Re: POST method - Default content encoding

Odi, GET is an entirely different ball game. RFC is quite explicit about it: it's US-ASCII all over the place, except for 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 e

Re: POST method - Default content encoding

RFC 2616 does not seem to say much. So, I assume that the default scheme applies: whatever charset is specified in "Content-Type" header. If charset is not explicitly set, ISO-8859-1 is used per default. Do you see it differently? Cheers Oleg -

Re: POST method - Default content encoding

Aha, it just hit me. Post parameters are url encoded, so all umlauts get escaped. If you send as a parameter value something like that: "Grüezi, Herr Thomas" You gonna get this: "Gr%C3%BCezi%2C%20Herr%20Thomas" I hope you are aware of that Oleg --

Re:AW: POST method - Default content encoding

Mathis, I have double-checked the code and so far I have got no reason to assume it produces errnous results. I have run a simple echo test against HttpClient test web application. All Umlauts appear to be doing fine there. I do not know the inner working of the CGI application you are using to

Re: POST method - Default content encoding

The encoding bug in entity enclosing methods (such as POST) has been fixed right after 2.0 alpha2 release. The problem should go away with the most recent CVS snapshot. Give it a shot Cheers Oleg >Is that fixed now? >I tested this issue with HttpClient 2.0 alpha2 and the result was the same

Re: The use of UTIUtil.toUsingCharset?

Sung-Gu Please take no offense, but URIUtil.toUsingCharset method still does not make even slightest sense to me. Your example shows how to invoke this method but does not explain what it is useful for, apart from garbling unicode strings Have a look at a simpler example. Here I attempt to (s