Mike,
It looks like out recent patch is still not quite correct in handling multiple
transfer encodings. I have re-read the relevant sections of the RFC 2616 on this issue
and found out the following:
Multiple transfer encodings are not supposed to be declared in separate
'Transfer-Encoding'
When I use the GetMethod class to send text with special characters (German
Umlaute äöü) in the request parameters, the special characters are not
encoded correctly. This happens when I use method
HttpMethodBase.setQueryString(NameValuePair[] params)
to set the query parameters.
I saw that
14.41 Transfer-Encoding
...
Transfer-Encoding = Transfer-Encoding : 1#transfer-coding
...
2.1 Augmented BNF
...
#rule
A construct # is defined, similar to *, for defining lists of
elements. The full form is n#melement indicating at least
n and at most m elements, each
Hello Martin,
This is a good question, one that I am not positive I know the answer
to. The HTTP request line (containing the query params) must be
US-ASCII. That I am sure of. The catch is that form urlencoding
strings makes them ASCII, regardless of the original charset. So
we have a situation where our connections just aren't closing
HttpMethodBase.ensureConnectionRelease() is getting called
however when it calls
responseConnection.releaseConnection();
the httpConnectionManager refered to inthat manager is == null and thus the
method only serves to set used = true;
Hello from Boston Kate!
In general, HttpMethodBase and the two connection managers try to reuse
connections as much as possible. This is purely for performance
purposes. Part of the HTTP spec defines when connections should be left
open and when they should be closed (see
Why is this the case? I have no idea. Anyone else has some thoughts on
this one?
Sung-Gu, maybe?
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This is one of many 'shady' areas of the HTTP spec. Basically there is
no standard way for the client to communicate to the server what coding
has been used to decode query parameters. I believe some browsers use
'Accept-charset or 'Accept-Language' headers to negotiate the locale
settings to be
Hello,
I am using the latest (downloaded early this week)
commons-httpclient-2.0-beta2.jar
Works fine with http.
I am trying to make a https connection thru a proxy.
I am getting the following exception:
java.net.SocketException: Socket closed
at
I am a bit doubtful that the bug fix #20938 had anything to do with your
problem. Anyway, it can get the most recent nightly build at the
following location
http://cvs.apache.org/builds/jakarta-commons/nightly/commons-httpclient/
If the problem persists after upgrade, please refer to the
Hello,
I just downloaded commons-httpclient to test HTTP postXML example. When
I run the client I get the following, it seems to be pretty common.
Exception in thread main
org.apache.commons.httpclient.HttpRecoverableExceptio
n: java.net.SocketException: Software caused connection abort: recv
The patch for 20938 should have been included in beta 2.
Mike
Oleg Kalnichevski wrote:
I am a bit doubtful that the bug fix #20938 had anything to do with your
problem. Anyway, it can get the most recent nightly build at the
following location
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Yevgeni,
It is really hard to tell what is going on here. It can well be a
problem on the server side. What HTTP server are you targeting? You may
also want to consult the trouble-shooting for instructions on further
actions
http://jakarta.apache.org/commons/httpclient/troubleshooting.html
Hi Mike, Oleg
Thanks for the response.
Though I have the latest build, I am still getting the
socket closed exception.
I guess I am missing something in the funda.
Here is my code:
// SET SYS PROP FOR HTTPCLIENT DEBUG
Oleg Kalnichevski wrote:
This is one of many 'shady' areas of the HTTP spec. Basically there is
no standard way for the client to communicate to the server what coding
has been used to decode query parameters.
It's definitely shady. I've seen two approaches used here. In the
past, many
I think I have another idea. If you use 'Basic' authentication scheme on
the proxy, try using preemptive proxy authentication.
Oleg
On Thu, 2003-07-10 at 21:32, Ramanan nr wrote:
Hi Mike, Oleg
Thanks for the response.
Though I have the latest build, I am still getting the
socket closed
Oleg,
I am executing the code against a valid url.
I am fine with the 404 error, as I know the target
server will thru a 404 if I request the info using
http. I just tried this to see if there is a problem
with my proxy.
As expected, http goes thru fine. The problem is when
I do a https.
I
Hi Oleg,
Tried with preemptive proxy authentication, still the
same exception.
-
NRR
--- Oleg Kalnichevski [EMAIL PROTECTED] wrote:
I think I have another idea. If you use 'Basic'
authentication scheme on
the proxy, try using preemptive proxy
authentication.
Oleg
On Thu, 2003-07-10
My understanding is that HTTP URLs do not include user info and thus
that data should be stripped (or probably an exception should be thrown
if we're being strict about it). FTP URLs on the other hand do.
Having said that, there's no harm in preserving the user credentials so
that they can
On Thursday, July 10, 2003, at 04:01 PM, Ramanan nr wrote:
btw, though I set the wire log to the debug mode, I
don't see any info. is there any other setting other
than the
org.apache.commons.logging.simplelog.log.httpclient.wire
=debug
My guess is that you are using Log4j (have it on your
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
That's quite a handy reference. Thank you for the info Laura.
Mike
On Thursday, July 10, 2003, at 03:35 PM, Laura Werner wrote:
Oleg Kalnichevski wrote:
This is one of many 'shady' areas of the HTTP spec. Basically there is
no standard way for the client to communicate to the server what
23 matches
Mail list logo
