Re: Encoding of special characters in request URI

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 codi

DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: SocketException

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 classpat

Re: Encoding of special characters in request URI

From RFC2396: For original character sequences that contain non-ASCII characters, however, the situation is more difficult. Internet protocols that transmit octet sequences intended to represent character sequences are expected to provide some way of identifying the charset used,

Re: URI class with userinfo ?

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 b

Re: SocketException : Socket closed [bug 20938]

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, 20

Re: SocketException : Socket closed [bug 20938]

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 will

Re: SocketException : Socket closed [bug 20938]

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 clo

Re: SocketException : Socket closed [bug 20938]

Wire log would definitely help. Have you tried executing your code against a valid URL? Besides, you might also want to examine proxy & target HTTP server logs. It would be very helpful to know where exactly the connection gets dropped. Cheers Oleg Well, this one should be an easy one. Status c

Re: Encoding of special characters in request URI

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 internat

Re: SocketException : Socket closed [bug 20938]

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 System.setProperty("org.apache.co

RE: Posting XML with http client

Yevgeni what I can gather from the log seems to support my assumption that something goes wrong on the server side. As far I as can tell the server fails to return any sort of status code at all, which is quite unusual. Please examine Tomcat's logs for clues as to what may have caused the problem.

RE: Posting XML with http client

Oleg, I have a tomcat server running on port 8080, through Together Control Center(just giving you the idea of what is running) I can access the server via a browser by going to http://localhost:8080/SomeServlet, this works fine. At the same time I open a command window and run Post XML example

Re: Posting XML with http client

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 Cheers

DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: SocketException : Socket closed [bug 20938]

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 http://cvs.apache.org/builds/jakarta-commons/nightly/

Posting XML with http client

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

Re: SocketException : Socket closed [bug 20938]

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 trouble-

SocketException : Socket closed [bug 20938]

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 java.net.PlainSocketImpl.socketGetOption

Re: Encoding of special characters in request URI

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 u

Re: URI class with userinfo ?

> 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]

Re: Connections not closing bug

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

Connections not closing bug

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; a

Re: Encoding of special characters in request URI

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 HttpMethod.se

Re: [PATCH] Multiple transfer encodings are still not handled properly

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 "#element" indicating at least and at most elements, e

RE: Encoding of special characters in request URI

I've solved this problem (Spanish Characters ) with private static final String CHARSET="ISO-8859-15"; try{ org.apache.commons.httpclient.URI.setDefaultProtocolCharset(CHARSET); }catch(org.apache.commons.httpclient.URI.DefaultCharsetChanged dcc){ // CASE 1: the exception could b

Encoding of special characters in request URI

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 Relea

Re: [PATCH] Multiple transfer encodings are still not handled properly

Which section of the RFC talks about this? Mike Kalnichevski, Oleg wrote: 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 en

Re: URI class with userinfo ?

Yes, it seems that none of the methods for getting the full URI include the userinfo. It is intenionaly removed in setURI(): if (_authority != null) { // has_authority if (_userinfo != null) { // by default, remove userinfo part if (_host != null) { buf.append(_host);

DO NOT REPLY [Bug 21378] - Transfer-Encoding: identity not supported + possible patch

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

[PATCH] Multiple transfer encodings are still not handled properly

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' he