RE: Is it possible to send and email using HTTPCLIENT?
Hello Steve, it is possible to create HTTP tunnels for other protocols with the 3.0 API, but you will still have to implement the protocol to be tunnelled. See http://issues.apache.org/bugzilla/show_bug.cgi?id=28151 cheers, Roland Steve Johnson [EMAIL PROTECTED] 20.10.2004 16:46 Please respond to Commons HttpClient Project To 'Commons HttpClient Project' [EMAIL PROTECTED] cc Subject RE: Is it possible to send and email using HTTPCLIENT? How about FTP through an HTTP proxy? Thanks, Steve Steve Johnson, Software Engineer, [EMAIL PROTECTED] direct 720.564.6532 www.mercury.com www.mercury.com -Original Message- From: Gerdes, Tom [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 8:08 AM To: Commons HttpClient Project Subject: RE: Is it possible to send and email using HTTPCLIENT? Thanks! -Original Message- From: Roland Weber [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 1:03 AM To: Commons HttpClient Project Subject: Re: Is it possible to send and email using HTTPCLIENT? Hello Tom, no it is not. Protocols for transferring EMail are SMTP or IMAP. HttpClient implements HTTP. Browsers do lots more than just HTTP, that's why most of them chose to implement mailing functionality as well. But HttpClient is intentionally focused on HTTP alone, which is tricky enough. There is a standard Java API for sending EMail in J2EE: http://java.sun.com/products/javamail/ You can probably get it running with J2SE as well. It includes support for multipart mail: http://java.sun.com/j2ee/1.4/docs/api/javax/mail/package-tree.html http://java.sun.com/j2ee/1.4/docs/api/javax/mail/Multipart.html hope that helps, Roland Gerdes, Tom [EMAIL PROTECTED] 19.10.2004 21:10 Please respond to Commons HttpClient Project To Commons HttpClient Project [EMAIL PROTECTED] cc Subject Is it possible to send and email using HTTPCLIENT? Can I just send a multipart post to an email server with attached files using Httpclient? Would this work for an email? If so, does anyone have an example of doing this? - 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]
Re: Auto-detecting proxy settings in a standalone Java app
Hello Chris, native Windows applications just work because they access native Windows APIs to read the proxy settings, which are probably stored somewhere in the Windows registry. Browsers and the Java Plugin for browsers are native Windows applications, and therefore can do just that. The only solution I can imagine right now is for you to write JNI code that looks up the appropriate keys in the registry. Which means you'll have to distribute a DLL along with the Java application. Wait, here is another idea: you could write a startup script that does the proxy settings lookup, then passes the settings through -D definitions as system properties, which can be accessed by your Java application. That's a bit less ugly than calling native code from within the app. The proxy settings for the HttpURLConnection of the JDK are expected as system properties, too. hope that helps, Roland Chris Brown [EMAIL PROTECTED] 22.10.2004 10:18 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject Auto-detecting proxy settings in a standalone Java app Hello, I would like to perform a simple request against a HTTP server in an application that will be deployed to customers with a wide variety of network configurations. The application won't be deployed as an applet or within Java Webstart, but will require JDK 1.4.2+ as the platform. The target audience are all Windows users. I've searched the HTTPClient archives and also the forums on Sun's Java Developer site. The only useful links were: http://forum.java.sun.com/thread.jsp?forum=30thread=364342 http://www.mail-archive.com/[EMAIL PROTECTED]/msg05349.html I get the following error when trying this out: java.io.IOException: Proxy service provider is not yet set at com.sun.java.browser.net.ProxyService.getProxyInfo(ProxyService.java:40) ...so I assume this only works within Webstart or an applet. Is there any way I can *automatically* retrieve the user's browser settings, even if requires using JNI or JNIWrapper for example ? At least the proxy host and port, even better if it can automatically enable login (or even provide me with enough info to use the NTLM features of HTTPClient, if required by the customer's environment). Manual proxy configuration generates *way* more support costs at present than anything else in the project. It's annoying to be disadvantaged in this way, when most native Windows applications just work... Thanks in advance, Chris Brown _ Bloquez les fenêtres pop-up, c'est gratuit ! http://toolbar.msn.fr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Auto-detecting proxy settings in a standalone Java app
Hello Chris, setting a fantasy proxy server in IE and searching for it in the registry yields: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings - ProxyServer - ProxyEnable a quick search on Google for Java Windows Registry yields: http://www.trustice.com/java/jnireg/ A public domain solution to access the Windows registry. http://sourceforge.net/projects/jregistrykey/ An LGPL-licensed solution to access the Windows registry. hope that helps, Roland Chris Brown [EMAIL PROTECTED] 22.10.2004 12:45 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject Re: Auto-detecting proxy settings in a standalone Java app Hi, Thanks for all the rapid feedback so far. I don't have VB or the VB runtime, although perhaps I could use the JNIWrapper software to access this information (if I knew where it was...!). Pity the Webstart proxy detection stuff isn't available for all to see, as it returns (I think) appropriate params, whether you use IE or Mozilla or whatever. On the other hand, given that JNIWrapper is commercial software, perhaps someone would know how to write a simple C program with mingw or whatever (easy to compile). It could detect params and return them on STDOUT, to be picked up either by a startup.bat or even through Runtime.exec() (solving the restart the JVM problem discussed earlier in this thread). First thing's first though... does anyone know where this information is stored in Windows ? IE and Mozilla/Firefox seem good targets for starters. Hey, why not even a little optional subproject for HTTPClient (requiring JNI and a compiler, preferably not *requiring* the MS tool chain), with a simple ProxyDetector interface, and a series of platform-specific implementations (to go further than my current Windows-only need) ? Any thoughts on these big ideas, or at least as far as solving the immediate problem (where are these settings stored and how can I get at them?) Thanks to all, Chris From: Oleg Kalnichevski [EMAIL PROTECTED] Reply-To: Commons HttpClient Project [EMAIL PROTECTED] To: Commons HttpClient Project [EMAIL PROTECTED] Subject: Re: Auto-detecting proxy settings in a standalone Java app Date: Fri, 22 Oct 2004 11:00:33 +0200 And how often does that happen in a course of one working day? I'd say not that often. I do agree with Roland that a startup script written in VBScript appears to be the best solution for the problem Oleg On Fri, 2004-10-22 at 10:54, Ortwin Glück wrote: Roland Weber wrote: Wait, here is another idea: you could write a startup script that does the proxy settings lookup, then passes the settings through -D definitions as system properties, which can be accessed by your Java application. That's a bit less ugly than calling native code from within the app. The proxy settings for the HttpURLConnection of the JDK are expected as system properties, too. Of course that implies you need to restart your app, everytime the proxy settings change... Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Recevez par e-mail des émoticônes pour MSN Messenger http://g.msn.fr/FR1001/2275?url=http://www.msn.fr/ilovemessenger/premium/Default.asp?Ath=f - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to send and email using HTTPCLIENT?
Hello Tom, no it is not. Protocols for transferring EMail are SMTP or IMAP. HttpClient implements HTTP. Browsers do lots more than just HTTP, that's why most of them chose to implement mailing functionality as well. But HttpClient is intentionally focused on HTTP alone, which is tricky enough. There is a standard Java API for sending EMail in J2EE: http://java.sun.com/products/javamail/ You can probably get it running with J2SE as well. It includes support for multipart mail: http://java.sun.com/j2ee/1.4/docs/api/javax/mail/package-tree.html http://java.sun.com/j2ee/1.4/docs/api/javax/mail/Multipart.html hope that helps, Roland Gerdes, Tom [EMAIL PROTECTED] 19.10.2004 21:10 Please respond to Commons HttpClient Project To Commons HttpClient Project [EMAIL PROTECTED] cc Subject Is it possible to send and email using HTTPCLIENT? Can I just send a multipart post to an email server with attached files using Httpclient? Would this work for an email? If so, does anyone have an example of doing this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP Version Not Supported Error
Hello Nick,
this description sounds more like a problem with connection re-use
than connection management. You can try to send connection: close
headers with each POST request, so the HTTP client does not try
to re-use connections. If that doesn't help, try to force HTTP client
back to the HTTP/1.0 protocol, which disables connection re-use
completely.
I agree with Oleg's guess that it is a server problem. The server
probably indicates HTTP/1.1 support, but does not implement
connection re-use for POSt requests. So when HTTP client relies
on this feature, the server fails.
cheers,
Roland
Nick Jarvis [EMAIL PROTECTED]
15.10.2004 19:41
Please respond to
Commons HttpClient Project
To
[EMAIL PROTECTED]
cc
Subject
Re: HTTP Version Not Supported Error
Hi Roland,
I don't understand why I am not able to synchronize the post method
considering that I am simply subclassing the PostMethod. What I have done
is simply copy the EntityEnclosingMethod's writeRequestBody function in my
new class first to see if it would work similarly like the post method
does.
This will not work for me and returns the HTTP Version Not Supported
function when the connection manager is done blocking after the max
connections per host is reached. So to reiterate, if my max connections
per
host for my MultiThreadedHttpConnectionManager is set to 2, and the max
total connections is default at 20, and I am trying to upload say 6 files
at
the same time. The first two will work succesfully blocking the rest of
the
threads. When one becomes available, the third file is giving me the
server
error of HTTP Version Not Supported. The fourth file will upload
correctly
when the thread is unblocked. Then the fifth will return the same HTTP
Verson Not Supported error and the sixth will work. Here is the code for
my
subclass. Below this class is how I would be using it in a thread run()
function.
public class UploadMethod extends PostMethod {
protected boolean writeRequestBody(HttpState state, HttpConnection
conn)
throws IOException, HttpException {
if (!super.hasRequestContent()) {
return true;
}
int contentLength = super.getRequestContentLength();
InputStream instream = null;
if (this.requestStream != null) {
instream = super.getRequestBodyAsStream();
}
if (instream == null) {
return true;
}
OutputStream outstream = conn.getRequestOutputStream();
if (contentLength = 0) {
// don't need a watcher here - we're reading from something
local,
// not server-side.
instream = new ContentLengthInputStream(instream,
contentLength);
}
byte[] tmp = new byte[4096];
int total = 0;
int i = 0;
while ((i = instream.read(tmp)) = 0) {
outstream.write(tmp, 0, i);
total += i;
}
if ((contentLength 0) (total contentLength)) {
throw new IOException(Unexpected end of input stream after
+ total + bytes (expected + contentLength +
bytes));
}
return true;
}
}
This is how I would be using this class in a thread:
File file = new File(filePath);
UploadMethod method = new UploadMethod(ServletAddress);
method.setRequestConentLength(file.length);
method.setRequestHeader(Content-type, application/octet-stream);
method.setRequestBodyAsStream(new FileInputStream(file));
int status = client.execute(method);
Thanks agiain,
Nick
From: Roland Weber [EMAIL PROTECTED]
Reply-To: Commons HttpClient Project
[EMAIL PROTECTED]
To: Commons HttpClient Project
[EMAIL PROTECTED]
Subject: Re: HTTP Version Not Supported Error
Date: Fri, 15 Oct 2004 09:19:23 +0200
Hello Nick,
by implementing ...methods.multipart.PartSource, you can supply your
own InputStream. Using HttpMethod.getResponseBodyAsStream(),
you have direct access to the input stream of the response. What more
control do you need?
The problem you report suggests that your version of the post method
somehow fails to synchronize the connection usage. But that is hard to
diagnose if you don't send the modified source.
cheers,
Roland
Nick Jarvis [EMAIL PROTECTED]
14.10.2004 20:13
Please respond to
Commons HttpClient Project
To
[EMAIL PROTECTED]
cc
Subject
HTTP Version Not Supported Error
I am currently using HttpClient 2.0.2 and trying to create a multi
threaded
file upload. I have restrictions on the project I can use , therefore I
am
using HttpClient MultiThreadedHttpConnectionManager that is connecting to
the same host and I am using HttpClient PostMethod for the upload. I am
trying to use the PostMethod as a subclass and overide the
WriteRequestBody
function to have more control over the upload. However, I am getting and
error reading: 'HTTP Version Not Supported' from the status text for the
third thread (for the third file that I am trying
Re: HTTP Version Not Supported Error
Hi Nick,
I didn't try this out, but here are a few suggestions:
a) HttpClient already implements chunked encoding in
both directions. Have a look at the classes, maybe you
can use them on the server side as well.
b) Don't call setContentLength, or set it to -1 in a
FilePart object. This should work fine with HTTP/1.1
and chunked encoding, but also with HTTP/1.0 and
no chunked encoding. Since the server does not know
the content length in advance, it has to read until the
end of the stream in no-chunks mode. Connection
re-use is impossible, but after transferring more than
2 gigs I doubt you'll notice the performance impact
of opening a new connection :-)
It might be a violation of HTTP to POST data without
a valid content length, but since you're controlling
the server as well, that shouldn't bother you much.
hope that helps,
Roland
Nick Jarvis [EMAIL PROTECTED]
18.10.2004 16:06
Please respond to
Commons HttpClient Project
To
[EMAIL PROTECTED]
cc
Subject
Re: HTTP Version Not Supported Error
Roland,
Thanks, I am writing my own server doGet and doPost methods using
HttpServlet, but for some reason the servlet must be defaulting to
HTTP/1.0.
Therefore I changed my subclass code with the setHttp11 method and the
connections seem to be closing after each upload and is not giving me the
problem. One of the main reasons why I wanted control for the upload was
to
figure out a way to upload files larger than 2 gigs. I understand that
chunked encoding is a possibility, but I am writing my own server code and
would rather not implement this on the server side. Is there a way I can
upload files larger than 2 gigs using HttpClient? I am also writing file
download code and I simply open up a stream in the doGet method and write
out the bytes to the stream from the server. On the client side it is
easy
to get the stream and read in all the bytes, and I am able to download
very
large files. I want to be able to do this uploading files, but the set
content length function only allows 2 gigs. Is there a limit on the
stream
to only be 2 gigs? How could I upload files larger than 2 gigs besides
using chunked encoding? Thanks for your help,
Nick
From: Roland Weber [EMAIL PROTECTED]
Reply-To: Commons HttpClient Project
[EMAIL PROTECTED]
To: Commons HttpClient Project
[EMAIL PROTECTED]
Subject: Re: HTTP Version Not Supported Error
Date: Mon, 18 Oct 2004 08:48:37 +0200
Hello Nick,
this description sounds more like a problem with connection re-use
than connection management. You can try to send connection: close
headers with each POST request, so the HTTP client does not try
to re-use connections. If that doesn't help, try to force HTTP client
back to the HTTP/1.0 protocol, which disables connection re-use
completely.
I agree with Oleg's guess that it is a server problem. The server
probably indicates HTTP/1.1 support, but does not implement
connection re-use for POSt requests. So when HTTP client relies
on this feature, the server fails.
cheers,
Roland
Nick Jarvis [EMAIL PROTECTED]
15.10.2004 19:41
Please respond to
Commons HttpClient Project
To
[EMAIL PROTECTED]
cc
Subject
Re: HTTP Version Not Supported Error
Hi Roland,
I don't understand why I am not able to synchronize the post method
considering that I am simply subclassing the PostMethod. What I have
done
is simply copy the EntityEnclosingMethod's writeRequestBody function in
my
new class first to see if it would work similarly like the post method
does.
This will not work for me and returns the HTTP Version Not Supported
function when the connection manager is done blocking after the max
connections per host is reached. So to reiterate, if my max connections
per
host for my MultiThreadedHttpConnectionManager is set to 2, and the max
total connections is default at 20, and I am trying to upload say 6 files
at
the same time. The first two will work succesfully blocking the rest of
the
threads. When one becomes available, the third file is giving me the
server
error of HTTP Version Not Supported. The fourth file will upload
correctly
when the thread is unblocked. Then the fifth will return the same HTTP
Verson Not Supported error and the sixth will work. Here is the code for
my
subclass. Below this class is how I would be using it in a thread run()
function.
public class UploadMethod extends PostMethod {
protected boolean writeRequestBody(HttpState state, HttpConnection
conn)
throws IOException, HttpException {
if (!super.hasRequestContent()) {
return true;
}
int contentLength = super.getRequestContentLength();
InputStream instream = null;
if (this.requestStream != null) {
instream = super.getRequestBodyAsStream();
}
if (instream == null) {
return true;
}
OutputStream outstream = conn.getRequestOutputStream();
if (contentLength = 0
Re: HTTP Version Not Supported Error
Hello Nick, by implementing ...methods.multipart.PartSource, you can supply your own InputStream. Using HttpMethod.getResponseBodyAsStream(), you have direct access to the input stream of the response. What more control do you need? The problem you report suggests that your version of the post method somehow fails to synchronize the connection usage. But that is hard to diagnose if you don't send the modified source. cheers, Roland Nick Jarvis [EMAIL PROTECTED] 14.10.2004 20:13 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject HTTP Version Not Supported Error I am currently using HttpClient 2.0.2 and trying to create a multi threaded file upload. I have restrictions on the project I can use , therefore I am using HttpClient MultiThreadedHttpConnectionManager that is connecting to the same host and I am using HttpClient PostMethod for the upload. I am trying to use the PostMethod as a subclass and overide the WriteRequestBody function to have more control over the upload. However, I am getting and error reading: 'HTTP Version Not Supported' from the status text for the third thread (for the third file that I am trying to upload after the previoius two are complete). The response from the server is not pretty either. I even tried copying the same exact source from the PostMetho class into a new class but I am still getting this error when running the method. I am noticing that the MultiThreadedHttpConnectionManager defaults to 2 connections per host, and the manager seems to be blocking my third thread until one of the other two complete. Once one thread is complete and unblocks the next thread, I am unable to upload the next file due to this server error. If I increase the connections per host variable, the upload after the connections per host limit is returning this message.If I just use the PostMethod or MultipartPostMethod, the uploads work fine, but I need more control over the input stream and the upload. Could someone please advise. Thank you for your time, Nick Jarvis _ Express yourself instantly with MSN Messenger! Download today - it's FREE! hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bugzilla] vs [JIRA] revisited
Hi Oleg, could we synchronize the switch with the 4.0 implementation? In other words, continue with Bugzilla for 2.0 and 3.0, but once work gets started on 4.0, where the API changes and the package names probably change, then the bug tracking system changes as well? cheers, Roland
Re: HttpClient query...
Hello Srinivas, java.sun.com seems to be down or overloaded, but I found this link in Google about signed applets: http://www.betrusted.com/downloads/products/keytools/v51/pro/j-docs/html/SampleCodes/sampleApplet/codesign/intro.html Once java.sun.com is back up, these links could be useful for you: http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html http://java.sun.com/security/signExample12/ hope that helps, Roland Srinivas Velidanda [EMAIL PROTECTED] 07.10.2004 15:33 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject Re: HttpClient query... Hi, Greetings. I am running into problems, as you have mentioned, i was trying to work with an Applet. Couldn't set security permissions and even if I set the permissions there could be problems with setting the user credentials. I do not know how I can make the applet access the files at client side. So, pl let me know how can I create a multipart request using HttpClient api or --how can I read the files from the file system once I get the drive and directory names from the client by using javascript, I searched the internet but couldn't find any samples to generate html form using javascript and that must create file items dynamically by reading the files from the file system. I thought of all the options that I could, but not getting a solution, which is very urgent. Pl. suggest me a solution. thanks for the help, Srinivas. Roland Weber [EMAIL PROTECTED] wrote: Hello Srinivas, I think some people have succeeded in using HttpClient from an applet. Remember you will have to sign the applet in order to access the client file system. But you could run into problems accessing the user credentials in the applet. You could also try to write JavaScript code which generates an HTML form, including one file element for every file in the directory. In that case, the browser would take care of building the HTTP request and adding user credentials. The problem once more is to access the file system from the script code. Using a combination of both could work out. It is possible to call JavaScript from an applet and vice versa. So you could write (and sign!) an applet that creates a directory listing, then use that listing in JavaScript to create a form which is then posted by the browser to the server. Other ideas? cheers, Roland Srinivas Velidanda 06.10.2004 13:43 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject Re: HttpClient query... Hi, Thanks for your help. I found the samples specified by you very much useful. I got it working with my JSP by sending user credential parameters which were required at my server. Now the problem is making the same with an applet as it is not working from remote client accessing the JSP. The flow is like this. I have a screen where I enter drive name, and directory to be uploaded and in the next JSP I get the files of specified folder and create multipart request and send to the server along with User credentials. Everything is working fine on the system which both client and server are running. But If I try the same from remote client then It is looking for files in the folder specified by client in server which is generating null pointer exception. Now I need to make the functionality of creating the multipart request at client side, I am planning to do it in the applet. Is it the right way to go for an applet, or can you suggest me some other solution.. thanks, Srinivas. Roland Weber wrote: Hello Srinivas, you are using HttpClient from within a JSP to connect to the server that is running the JSP? Or to a different server? If you want to set request parameters, you don't do that before creating the multipart request. You create the multipart request, then add the parameters using MP.addParameter(..) or MP.addPart(...). Just make sure to add all required parameters before you *execute* the method. See also the web site at http://jakarta.apache.org/commons/httpclient/methods/multipartpost.html The sample code for multipart file upload is for the 2.0 API, but it should be helpful anyway. Go straight to the actionPerformed method: http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/?only_with_tag=HTTPCLIENT_2_0_BRANCH cheers, Roland Srinivas Velidanda 05.10.2004 14:00 Please respond to Commons HttpClient Project To Commons HttpClient Project cc Subject Re: HttpClient query... Hi Roland, thanks for the reply. I am new to this API and pl let me know how can I do the following. 1. can I set the same parameters coming from the session before creating Multipart request to the Multipart request, if yes, how can I set and how can these parameters can be referred at the server side. 2.I am getting the session parameters in the JSP where I am creating Multipart request, but once I post the Multipart request to the server
Re: HttpClient query...
Hello Srinivas, I think some people have succeeded in using HttpClient from an applet. Remember you will have to sign the applet in order to access the client file system. But you could run into problems accessing the user credentials in the applet. You could also try to write JavaScript code which generates an HTML form, including one file element for every file in the directory. In that case, the browser would take care of building the HTTP request and adding user credentials. The problem once more is to access the file system from the script code. Using a combination of both could work out. It is possible to call JavaScript from an applet and vice versa. So you could write (and sign!) an applet that creates a directory listing, then use that listing in JavaScript to create a form which is then posted by the browser to the server. Other ideas? cheers, Roland Srinivas Velidanda [EMAIL PROTECTED] 06.10.2004 13:43 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject Re: HttpClient query... Hi, Thanks for your help. I found the samples specified by you very much useful. I got it working with my JSP by sending user credential parameters which were required at my server. Now the problem is making the same with an applet as it is not working from remote client accessing the JSP. The flow is like this. I have a screen where I enter drive name, and directory to be uploaded and in the next JSP I get the files of specified folder and create multipart request and send to the server along with User credentials. Everything is working fine on the system which both client and server are running. But If I try the same from remote client then It is looking for files in the folder specified by client in server which is generating null pointer exception. Now I need to make the functionality of creating the multipart request at client side, I am planning to do it in the applet. Is it the right way to go for an applet, or can you suggest me some other solution.. thanks, Srinivas. Roland Weber [EMAIL PROTECTED] wrote: Hello Srinivas, you are using HttpClient from within a JSP to connect to the server that is running the JSP? Or to a different server? If you want to set request parameters, you don't do that before creating the multipart request. You create the multipart request, then add the parameters using MP.addParameter(..) or MP.addPart(...). Just make sure to add all required parameters before you *execute* the method. See also the web site at http://jakarta.apache.org/commons/httpclient/methods/multipartpost.html The sample code for multipart file upload is for the 2.0 API, but it should be helpful anyway. Go straight to the actionPerformed method: http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/?only_with_tag=HTTPCLIENT_2_0_BRANCH cheers, Roland Srinivas Velidanda 05.10.2004 14:00 Please respond to Commons HttpClient Project To Commons HttpClient Project cc Subject Re: HttpClient query... Hi Roland, thanks for the reply. I am new to this API and pl let me know how can I do the following. 1. can I set the same parameters coming from the session before creating Multipart request to the Multipart request, if yes, how can I set and how can these parameters can be referred at the server side. 2.I am getting the session parameters in the JSP where I am creating Multipart request, but once I post the Multipart request to the server the session is getting killed. We are not working with cookies. Is there a solution without using cookies or I must go for cookies.. thanks, Srinivas Roland Weber wrote: Hello Srinivas, if the session is handled by a session cookie, just make sure you use the same HttpState object for all requests. That should happen automagically if you do nothing special and re-use one HttpClient for all requests. If the server uses URL rewriting because it believes that the client can't handle cookies, you have a problem. You will have to parse server responses in order to extract URLs with the session information encoded in them. Or convince the server to send cookies. hope that helps, Roland Srinivas Velidanda 05.10.2004 13:32 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject HttpClient query... Hi, I am using HttpClient (commons-httpclient-3.0-alpha2) api for file upload. How to handle a session if I am creating a MultipartPost request in a JSP and posting the request using client.executeMethod(mPost) to a servlet URL. Once I send the request the session is getting killed and could not pass on the request to a specific handler in sequence.. Pl. let me know how to handle the session, if possible send me some sample code for that. thanks in advance.. Srinivas. - Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! - Do you Yahoo!? Yahoo
Re: HttpClient query...
Hello Srinivas, if the session is handled by a session cookie, just make sure you use the same HttpState object for all requests. That should happen automagically if you do nothing special and re-use one HttpClient for all requests. If the server uses URL rewriting because it believes that the client can't handle cookies, you have a problem. You will have to parse server responses in order to extract URLs with the session information encoded in them. Or convince the server to send cookies. hope that helps, Roland Srinivas Velidanda [EMAIL PROTECTED] 05.10.2004 13:32 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject HttpClient query... Hi, I am using HttpClient (commons-httpclient-3.0-alpha2) api for file upload. How to handle a session if I am creating a MultipartPost request in a JSP and posting the request using client.executeMethod(mPost) to a servlet URL. Once I send the request the session is getting killed and could not pass on the request to a specific handler in sequence.. Pl. let me know how to handle the session, if possible send me some sample code for that. thanks in advance.. Srinivas. - Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages!
Re: HttpClient query...
Hello Srinivas, you are using HttpClient from within a JSP to connect to the server that is running the JSP? Or to a different server? If you want to set request parameters, you don't do that before creating the multipart request. You create the multipart request, then add the parameters using MP.addParameter(..) or MP.addPart(...). Just make sure to add all required parameters before you *execute* the method. See also the web site at http://jakarta.apache.org/commons/httpclient/methods/multipartpost.html The sample code for multipart file upload is for the 2.0 API, but it should be helpful anyway. Go straight to the actionPerformed method: http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/?only_with_tag=HTTPCLIENT_2_0_BRANCH cheers, Roland Srinivas Velidanda [EMAIL PROTECTED] 05.10.2004 14:00 Please respond to Commons HttpClient Project To Commons HttpClient Project [EMAIL PROTECTED] cc Subject Re: HttpClient query... Hi Roland, thanks for the reply. I am new to this API and pl let me know how can I do the following. 1. can I set the same parameters coming from the session before creating Multipart request to the Multipart request, if yes, how can I set and how can these parameters can be referred at the server side. 2.I am getting the session parameters in the JSP where I am creating Multipart request, but once I post the Multipart request to the server the session is getting killed. We are not working with cookies. Is there a solution without using cookies or I must go for cookies.. thanks, Srinivas Roland Weber [EMAIL PROTECTED] wrote: Hello Srinivas, if the session is handled by a session cookie, just make sure you use the same HttpState object for all requests. That should happen automagically if you do nothing special and re-use one HttpClient for all requests. If the server uses URL rewriting because it believes that the client can't handle cookies, you have a problem. You will have to parse server responses in order to extract URLs with the session information encoded in them. Or convince the server to send cookies. hope that helps, Roland Srinivas Velidanda 05.10.2004 13:32 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject HttpClient query... Hi, I am using HttpClient (commons-httpclient-3.0-alpha2) api for file upload. How to handle a session if I am creating a MultipartPost request in a JSP and posting the request using client.executeMethod(mPost) to a servlet URL. Once I send the request the session is getting killed and could not pass on the request to a specific handler in sequence.. Pl. let me know how to handle the session, if possible send me some sample code for that. thanks in advance.. Srinivas. - Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! - Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish.
java.net.SocketException: Connection reset
Return Receipt Your java.net.SocketException: Connection reset document : was Roland Weber/Germany/IBM received by: at: 04/10/2004 08:53:27 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
java.net.SocketException: Connection reset
Return Receipt Your java.net.SocketException: Connection reset document : was Roland Weber/Germany/IBM received by: at: 04/10/2004 08:54:45 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threads problem with many connections
Hello Guillaume, have you considered implementing your own connection manager? But I would start with tuning the parameters of the existing one. If it is a realistic scenario that each service thread executes a POST at the same time, increase the number of connections in total and per host to the number of threads. This will not solve the garbage over and over problem, though. If it is acceptable performance-wise, you can disable connection re-use. I'm not familiar with the implementation, but it might prevent the connection manager from reading the response body. cheers, Roland Guillaume Cottenceau [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01.10.2004 12:57 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject threads problem with many connections Hello, We use HttpClient for performing several HTTP post in parallel in our applications. We have a problem when the server(s) receiving our HTTP post either answers very slowly, or goes mad and sends garbage data over and over: the connection stays open forever, but more important, the Java threads as well. We have situations where we reach the maximum of Java threads our (tomcat) application is configured to handle, and our whole application is then unusable. It seems that java.nio is capable of using only one thread for several lowlevel (OS) socket connections, and is actually also quite efficient. I have seen that Oleg Kalnichevski has already expressed his views several times on the subject, and I have seen that you want to keep 1.2 compatibility, so java.nio out. http://www.mail-archive.com/[EMAIL PROTECTED]/msg05551.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg06998.html (btw, I don't agree with in my opinion there's absolutely nothing that NIO can bring in in terms of performance to client-side applications - well I agree that pure performance is not the problem but threads and memory consumption surely is - so in my opinion there is a lot to win with java.nio in httpclient) My question is, since you don't want to lose 1.2 compatibility before 4.0, is there then a way to solve a typical too many threads problem such as the one we have? Do you people never had the same problem? Or have found a way to solve it? It seems the HTTP protocol doesn't have anything resembling a global timeout for a given connection (e.g. after x seconds, close the receiving channel even if server hasn't finished sending), and thus normally httpclient doesn't provide such a thing. Do you think this should be investigated/implemented in some way? Thanks, and best regards. -- Guillaume Cottenceau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick Question
Hi Rudy, Hentzen, Rudy [EMAIL PROTECTED] wrote on 29.09.2004 15:16:34: Another thing, it is possible to, for example, get all the of the form actions from a html page, I have managed to get what I need using reg exps but just wondering if it is in the HttpClient package??? It is not, and never will be. That's HTML parsing, not HTTP handling. cheers, Roland
Re: Unable to use post with a site
Hello,
first, you should try to add the following:
method.addParameter(abcv, View)
because a submit button also defines a parameter
when it is given a name.
Due to the onclick handler, there should be a POST
request as well as the modification of the location.
I can't tell whether the location change affects the
current page or the one returned by the POST. It
seems more reasonable if it affects the current
page. Either way, since the new URL starts with a
#, it probably only scrolls the page that is shown to
an anchor within the page. Maybe to move the
submit button out of view, for those impatient users
that would click on it again and again.
cheers,
Roland
Spam Proof [EMAIL PROTECTED]
13.09.2004 14:13
Please respond to
Commons HttpClient Project
To
[EMAIL PROTECTED]
cc
Subject
Unable to use post with a site
Hi,
I am using httpclient to post some data to a website.
The actual url that I am trying to post to is
http://www.amfiindia.com/navreport.asp
The asp page corresponding to the form is given below
---navreport.asp--begin
form name=abc method=post action=navreport.asp
select size=1 name=cmbmf
option value=allALL/option
option value=39abc/option
...
/select
input type=submit value=View name=abcv
onclick=location.replace('#123')
---navreport.asp--end--
I use the following code:
String url = http://www.amfiindia.com/navreport.asp;;
HttpClient client = new HttpClient();
PostMethod method = new PostMethod( url );
method.addParameter( cmbmf, all );
method.setFollowRedirects(true);
int statusCode = client.executeMethod( method );
if( statusCode != -1 ) {
String contents = method.getResponseBodyAsString();
method.releaseConnection();
System.out.println( contents );
}
Instead of the posted results, I am getting the page containing the form.
Should I use a different url because of the
onclick=location.replace('#123') in the submit button?
Yahoo! India Matrimony: Find your life partneronline.
Re: URLGetMethod.executeMethod is hanging under multi threaded environment
Hello,
unfortunately, you left out the part where the HttpClient instance is
created.
Did you remember to install a MultiThreadedHttpConnectionManager?
If the same client object is passed to several of the SaveAttachmentThread
instances, you need the thread-safe connection manager.
But the main problem should be that you do not call
getMethod.releaseConnection() after reading the response body.
This should best be done in a finally clause, since it is necessary
no matter whether there is a problem or not.
With your implementation and the SimpleHttpConnectionManager which is
used by default, a single download should succeed. All other downloads
then wait for the connection that is never released by the first one.
cheers,
Roland
Koundinya \(Sudhakar Chavali\) [EMAIL PROTECTED]
06.09.2004 14:25
Please respond to
Commons HttpClient Project
To
[EMAIL PROTECTED]
cc
Subject
URLGetMethod.executeMethod is hanging under multi threaded environment
Subject: URLGetMethod.executeMethod is hanging under multi threaded
environment
Hello Guys,
Please see the folloiwng code. I am trying to download the mails of MS
Exchange Server using
URLGetMethod.executeMethod. But when execution pointer comes to the thread
area
(URLGetMethod.executemethod),
URLGetMethod.executemethod is not coming out of it's loop. Could you
please explain what is the
problem with this code??
class SaveAttachmentThread
extends Thread
implements Runnable {
static int threadCount = 0;
String uri = ;
String strAttachmentName = ;
private org.apache.commons.httpclient.HttpClient client = null;
org.apache.commons.httpclient.methods.UrlGetMethod attachmentMethod =
null;
public SaveAttachmentThread(String uri, String strAttachmentName,
org.apache.commons.httpclient.HttpClient
client) {
this.uri = uri;
this.strAttachmentName = strAttachmentName;
this.client = client;
}
public SaveAttachmentThread(org.apache.commons.httpclient.methods.
UrlGetMethod _getMethod, String attachment)
{
attachmentMethod = _getMethod;
this.strAttachmentName = attachment;
}
public void run() {
//strAttachmentName = URLDecoder.decode(strAttachmentName);
System.err.println(Saved to + strAttachmentName);
System.err.println(URL : + uri);
try {
System.err.println(Saving the URL : + strAttachmentName);
org.apache.commons.httpclient.methods.UrlGetMethod getMethod = new
org.
apache.commons.httpclient.methods.UrlGetMethod(uri);
int status = client.executeMethod(getMethod);
byte attachmentBytes[] = getMethod.getResponseBody();
FileOutputStream fout = new FileOutputStream(strAttachmentName);
fout.write(attachmentBytes);
fout.close();
fout = null;
threadCount++;
System.err.println(threadCount);
}
catch (Throwable e) {
System.err.println(Error raised while saving the URI : +
strAttachmentName);
e.printStackTrace();
}
}
}
thanks
Sudhakar
P.S:
The Client Instance creating is some thing like this
try {
org.apache.commons.httpclient.HttpURL url = (org.apache.commons.
httpclient.HttpURL) getURL(path + / + user);
org.prithvi.docparser.microsoft.msexchange.apache.OwaWebdavResource
webDavResourceFile = getWebResource(
url);
//get the client session
client = webDavResourceFile.retrieveSessionInstance();
}
catch (Throwable ex) {
//set the client session instance to null;
client = null;
}
I mean for creating client instance I am using
WebDaveResource.retrieveSessionInstance()
=
No one can earn a million dollars honestly.- William Jennings Bryan
(1860-1925)
Make everything as simple as possible, but not simpler.- Albert Einstein
(1879-1955)
It is dangerous to be sincere unless you are also stupid.- George
Bernard Shaw (1856-1950)
__
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
RE: Response content length is not known
Hi Oleg, Kalnichevski, Oleg [EMAIL PROTECTED] wrote on 18.08.2004 11:26:10: HTTP/1.0 200 OK[\r][\n] Date: Thu, 19 Aug 2004 02:01:34 GMT[\r][\n] Server: Oracle9iAS (9.0.3.0.0) Containers for J2EE[\r][\n] Content-Type: text/html[\r][\n] As you can see the response does not contain a 'content-length' header which is mandatory for the 200 (OK) response, hence the warning RFC1945 7.2 Entity Body ... For response messages, ... [a]ll 1xx (informational), 204 (no content), and 304 (not modified) responses must not include a body. All other responses must include an entity body or a Content-Length header field defined with a value of zero (0). /RFC1945 It says or. Meaning if there is a body, there is no need for the Content-Length header, right? It's mandatory only with value 0, to indicate that there is no body. Otherwise, dynamically generated content would have been a major problem with HTTP/1.0, or so I figure. But I'm not familiar with RFC 1945, so please correct me if I'm wrong. cheers, Roland
Re: Invoke a httpclient in a EJB
Hello Karthi, HttpClient does create sockets. And it creates threads in some situations, for example when using timeouts while creating sockets. It's definitely not EJB friendly. cheers, Roland Karthikeyani K [EMAIL PROTECTED] 04.08.2004 17:20 Please respond to Commons HttpClient Project To [EMAIL PROTECTED] cc Subject Invoke a httpclient in a EJB Hi, We have all requests posted to a servlet which delegates the request to a Stateless Session Bean. Does creatring and invoking a Httpclient postmethod in a helper class invoked by the Stateless Session Bean violate any of the EJB specifications. (EJB spec says sockets are not to be created in EJB code etc. ). Please suggest. Thanks, Karthi __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: URL escaping
Hi Steve,
the comma is a reserved character, and the vertical bar is
an excluded character in RFC 2396 (URI Generic Syntax).
Try to escape just those characters in the part before ?.
cheers,
Roland
Steve Johnson [EMAIL PROTECTED]
07.07.2004 17:53
Please respond to
Commons HttpClient Project
To
'[EMAIL PROTECTED]'
[EMAIL PROTECTED]
cc
Subject
URL escaping
Hi All,
Here is a URL that throws an exception if passed to GetMethod as is:
throws something like invalid argument or uri.
It appears to be the unescaped characters in
/tr/cl/1,,TRAVELOCITY|987,00.html
The problem is if the whole string is escaped then these escaped
characters are double encoded: %3fService%3d
to %325fService%253d
which causes a server error 500.
http://tr.travelocity.com/tr/cl/1,,TRAVELOCITY|987,00.html?s=hp1
http://tr.travelocity.com/tr/cl/1,,TRAVELOCITY|987,00.html?s=hp1c=hdstuffURL=https://dps1.travelocity.com/l
ognlogin.ctl%3fService%3dTRAVELOCITY%26tr_module%3dRETR%26SEQ%3d1372136878108921366819
c=hdstuffURL=https://dps1.travelocity.com/lognlogin.ctl%3fService%3dTRAVELOCITY%26tr_module%3dRETR%26SEQ%3d1
372136878108921366819
Is there a simple way to send any request without complaining about the
URI?
If this URL is pasted into IE it works.
Currently doing this:
URI parsedURI = null;
// if at first you don't succeed.
try {
try { // again.
parsedURI = new URI(url.toCharArray()); // This throws on
the URL above
} catch (URIException e) {
parsedURI = new URI(url, I18N.getDefaultEncoding()); //
This double encodes the URL above.
}
} catch (URIException e) {
}
Thanks for your time and help,
Steve
Steve Johnson
Software Engineer
Mercury Interactive
720 564 - 6532
USA, Canada and the Americas
720 564-6620
Hours: M-F 08:00-17:00 MST (Mountain Standard Time)
http://www.mercuryinteractive.com http://www.mercuryinteractive.com
Looking for Answers to your SiteScope or SiteSeer questions?
http://support.mercuryinteractive.com
http://support.mercuryinteractive.com
RE: NTLM authentication to an MS Exchange web page account using HTTP Client V2.0
Hi Andre-John, I have just got my friend to try connecting to out intranet web server with Safari and it does not support NTLM authentication. The only two web clients on the platform that do suppor it are Mozilla variety and Internet Explorer. Though I can't confirm whether they use the user's logged in credentials, since he logs in to his portable with local authentication and then connects to the servers on a case by case basis. As for 'JDK with HttpUrlConnection'I have not yet tested this. It may turn out to be a Windowss only solution. Thanks for the information. Thinking about it, I believe the ideal solution would be to create an authentication factory, which would return an instance of an 'authenticator' (my made up name), based on specified name. This would allow us to have the flexibility of either returning a pure Java instance of an implementation (if possible) or one that has a native implementation. If an authenticator could not initialise itself for the given platform or environment, then an Exception would be thrown. How does this sound? - note: 2min design process Sounds great. Use *.httpclient.auth.CredentialsProvider as the interface for the 'authenticator' and you're almost there :-) The factory will become very ugly though, because of all the platform specific checks. cheers, Roland
Re: NTLM authentication to an MS Exchange web page account using HTTP Client V2.0
Hi Odi, I am not requiring or implementing the feature, I was merely asking out of curiosity and to be prepared for the next time someone wants to know how to authenticate as the OS user. I fully agree that calling sun or com.sun classes is not a good idea. But whenever we tell people they could use JNI, I very much doubt they'll actually try it. Adding native code to a Java project is a big step which few will take. If there is an internal Java API we know about, we could at least tell folks about it, point out the implementation dependency problem, and leave the decision to them. As I am using IBM JDKs, I can tell you they include plenty of sun and com.sun classes. The IBM implementation is also based on the Sun version. cheers, Roland Ortwin Glück [EMAIL PROTECTED] 30.06.2004 09:01 Please respond to Commons HttpClient Project To Commons HttpClient Project [EMAIL PROTECTED] cc Subject Re: NTLM authentication to an MS Exchange web page account using HTTP Client V2.0 Roland Weber wrote: If the latter is true, there still might be a platform-independent class somewhere in sun.* or com.sun.*. Roland, you can safely call the sun.* and com.sun.* packages platform/implementation dependent. Apple have their own Java implementation, which is based on Sun's. If you are using implementations from IBM or BEA: They have no sun.* packages at all. Using sun packages ties your code tightly to a specific Java implementation. That is even worse than using native code, which is still portable among Java implementations. If JNI is an option, you must of course provide a specific JNI module for every supported platform. This is not a bad thing. If you had used any other language you would have needed to do it as well. You can write your application such that it runs on any platform and can use the automatic NT credentials on supported platforms only. Think of it as a plug-in. Ortwin Glück -- _ NOSE applied intelligence ag ortwin glück [www] http://www.nose.ch software engineer hardturmstrasse 171 [pgp id] 0x81CF3416 8005 zürich [office] +41-1-277 57 35 switzerland [fax] +41-1-277 57 12 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RESULT: possible bugs:( Re: Resend: disable httpclient logging)
Hi Odi, Maybe we should also change the wirelog logger to something like 'org.apache.commons.httpclient.wire'. The JLogFactory uses different methods to obtain loggers for a class and by name. Prefixing the name with a package is OK by me, but I'd prefer to leave some distinction in the naming scheme. Maybe 'org.apache.commons.httpclient.WIRE'. Or use some special characters no sane person would want to have in a class name, though they are acceptable in a property name. cheers, Roland
Re: Invalid RSA modulus size
Hello Tim, from what I know about the export regulations, shipping working crypto code that is just disabled through some configuration file is not acceptable. You will have to obtain a full-strength JCE/JSSE implementation. Either a US-only version of the JDK, or a non-US implementation of the library which is not subject to US or other export restrictions on cryptography. cheers, Roland Tim Wild [EMAIL PROTECTED] 21.06.2004 05:19 Please respond to Commons HttpClient Project To Commons HttpClient Project [EMAIL PROTECTED] cc Subject Re: Invalid RSA modulus size Does anyone know if the Unlimited Strength Jurisdiction Policy Files are meant to solve this problem, or is it actually a bug with the JDK1.4? The policy files don't help me at all on the JDK1.4. Thanks Tim Oleg Kalnichevski wrote: Tim, This is believed to be a limitation of all Sun's JCE/JSSE implementations up to Java version 1.5. You can try testing your application with Java 1.5-b2 to see if the problem has indeed been fixed. Alternatively consider using IBM Java 1.4 or 3rd party JCE/JSSE implementations which _may_ not exhibit the same limitation HTH Oleg On Sat, 2004-06-12 at 05:36, Tim Wild wrote: Hi, I'm using HttpClient to connect to an apache server that requires certificates. When I use client and server certificates from my own CA with 1024 bit keys it works perfectly. When I get a commercial certificate with a longer key (4096 bits), I get the following error (full message below) when I connect to apache: javax.net.ssl.SSLProtocolException: java.io.IOException: subject key, Unknown key spec: Invalid RSA modulus size. Google produced one result, which talked about a maximum key size using the JCE of 2048 bits using the JDK 1.4.2 default policy files. Another site suggested getting the unrestricted policy files, so I got and installed them, but it doesn't seem to make any difference at all. Does anyone have any thought or suggestions? Half formed thoughs or ideas are welcome as it might give me a lead that I can follow myself. Thanks Tim Wild - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding Bug 20744
=0.7,*;q=0.7[\r][\n] [DEBUG] wire - - Proxy-Connection: keep-alive[\r][\n] [DEBUG] wire - - Host: azure.freeservers.com[\r][\n] [DEBUG] wire - - Cookie: $Version=0; usage=fm:1:20040619%2Csite_admin:1:20040619%2C; $Path=/cgi-bin/util/[\r][\n] [DEBUG] wire - - Cookie: $Version=0; LOGIN=YXp1cmUuZnJlZXNlcnZlcnMuY29tOm02bTZtNg%3D%3D; $Path=/[\r][\n] [DEBUG] wire - - Cookie: $Version=0; PostLH=9904507; $Path=/[\r][\n] [DEBUG] wire - - Cookie: $Version=0; aws_member=d795a0631c8117efbab1fbfdf9c38c07; $Path=/[\r][\n] [DEBUG] wire - - Content-Length: 751[\r][\n] [DEBUG] wire - - Content-Type: multipart/form-data; boundary=314159265358979323846[\r][\n] [DEBUG] wire - - [\r][\n] [DEBUG] wire - - -- [DEBUG] wire - - 314159265358979323846 [DEBUG] wire - - [\r][\n] [DEBUG] wire - - Content-Disposition: form-data; name= [DEBUG] wire - - [DEBUG] wire - - uploadfile1 [DEBUG] wire - - [DEBUG] wire - - ; filename= [DEBUG] wire - - [DEBUG] wire - - bom12.txt [DEBUG] wire - - [DEBUG] wire - - [\r][\n] [DEBUG] wire - - Content-Type: [DEBUG] wire - - application/octet-stream [DEBUG] wire - - ; charset= [DEBUG] wire - - ISO-8859-1 [DEBUG] wire - - [\r][\n] [DEBUG] wire - - [\r][\n] [DEBUG] wire - - bom12 [DEBUG] wire - - [\r][\n] [DEBUG] wire - - -- [DEBUG] wire - - 314159265358979323846 [DEBUG] wire - - [\r][\n] [DEBUG] wire - - Content-Disposition: form-data; name= [DEBUG] wire - - [DEBUG] wire - - submit [DEBUG] wire - - [DEBUG] wire - - [\r][\n] [DEBUG] wire - - [\r][\n] [DEBUG] wire - - Login! [DEBUG] wire - - [\r][\n] [DEBUG] wire - - -- [DEBUG] wire - - 314159265358979323846 [DEBUG] wire - - [\r][\n] [DEBUG] wire - - Content-Disposition: form-data; name= [DEBUG] wire - - [DEBUG] wire - - selector [DEBUG] wire - - [DEBUG] wire - - [\r][\n] [DEBUG] wire - - [\r][\n] [DEBUG] wire - - [\r][\n] [DEBUG] wire - - -- [DEBUG] wire - - 314159265358979323846 [DEBUG] wire - - [\r][\n] [DEBUG] wire - - Content-Disposition: form-data; name= [DEBUG] wire - - [DEBUG] wire - - viewer [DEBUG] wire - - [DEBUG] wire - - [\r][\n] [DEBUG] wire - - [\r][\n] [DEBUG] wire - - [\r][\n] [DEBUG] wire - - -- [DEBUG] wire - - 314159265358979323846 [DEBUG] wire - - [\r][\n] [DEBUG] wire - - Content-Disposition: form-data; name= [DEBUG] wire - - [DEBUG] wire - - destfolder1 [DEBUG] wire - - [DEBUG] wire - - [\r][\n] [DEBUG] wire - - [\r][\n] [DEBUG] wire - - Choose a Destination... [DEBUG] wire - - [\r][\n] [DEBUG] wire - - -- [DEBUG] wire - - 314159265358979323846 [DEBUG] wire - - [\r][\n] [DEBUG] wire - - Content-Disposition: form-data; name= [DEBUG] wire - - [DEBUG] wire - - destfolder2 [DEBUG] wire - - [DEBUG] wire - - [\r][\n] [DEBUG] wire - - [\r][\n] [DEBUG] wire - - Choose a Destination... [DEBUG] wire - - [\r][\n] [DEBUG] wire - - -- [DEBUG] wire - - 314159265358979323846 [DEBUG] wire - - -- [DEBUG] wire - - [\r][\n] [DEBUG] wire - - HTTP/1.1 200 OK[\r][\n] [DEBUG] wire - - Date: Sat, 19 Jun 2004 22:21:54 GMT[\r][\n] [DEBUG] wire - - Server: .V25 Apache/1.3.26 (Unix) mod_fs 6.005[\r][\n] [DEBUG] wire - - Partner-Revision: 1.345[\r][\n] [DEBUG] wire - - Transfer-Encoding: chunked[\r][\n] [DEBUG] wire - - Content-Type: text/html[\r][\n] [DEBUG] HttpConnection - -HttpConnection.getSoTimeout() [DEBUG] HttpMethodBase - -Buffering response body = end = __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail [attachment src.tar.gz deleted by Roland Weber/Germany/IBM] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invalid RSA modulus size
Hello Tim, not quite. If you read carefully, that paragraph addresses import restrictions, not export restrictions. It does not say that the 1.4.2 code does not have crypto limitations as a result of the US export regulations. No restrictions in the policy files means full strength of the implementation. If the implementation is crippled, that won't help you. cheers, Roland Tim Wild [EMAIL PROTECTED] 21.06.2004 07:23 Please respond to Commons HttpClient Project To Commons HttpClient Project [EMAIL PROTECTED] cc Subject Re: Invalid RSA modulus size Thanks Roland, I just re-read the documentation that comes with the Unlimited Strength Jurisdiction Policy Files, and it indicates that they do enable full strength crpytography based on the configuration file. I've included the applicable paragraph below. Does anyone else have thoughts on this? It works fine in JDK 1.5 but not 1.4, which would indicate to me that it's a bug rather than it being disabled. The exception i'm getting in JDK 1.4.2 is javax.net.ssl.SSLProtocolException: java.io.IOException: subject key, Unknown key spec: Invalid RSA modulus size Thanks Tim --- The JCE architecture allows flexible cryptographic strength to be configured via jurisdiction policy files. Due to the import restrictions of some countries, the jurisdiction policy files distributed with the J2SDK, v 1.4.2 software have built-in restrictions on available cryptographic strength. The jurisdiction policy files in this download bundle (the bundle including this README file) contain no restrictions on cryptographic strengths. This is appropriate for most countries. Framework vendors can create download bundles that include jurisdiction policy files that specify cryptographic restrictions appropriate for countries whose governments mandate restrictions. Users in those countries can download an appropriate bundle, and the JCE framework will enforce the specified restrictions. --- - Original Message - From: Roland Weber [EMAIL PROTECTED] Date: Monday, June 21, 2004 5:06 pm Subject: Re: Invalid RSA modulus size Hello Tim, from what I know about the export regulations, shipping working crypto code that is just disabled through some configuration file is not acceptable. You will have to obtain a full-strength JCE/JSSE implementation. Either a US-only version of the JDK, or a non-US implementation of the library which is not subject to US or other export restrictions on cryptography. cheers, Roland Tim Wild [EMAIL PROTECTED] 21.06.2004 05:19 Please respond to Commons HttpClient Project To Commons HttpClient Project [EMAIL PROTECTED] cc Subject Re: Invalid RSA modulus size Does anyone know if the Unlimited Strength Jurisdiction Policy Files are meant to solve this problem, or is it actually a bug with the JDK1.4? The policy files don't help me at all on the JDK1.4. Thanks Tim Oleg Kalnichevski wrote: Tim, This is believed to be a limitation of all Sun's JCE/JSSE implementations up to Java version 1.5. You can try testing your application with Java 1.5-b2 to see if the problem has indeed been fixed. Alternatively consider using IBM Java 1.4 or 3rd party JCE/JSSEimplementations which _may_ not exhibit the same limitation HTH Oleg On Sat, 2004-06-12 at 05:36, Tim Wild wrote: Hi, I'm using HttpClient to connect to an apache server that requires certificates. When I use client and server certificates from my own CA with 1024 bit keys it works perfectly. When I get a commercial certificate with a longer key (4096 bits), I get the following error (full message below) when I connect to apache: javax.net.ssl.SSLProtocolException: java.io.IOException: subject key, Unknown key spec: Invalid RSA modulus size. Google produced one result, which talked about a maximum key size using the JCE of 2048 bits using the JDK 1.4.2 default policy files. Another site suggested getting the unrestricted policy files, so I got and installed them, but it doesn't seem to make any difference at all. Does anyone have any thought or suggestions? Half formed thoughs or ideas are welcome as it might give me a lead that I can follow myself. Thanks Tim Wild - 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] --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Attention: The information contained in this message and or attachments is intended only for the person or entity to which it is addressed
Re: HttpClient 2.0 problems
Hello Arturo,
what exactly do you chance when it works?
From a quick look at the code, I suggest the
following modifications:
- don't recycle the method, create a new one
- invoke releaseConnection() in a finally block,
no matter whether there was an exception or not
The unable to find line starting with HTTP has
been mentioned in other recent posts. Are you
by any chance using the HttpClient from
different threads, without having installed the
MultiThreadedConnectionManager ?
cheers,
Roland
Arturo Esquivel Sanchez [EMAIL PROTECTED]
10.06.2004 12:19
Please respond to
Commons HttpClient Project
To
[EMAIL PROTECTED]
cc
Subject
HttpClient 2.0 problems
Hi,
The problem that im having is that sometimes i get the following error
when trying to connect to url, and then i change something in my code and
suddenly works fine, then i change something again and i get again the
same error (¿?), if a loop in my code in order to get a response other
than -1 it doesn´t work and i get a lots of the error.
This is the error:
[INFO] HttpMethodBase - -Recoverable exception caught when processing
request [WARN] HttpMethodBase - -Recoverable exception caught but
MethodRetryHandler.ret ryMethod() returned false, rethrowing exceptionA
recoverableexception occurred, retrying.
org.apache.commons.httpclient.Http RecoverableException: Error in parsing
the status line from the response: unabl e to find line starting with
HTTP
This is the code that im using:
boolean retry=false;
do{
statusCode = Procesa_Get_Url(url, client, config, state,
urlToConnect2, respHTML1);
if (statusCode != -1 urlToConnect2.toString().trim() !=
urlToConnect2.toString().trim().length() != 0){
retry=true;}
}while (retry==false);
private int Procesa_Get_Url(String urlProc, HttpClient clientProc,
HostConfiguration configProc, HttpState stateProc, StringBuffer urlTC,
StringBuffer respHTML) throws Exception {int statusCode=-1;
String redirectLocation=null;
clientProc.setTimeout(60*30*1000);
clientProc.setHttpConnectionFactoryTimeout(60*30*1000);
clientProc.setConnectionTimeout(60*30*1000);
//try{
//URI uri = new URI(urlProc.toCharArray());
URI uri = new URI(urlProc.toCharArray());
HttpMethod method = new GetMethod(uri.toString());
String schema = uri.getScheme();
if ((schema == null) || (schema.equals())){
schema = http;
}
Protocol protocol = Protocol.getProtocol(schema);
String host = uri.getHost();
int port = uri.getPort();
configProc.setHost(host,port,protocol);
configProc.setProxy(System.getProperty(http.proxyHost),Integer.parseInt(System.getProperty(http.proxyPort,80)));
stateProc.setProxyCredentials(null, null,
new UsernamePasswordCredentials(
System.getProperty(http.proxyUserName),
System.getProperty(http.proxyPassword)));
int attempt=0;
boolean retry=false;
//do{
//for (attempt = 0; statusCode == -1 attempt 3; attempt++) {
try{
statusCode =
clientProc.executeMethod(configProc,method,stateProc); //if
(statusCode != -1){ // retry=true;
//}
} catch (HttpRecoverableException e) {
method.recycle();
method.releaseConnection();
System.out.println(A recoverable exception occurred,
retrying. + e.getMessage());} catch
(IOException e) {
System.err.println(Failed to download file.);
e.printStackTrace();
}catch (Exception e) {
System.err.println(Errorsote.);
e.printStackTrace();
}
//}while (retry=false);
if (statusCode == -1) {
System.err.println(Numero de Intentos: + attempt);
System.err.println(Failed to recover from exception.);
}
switch (statusCode){
case 200 : stateProc.setCookiePolicy(CookiePolicy.RFC2109);
Cookie[] cookies = stateProc.getCookies();
System.out.println(Present cookies: );
for (int i = 0; i cookies.length; i++) {
System.out.println( - +
cookies[i].toExternalForm());}
urlTC.append(method.getURI().toString());
respHTML.append(method.getResponseBodyAsString());
break;
case 302 : stateProc.setCookiePolicy(CookiePolicy.RFC2109);
Cookie[] cookies2 = stateProc.getCookies();
System.out.println(Present cookies: );
for (int i = 0; i cookies2.length; i++) {
System.out.println( - +
cookies2[i].toExternalForm());}
Header
Re: HttpException question
Hello Xavier, if the server sends an HTTP status code, there is no need for an exception. Just use HttpMethod.getStatusCode(). If there is an exception, there is no status code to include in the message. Unless you throw your own exception, in which case you are free to generate every message you consider useful. cheers, Roland Xavier Frisaye [EMAIL PROTECTED] 14.06.2004 08:48 Please respond to Commons HttpClient Project To Commons HttpClient Project [EMAIL PROTECTED] cc Subject HttpException question Hi, I would like to have in the message of an HttpException the reason (http) code. Do you think it could be useful or not? Regards, Xavier Frisaye - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Retrieving server side certificate durring handshake?
Hello Marc, the latter is the case. For the HTTP protocol, the certificate doesn't matter. Once the secure connection is established, HttpClient just uses it. Whether any certificates were involved when the factory established the connection is of no interest to HttpClient. You may have to implement your own protocol factory. Whether it will be possible to determine the factory level information for a connection, I cannot tell. If not, let us know and we'll discuss what hooks should be added. cheers, Roland Marc Boorshtein [EMAIL PROTECTED] 07.06.2004 14:43 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:Retrieving server side certificate durring handshake? Hello, I have the http libraries working with SSL, but I need to be able to retrieve the server's certificate on connection. I looked at the easy ssl protocol handler, but I didn't see anything that let me do this. Am I missing something, or is this handled at the JSSE level? Thanks -- Marc Boorshtein Sr. Software Engineer, Octet String [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authenticate problem
Hello Jing, null is the default realm, where the HttpClient looks if there are no credentials for the specific realm, or if it doesn't know the realm because it performs preemptive authentication. Why the server accepts empty credentials is a different question. Probably a misconfiguration on the server side. Did you verify by wire log that the authentication actually takes place? Maybe the state holds a session cookie from a previous request and the server does not require authentication for the following ones. For example, WebSphere Application Server would behave like that if an LTPA cookie is sent by the client. hope that helps, Roland Jing Chen [EMAIL PROTECTED] 03.06.2004 00:06 Please respond to Commons HttpClient Project To: Commons HttpClient Project (E-mail) [EMAIL PROTECTED] cc: Subject:authenticate problem I have an application that requires authentication. I user a timer to schedule a task that will access the same application through httpClient. I am surprised to see the following statement did pass the authentication: client.getState().setCredentials (null,new UsernamePasswordCredentials()); 1. Can anybody explain why? 2. I did a little experiement - if I don't call authenticate(), then the client.executeMethod(new PostMethod(http://myapp.com/myapp)) will fail becaue no credentials available for realm x at host xxx. However, if I call authenticate(), even to authenticate empty credential with null realm, I get pass for the next client.executeMethod(...). Why can I get authenticated on realm x while I only did authentication for null?? Thanks Jing
Re: HttpConnection and HttpState reuse problem
Hello Himanshu,
you can create your own HttpState object and pass it
to each method invocation. That should solve your first
problem.
Why don't you leave the connection re-use to the
connection manager? For an application, it shouldn't
matter at all whether it is the same or a different
connection. If it is an absolute requirement, you can
still implement your own connection manager.
cheers,
Roland
Himanshu Thube [EMAIL PROTECTED]
03.06.2004 18:24
Please respond to Commons HttpClient Project
To: [EMAIL PROTECTED]
cc:
Subject:HttpConnection and HttpState reuse problem
Hi
In my class I need two connections to same host and different URL's. For
connecting first time, I want to get the HttpState and HttpConnection.
Later just execute the method using the same HttpConnection and HttpState.
However from API I found, to get the state I need to execute the method
with HttpClient for the first time as only HttpClient is able to return
the HttpState. For the later executions of GetMethod I am not able to
reuse the HttpConnection used for first execution as HttpClient doesn't
provide me a handle to the HttpConnection which it used for first
execution.
My existing code is as follows :
*For first invocation *:
httpsclient = new HttpClient();
int statusCode = -1;
String [] response=new String[2];
httpsget = new GetMethod(uri.toString());
statusCode = httpsclient.executeMethod(httpsget);
state=httpsclient.getState();
*For Later invocations : (now I have the HttpsState but no handle to
HttpConnection used :( so have to create a new HttpConnection)*
if(con==null) {
try {
con=new HttpConnection(uri.getHost(), uri.getPort(),
getProtocol());
} catch (URIException e1) {
e1.printStackTrace();
}
}
try {
httpsget.recycle();
httpsget.setPath(connectUrl);
httpsget.execute(state, con);
} catch (IOException e) {
e.printStackTrace();
}
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: Connection Accounting Problem
Hi Mike,
deprecate getConnectionsInUse(),
replace with getConnectionsInPool() ?
Introduce something like
garbageCollectConnections() or
deleteIdleConnections()
for people who really want to throw
away the closed connections ?
I'd stick with your option 1 until there
is a case where the other behavior is
actually needed.
cheers,
Roland
Michael Becke [EMAIL PROTECTED]
01.06.2004 03:14
Please respond to Commons HttpClient Project
To: Commons HttpClient Project
[EMAIL PROTECTED]
cc:
Subject:Re: Connection Accounting Problem
Hi Satya,
Sorry for the slow response... The number of connections in use does
not get decremented in this case as no connections are actually being
destroyed. The connection manager still holds references to the same
number of connections after closeIdleConnections() is called.
connectionsInUse is meant to detail the number of connections that have
been allocated, not the number that are open. Given these semantics
the behavior is correct I believe.
The next question is if this makes sense. I see two possibilities here:
1) Document getConnectionsInUse() to better describe the current
behavior.
2) Change closeIdleConnections() to delete closed connections. This
will require changes to the IdleConnectionHandler, so that we know
which connections are closed.
Any suggestions or preferences?
Mike
On May 27, 2004, at 5:27 PM, [EMAIL PROTECTED] wrote:
After Calling
MultiThreadedHttpConnectionManager.closeIdleConnections(idleTime), the
timedout connections are closed, however, connectinon count does not
decrease.
Therefore, if I call
MultiThreadedHttpConnectionManager.getConnectionsInUse(), I still get
the same value as before calling closeIdleConnections(). After a bit
of code browsing the problem seems to be in the following code:
public synchronized void closeIdleConnections(long idleTimeout) {
idleConnectionHandler.closeIdleConnections(idleTimeout);
}
Which does not decrease the number of connections after actually
removing them.
The code should be:
public synchronized void closeIdleConnections(long idleTimeout) {
idleConnectionHandler.closeIdleConnections(idleTimeout);
//Now do the connection accounting (Pseudo code)
numConnections = idleConnectionHandler.getConnectionsCount();
//Also adjust the hostPool.numConnections
}
Any taker?
--Satya
-
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]
Re: does HttpClient transparently send proxy auth after getting HTTP 403 code?
Hello Alex, HttpClient can send the authentication data automatically. Use HttpMethod.setDoAuthentication(true) to tell it to. You may want to set the credentials for the particular host and port of the proxy, rather than as default credentials. This will prevent them from being sent to the wrong host. cheers, Roland Alex Hunsley [EMAIL PROTECTED] 27.05.2004 12:27 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:does HttpClient transparently send proxy auth after getting HTTP 403 code? I hope this is an approriate list for this question, if not, please accept my apologies! I'm running HttpClient 2.0 with j2sdk1.4.2_03. I'm using HttpClient to access web pages via an http proxy server that needs basic proxy authorization (note: it's the *proxy* that needs auth, not the end-target web server. I add this because I have got confused myself sometimes over this!) I'm debugging my HttpClient-using code by pointing it at a local proxy (I'm running 'Charles') and from this I can see that my request is *not* providing proxy authorization information. If, however, I call: httpClient.getState().setAuthenticationPreemptive(true); to enable pre-emptive authorization, my test proxy does receive the authorization. I had no idea that the preeptive authorization also applies to the proxy authorization as the docs don't make this clear (and if this is indeed the case, a clarification in the docs might be handy). My main question is: if I don't call setAuthenticationPreemptive(true), and if HttpClient tries to use a proxy and receives an HTTP 403 (proxy auth required) message back, will it transparently then give the proxy auth that I have set, or will it just give me the 403 code it received? As far as I can see, it is just giving me the 403 code back, so I don't understand why it doesn't just always give the proxy auth up front as a matter of convenience! I hope someone can clarify this and thanks for reading! alex p.s. I have had no luck at all finding a simple proxy that is runnable under cygwin or windows that will let me enable basic proxy authorization so I can test this. All I know that is my proxy authorization wasn't working in a client's office - I was getting HTTP 403 - despite me setting the proxy auth in my request (but not putting .setAuthenticationPreemptive(true)). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sun's javax.net.ssl and HttpClient
Hello Himanshu, Http Client and javax.net.ssl are in no way comparable at all. SSL is a technique to secure connections on the transport layer. HTTP is a protocol for client/server communication, which runs on top of a transport layer. By combining HTTP and SSL, you get HTTPS. For example, you can use the HttpClient to communciate over an SSL connection from javax.net.ssl. The HttpURLConnection in the standard JDKs is flawed because it does not provide flexibility with respect to timeout handling, multithreading, connection pooling, streaming, HTTP protocol versions and server specific dialects, authentication, error handling, retry handling, and probably plenty of other things I forgot. The HttpsURLConnection from javax.net.ssl is the same as the HttpURLConnection, except that it uses SSL instead of plain sockets for the transport layer. HttpClient uses a generic interface to create SSL connections when needed for HTTPS connections. It is up to you to implement this interface, and you can support SSL session reuse if you want to. You can also implement your own HTTP connection pool, which can be aware of your SSL connection pool to optimize reuse. hope that helps, Roland Himanshu Thube [EMAIL PROTECTED] 19.05.2004 17:47 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:Sun's javax.net.ssl and HttpClient Hi I am trying to suggest Apache Http client library against SUN javax.net.ssl for our application, our application requirement is as follows : 1. SSL support 2. Reuse the SSLSession / HttpState while reconnecting to web server (Apache) 3. Restablishing Http(s) connection multiple times to web server 4. HttpClient should have same behaviour like a Browser (IE) 5. Asynchronous communication where Http client opens connection and should recieve data from server whenever server has some data for http client. 6. Other requirements are Performance, etc.. From the web I found few comparisons but some of them were vague (e.g. One features page of Http client it is written The jdk has the HttpUrlConnection which is limited and in many ways flawed) but there is no concrete explaination for this. Another comparison link http://www.nogoop.com/product_16.html#compare does not provide sufficient comparison for my requirement. Can someone provide concrete link or information, about comparison between Apache Http client library against SUN javax.net.ssl for my requirements ? For my requirement, I came up with only one valid point where Apache Http client library provides a API where I can associate HttpState with Http(s) connection. I guess if I dig more into JDK I will also find a way to do this over there. One more question - Does HttpState contain the Credentials ? Does this also contain SSL information (certificates, etc...) It is just a marker interface at the moment. So does it contain certificates, etc... like SUN's SSLSession ? Regards Himanshu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient initialization, when/where?
Hello, you need one HttpState for each thread, since the cookies are stored there. Creating a new state for each request will not work, unless the threads manage the cookies themselves. The HttpClient is associated with a connection pool. If you require independently configured connection pools for each thread, you have to create multiple HttpClient objects. Otherwise, one HttpClient with MultiThreadedHCM is ok. hope that helps, Roland Cabbar Duzayak [EMAIL PROTECTED] 12.05.2004 09:32 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:HttpClient initialization, when/where? Hi, I will be writing a gateway which will invoke URLs in behalf of several threads and they will return the content. Each thread needs to invoke different URLs with different context (cookies, etc). It looks like right way of doing this is to instantiate the HttpClient once with MultiThreadedHttpConnectionManager and each thread will use httpClient.executeMethod on this HttpClient instance. Or the other alternative is to instantiate one object for each thread, and keep calling executeMethods on them. However, since you can set the state of the HttpClient, I was wondering if I can use the HttpClient for iterative http invocations with different contexts? I mean, is there an in-memory state other than the HttpState that is preserved between these invocations? Would it be enough to create an HttpState and GetMethod for each call, and set it before calling executeMethod? Shortly, what is the optimum mechanism for this functionality? TIA... __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient initialization, when/where?
Hi Duzayak (?), the MultiThreadedHCM is called so because it allows for multiple threads to use the same HttpClient. It has to be used if the application is multithreaded. The connection pool limits the number of simultaneous connections, to a particular host and in general. It keeps resource usage in check. Also, if there are many requests to the same host, open connections may be reused, which avoids the overhead of establishing a new connection for each request. If you want to know how it works, feel free to look at the source code. It's open :-) cheers, Roland Cabbar Duzayak [EMAIL PROTECTED] 12.05.2004 12:26 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: HttpClient initialization, when/where? Can you please elaborate a bit how this connection pool and multithreaded HCM work? Cause, given that httpclient will be executed within my thread, why do we need a multithreaded HCM? Also, connection pool is used for sharing connections between threads? How exactly does it work, what does it improve? Thanks a lot for the information!
Re: Bug in HTTPUrl?
Hi Oleg, see RFC 2396, URI: Generic Syntax, section 3.2.2: userinfo@host:port Some URL schemes use the format user:password in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used. cheers, Roland Oleg Kalnichevski [EMAIL PROTECTED] 27.04.2004 18:44 Please respond to Commons HttpClient Project To: Jakarta Commons HttpClient mailing list [EMAIL PROTECTED] cc: Subject:Re: Bug in HTTPUrl? Folks, Any idea what to do with one? First of all, user name and password in HTTP url is something completely new to me. Any idea what Sung-Gu had in mind? Oleg On Fri, 2004-04-02 at 16:08, Gustav Munkby wrote: hi, If I do: HTTPUrl url = new HTTPUrl(kurt, nicepass#, hostname, 80, path); throws a URIException with message port number invalid. First of all the message is wrong... Next attempt was to urlencode the password, which resulted in the above line working, but the password was sent url-encoded to the destination, which can hardly be the desired behaviour? regards, Gustav Munkby - 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]
RE: customizing debugging levels per httpclient instance
Hi Oleg, abstraction is good, abstraction layers are even better... But seriously: no need for NDC support in HttpClient. My application provides it's own logging framework, so I can use the thread context to pass information from my application to my logging framework, through and without help from the HttpClient layer. What I'd like to think about for 4.0 is to get away from plenty of static loggers in the classes, to dynamic loggers that can be configured differently for different instances of HttpClient. Kind of like the wire log, which also transcends class boundaries. Except that it is still a global wire log, which will combine wire output from different connections and clients. The static class loggers are nice to activate logging for parts of the framework, while leaving it disabled for others. To what degree is this feature used by you and the other developers of HttpClient? On the mailing list, we usually ask people for a wire log, or to switch on logging in general. Or maybe it's easier to just include some context in each log message. For example by giving HttpClient instances names, and logging the name each time. ...and giving connections numbers, logging the number each time... this is beginning to sound like an NDC implementation directly in the HttpClient. I better stop now ;-) cheers, Roland Oleg Kalnichevski [EMAIL PROTECTED] 27.04.2004 16:22 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:RE: customizing debugging levels per httpclient instance Roland, As long as NDC is not supported by commons-logging HttpClient will not be able to take full advantage of it. We can still think about some sort of workaround as long as it does not make stock version of HttpClient dependent on any particular logging toolkit. One idea that springs to mind is to provide logging as an aspect using AspectJ or similar Another possibility is, of course, introduce a logging toolkit abstraction layer and abstract commons-logging away ;-))) Oleg On Tue, 2004-04-27 at 15:39, Roland Weber wrote: Hi Gareth, thanks a lot for the pointer. The concept is very close to what I need. The problem is that I'm not using log4j, since the application uses a different logging framework. But I might borrow the idea of attaching some context to the thread in my application. thanks again, Roland [EMAIL PROTECTED] 27.04.2004 15:20 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:RE: customizing debugging levels per httpclient instance Best solution I've come up with for this sort of thing is to use Nested Diagnostic Context's (NDC) in log4j have a look at the section on them in: http://logging.apache.org/log4j/docs/manual.html Not quite what you want I know, but it will give you something to grep on. Gareth Roland Weber [EMAIL PROTECTED] com To Commons HttpClient Project 27/04/2004 14:12 [EMAIL PROTECTED] che.org cc Please respond to Commons Subject HttpClient RE: customizing debugging levels Project per httpclient instance commons-httpclie [EMAIL PROTECTED] ache.org Hi Oleg, I had a similar problem when I started using HttpClient last year. Not thread-based though. I'm in a servlet engine, so I don't know which thread will be processing the request that uses HttpClient. I'd like to have different log settings per HttpClient instance, but that's not possible because they all use the same static loggers. It's not a big issue for me now, since I have enough application level tracing. But if someone has an idea how this problem could be solved once and for all, it might be worth considering for 4.0. Like creating a logger for each HttpClient instance instead of each implementation class. Or falling back to the class logger only if no instance logger is configured in the params. cheers, Roland Kalnichevski, Oleg [EMAIL PROTECTED] 26.04.2004 18:34 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:RE: customizing debugging levels per httpclient instance Jorrit, HttpClient relies on commons-logging toolkit to do all its logging. The commons-logging itself is merely an abstraction layer intended to provide a uniform interface to different logging toolkits. If there is a toolkit capable of assigning different appenders on per thread basis, then HttpClient can be configured to take advantage of it. To my best
Re: Bug in HTTPUrl?
Hi Ortwin, the quote was not meant as an estimation. Just a hint why that part of the URI spec might be less well known as others. BTW, the section also defines the valid characters: userinfo = *( unreserved | escaped | ; | : | | = | + | $ | , ) cheers, Roland Ortwin Glück [EMAIL PROTECTED] 28.04.2004 08:23 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: Bug in HTTPUrl? Roland Weber wrote: Hi Oleg, see RFC 2396, URI: Generic Syntax, section 3.2.2: userinfo@host:port Some URL schemes use the format user:password in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used. cheers, Roland Roland, of course it is out of question that this poses security problems. But this fact does not make the URI classes less buggy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Yahoo login with Httpclient
Hello Frank,
the problem with the Sun site is that HttpClient does not
support cross host redirects. See here for directions:
http://jakarta.apache.org/commons/httpclient/redirects.html
For Yahoo with it's HTTPS URL, you have to install or
enable SSL support. See here for directions:
http://jakarta.apache.org/commons/httpclient/sslguide.html
cheers and good luck,
Roland
Min (Frank) Ni [EMAIL PROTECTED]
28.04.2004 16:28
Please respond to Commons HttpClient Project
To: Commons HttpClient Project
[EMAIL PROTECTED], [EMAIL PROTECTED]
cc:
Subject:RE: Yahoo login with Httpclient
Hi Oleg:
Thanks for your reply. Two days ago I tried the FormLoginDemo, but after I
saw your e-mail I tried again and got the following response, with my Sun
Developer Id and password :
===
Login form get: HTTP/1.1 200 OK
Initial set of cookies:
None
Apr 28, 2004 10:05:24 AM org.apache.commons.httpclient.HttpMethodBase
processRedirectResponse
INFO: Redirect requested but followRedirects is disabled
Login form post: HTTP/1.1 302 Moved Temporarily
Logon cookies:
- JDC=5719750140229660595
- JSESSIONID=developer.java.sun.com-e7b9%253A408fba23%253Af8cfb4dd3166b6ce
- SessionCredentials=5213651892774654901
Redirect target: http://developer.java.sun.com/index.html
Apr 28, 2004 10:05:24 AM org.apache.commons.httpclient.HttpMethodBase
checkValidRedirect
WARNING: Error getting URI host
org.apache.commons.httpclient.HttpException: Redirect from host
developer.java.sun.com to java.sun.com is not supported
at
org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMethodBase.java:1243)
at
org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(HttpMethodBase.java:1191)
at
org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBase.java:977)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1095)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:675)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529)
at FormLoginDemo.main(FormLoginDemo.java:124)
Apr 28, 2004 10:05:24 AM org.apache.commons.httpclient.HttpMethodBase
processRedirectResponse
WARNING: Invalid Redirect URI from:
http://developer.java.sun.com:80/index.html to: http://java.sun.com/
Redirect: HTTP/1.1 302 Moved Temporarily
===
The probelm with Yahoo login is even harder to understand, it seems Yahoo
redirects several times, and it requires cookies, I tried the following
lines, but it won't work :
===
System.getProperties().put(java.protocol.handler.pkgs,
HTTPClient);
String url=https://login.yahoo.com/config/login;;
//String url=http://f1.pg.briefcase.yahoo.com/;;
HttpClient client = new HttpClient();
HttpMethod method = new GetMethod(url);
try
{
// URL url=new URL(https://login.yahoo.com/config/login;);
/* String Msg_Out=.fUpdate=1\n+
.tries=1\n+
.done=http://f1.pg.briefcase.yahoo.com/\n+
.src=bc\n+
.intl=us\n+
login=javamr\n+
passwd=javatest\n+
submit=Login;
String Msg_Out=.fUpdate=1+
.tries=1+
.done=http://f1.pg.briefcase.yahoo.com/+
.src=bc+
.intl=us+
login=javamr+
passwd=javatest+
submit=Login;
// WriteFile Write_File=new WriteFile(url,Msg_Out);
// taText.append(Write_File.Text_In.toString());
// NM_Lib.Display_HTML_In_Browser(Write_File.Text_In.toString());
// method.setQueryString(Msg_Out);
*/
NameValuePair N_V_P[]= { new NameValuePair(.fUpdate,1),
new NameValuePair(.tries,1),
new NameValuePair(.done,
http://f1.pg.briefcase.yahoo.com/;),
new NameValuePair(.src,bc),
new NameValuePair(.intl,us),
new NameValuePair(login,javamr),
new NameValuePair(passwd,javatest),
new NameValuePair(submit,Login)
};
method.setQueryString(N_V_P);
client.executeMethod(method);
}
catch (Exception e) { System.out.println(e.toString()); }
String responseBody = method.getResponseBodyAsString();
method.releaseConnection();
//NM_Lib.Display_HTML_In_Browser(responseBody);
}
RE: customizing debugging levels per httpclient instance
Hi Oleg, I had a similar problem when I started using HttpClient last year. Not thread-based though. I'm in a servlet engine, so I don't know which thread will be processing the request that uses HttpClient. I'd like to have different log settings per HttpClient instance, but that's not possible because they all use the same static loggers. It's not a big issue for me now, since I have enough application level tracing. But if someone has an idea how this problem could be solved once and for all, it might be worth considering for 4.0. Like creating a logger for each HttpClient instance instead of each implementation class. Or falling back to the class logger only if no instance logger is configured in the params. cheers, Roland Kalnichevski, Oleg [EMAIL PROTECTED] 26.04.2004 18:34 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:RE: customizing debugging levels per httpclient instance Jorrit, HttpClient relies on commons-logging toolkit to do all its logging. The commons-logging itself is merely an abstraction layer intended to provide a uniform interface to different logging toolkits. If there is a toolkit capable of assigning different appenders on per thread basis, then HttpClient can be configured to take advantage of it. To my best knowledge Log4j cannot assign individual appenders to different threads within the same application (within the same class loader context rather). You may consider evaluating a different logging toolkit that provides such a feature, or file a feature request with the Log4j project. Oleg -Original Message- From: Jorrit Kronjee [mailto:[EMAIL PROTECTED] Sent: Monday, April 26, 2004 13:19 To: [EMAIL PROTECTED] Subject: customizing debugging levels per httpclient instance Hello, I have an application consisting of two threads. Both threads have an own instance of httpclient and use it for different things. I would like to see the wire of one of the threads, but suppress the other. I use log4j. log4j can set the debugging level (trace or not) based on package/class names. I was wondering if it's possible to set the class name for http client, so i can customize my debugging per thread. Or perhaps I'm not understanding it correctly. If this is not possible, I would like to make this a feature request. Thanks in advance, Jorrit Kronjee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: customizing debugging levels per httpclient instance
Hi Gareth, thanks a lot for the pointer. The concept is very close to what I need. The problem is that I'm not using log4j, since the application uses a different logging framework. But I might borrow the idea of attaching some context to the thread in my application. thanks again, Roland [EMAIL PROTECTED] 27.04.2004 15:20 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:RE: customizing debugging levels per httpclient instance Best solution I've come up with for this sort of thing is to use Nested Diagnostic Context's (NDC) in log4j have a look at the section on them in: http://logging.apache.org/log4j/docs/manual.html Not quite what you want I know, but it will give you something to grep on. Gareth Roland Weber [EMAIL PROTECTED] com To Commons HttpClient Project 27/04/2004 14:12 [EMAIL PROTECTED] che.org cc Please respond to Commons Subject HttpClient RE: customizing debugging levels Project per httpclient instance commons-httpclie [EMAIL PROTECTED] ache.org Hi Oleg, I had a similar problem when I started using HttpClient last year. Not thread-based though. I'm in a servlet engine, so I don't know which thread will be processing the request that uses HttpClient. I'd like to have different log settings per HttpClient instance, but that's not possible because they all use the same static loggers. It's not a big issue for me now, since I have enough application level tracing. But if someone has an idea how this problem could be solved once and for all, it might be worth considering for 4.0. Like creating a logger for each HttpClient instance instead of each implementation class. Or falling back to the class logger only if no instance logger is configured in the params. cheers, Roland Kalnichevski, Oleg [EMAIL PROTECTED] 26.04.2004 18:34 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:RE: customizing debugging levels per httpclient instance Jorrit, HttpClient relies on commons-logging toolkit to do all its logging. The commons-logging itself is merely an abstraction layer intended to provide a uniform interface to different logging toolkits. If there is a toolkit capable of assigning different appenders on per thread basis, then HttpClient can be configured to take advantage of it. To my best knowledge Log4j cannot assign individual appenders to different threads within the same application (within the same class loader context rather). You may consider evaluating a different logging toolkit that provides such a feature, or file a feature request with the Log4j project. Oleg -Original Message- From: Jorrit Kronjee [mailto:[EMAIL PROTECTED] Sent: Monday, April 26, 2004 13:19 To: [EMAIL PROTECTED] Subject: customizing debugging levels per httpclient instance Hello, I have an application consisting of two threads. Both threads have an own instance of httpclient and use it for different things. I would like to see the wire of one of the threads, but suppress the other. I use log4j. log4j can set the debugging level (trace or not) based on package/class names. I was wondering if it's possible to set the class name for http client, so i can customize my debugging per thread. Or perhaps I'm not understanding it correctly. If this is not possible, I would like to make this a feature request. Thanks in advance, Jorrit Kronjee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system
Re: HttpClient for Https gives Unrecognized SSL message..
Hello Raj, could you post a code example? I am a bit confused about the https for the same link part. The protocol is usually part of the link. If you managed to convice HttpClient to use SSL, while the server still believes it is plain HTTP, that would explain the error message. cheers, Roland Raj, Bhalla [EMAIL PROTECTED] 19.04.2004 11:41 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:HttpClient for Https gives Unrecognized SSL message.. Hi , Please Help. I am using HttpClient and i am able to successfully send http request and receive response. But when i try to send https request for the same link i get the following error(I am able to successfully send https request and response through the browser. ). javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection? javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection? at com.sun.net.ssl.internal.ssl.InputRecord.b(DashoA6275) at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275) at org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(HttpC onnection.java:1347) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127) at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpCo nnection.java:782) at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.jav a:2173) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.j ava:2528) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:106 5) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:638) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:500) at com.travelocity.component.net.http.SimpleHttpConnectionManager.execute(Simpl eHttpConnectionManager.java:68) I have tried the steps mentioned in SSL guide: http://jakarta.apache.org/commons/httpclient/sslguide.html with no luck.Can this happen if the certificate is not trusted . My jdk version is 1.4 and Please suggest steps to debug and bring it running. Any help would be highly appreciated. Thanks Raj - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HttpClient for Https gives Unrecognized SSL message..
Hello Raj,
I take it that you are connecting to the following URLs:
http://10.248.193.151:80/services/tvly/mmh.cgi/
https://10.248.193.151:443/services/tvly/mmh.cgi/
which rules out my suspicion that you might be connected
to port 80 via SSL. Could you please try to generate a wire log?
http://jakarta.apache.org/commons/httpclient/logging.html
The Java trace you sent does not give us the information
about the HttpClient that we need.
cheers,
Roland
Raj, Bhalla [EMAIL PROTECTED]
19.04.2004 12:50
Please respond to Commons HttpClient Project
To: Commons HttpClient Project
[EMAIL PROTECTED]
cc:
Subject:RE: HttpClient for Https gives Unrecognized SSL
message..
Hi Roland,
Thanks for response .
What i meant was when i use http it work fine but when i use https it
gives error.
Server is properly configured for https reuest because when i send from
browser https request i get proper response
here is the sample code.
HttpClient client = new HttpClient( );
HttpMethod httpMethod =
SimpleHttpConnectionManagerUtil.createHttpMethod( httpRequest );
statusCode = client.executeMethod( httpMethod );
***(This is are custom classes for Httprequest.. this is passes above in
createHttpMethod)
HttpRequest httpRequest = new HttpRequest( );
String url_i=https://10.248.193.151:443/services/tvly/mmh.cgi/;;
httpRequest.setUrl(url_i);
httpRequest.setMethod(HttpRequestMethod.GET);
HttpRequestParameter[ ] requestParameters =
{ new HttpRequestParameter(
method, _method ), new HttpRequestParameter(xml,xmlRequest) };
*
-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 4:11 PM
To: Commons HttpClient Project
Subject: Re: HttpClient for Https gives Unrecognized SSL message..
Hello Raj,
could you post a code example? I am a bit confused
about the https for the same link part. The protocol
is usually part of the link. If you managed to convice
HttpClient to use SSL, while the server still believes
it is plain HTTP, that would explain the error message.
cheers,
Roland
Raj, Bhalla [EMAIL PROTECTED]
19.04.2004 11:41
Please respond to Commons HttpClient Project
To: [EMAIL PROTECTED]
cc:
Subject:HttpClient for Https gives Unrecognized SSL
message..
Hi ,
Please Help.
I am using HttpClient and i am able to successfully send http request and
receive response.
But when i try to send https request for the same link i get the
following
error(I am able to successfully send https request and response through
the
browser. ).
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?
at com.sun.net.ssl.internal.ssl.InputRecord.b(DashoA6275)
at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
at
org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(HttpC
onnection.java:1347)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69)
at
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127)
at
org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpCo
nnection.java:782)
at
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.jav
a:2173)
at
org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.j
ava:2528)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:106
5)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:638)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:500)
at
com.travelocity.component.net.http.SimpleHttpConnectionManager.execute(Simpl
eHttpConnectionManager.java:68)
I have tried the steps mentioned in SSL guide:
http://jakarta.apache.org/commons/httpclient/sslguide.html
with no luck.Can this happen if the certificate is not trusted .
My jdk version is 1.4 and
Please suggest steps to debug and bring it running.
Any help would be highly appreciated.
Thanks
Raj
-
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]
Broken link on website
Hi guys, I just found a broken link in the Logging Guide. The Commons Logging home page has moved from http://jakarta.apache.org/commons/logging.html to http://jakarta.apache.org/commons/logging/ cheers, Roland
Re: SOCKS Proxies
Hi Sam, SOCKS is a socket level protocol that is supposed to be transparent for the application using the sockets. So you best take a look at org.apache.commons.httpclient.protocol.ProtocolSocketFactory. By implementing your own ProtocolSocketFactory, you are free to return a plain socket or one that uses SOCKS. cheers, Roland Sam Berlin [EMAIL PROTECTED] 14.04.2004 19:04 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:SOCKS Proxies Hi All, The website states the SOCKS proxies are supported by the setting the native java properties that convert Sockets to using SOCKS internally. Unfortunately, this solution is not possible for us, as we need to be able to create Sockets sometimes with and sometimes without SOCKS. How would one go about implementing SOCKS as an additional proxying method (on the 2.0 code)? Some rough pointers to the general classes that require changes would be useful. Thanks much, Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tunneling non-HTTP through a web proxy with HttpClient
Hi Mike Mike Michael Becke wrote: Given that HttpClient is in the business of communicating using HTTP, it is not terribly well suited for other purposes. Since CONNECT is also an HTTP method, it is not totally out of scope for the HttpClient. From RFC 2616, section 9.9: This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]). Maybe we can consider official support for CONNECT as a feature for the big 4.0 API overhaul. cheers, Roland
Re: Tunneling non-HTTP through a web proxy with HttpClient
Hello Mike, (for 4.0) we can wrap input and output streams around those of the underlying socket. Connection reuse is not an option for that method anyway, and by help of the wrapper we can cut any references to the underlying socket's input and output streams as soon as the connection manager gets back the connection. Of course, that is only required if the socket doesn't create new input and output streams for each connection anyway. As you have guessed by now, I agree that not the socket itself but only the streams should be made available. cheers, Roland Michael Becke [EMAIL PROTECTED] 26.03.2004 14:44 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: Tunneling non-HTTP through a web proxy with HttpClient Hi Mike Mike :) Since CONNECT is also an HTTP method, it is not totally out of scope for the HttpClient. From RFC 2616, section 9.9: Agreed. CONNECT is definitely an HTTP method. The only question is if we should support it's use in non-HTTP contexts. Maybe we can consider official support for CONNECT as a feature for the big 4.0 API overhaul. It seems like it could be a good addition. My only hesitation is in giving direct access to the Socket. This seems like a pretty major departure from our current system. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tunneling non-HTTP through a web proxy with HttpClient
Hi Oleg, I guess it's just a typo, but to be sure: The CONNECT method is for establishing a generic tunnel through an HTTP proxy. SSL tunneling is just one application of that. cheers, Roland Kalnichevski, Oleg [EMAIL PROTECTED] 26.03.2004 14:49 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:RE: Tunneling non-HTTP through a web proxy with HttpClient All Mikes, Roland, and all I believe it _might_ be possible to implement a generic SSL tunnelling mechanism using stock version of HttpClient. The only API change it may requite is adding protected HttpConnection#getSocket method. I may try to hack something up this weekend. Oleg -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Friday, March 26, 2004 14:44 To: Commons HttpClient Project Subject: Re: Tunneling non-HTTP through a web proxy with HttpClient Hi Mike Mike :) Since CONNECT is also an HTTP method, it is not totally out of scope for the HttpClient. From RFC 2616, section 9.9: Agreed. CONNECT is definitely an HTTP method. The only question is if we should support it's use in non-HTTP contexts. Maybe we can consider official support for CONNECT as a feature for the big 4.0 API overhaul. It seems like it could be a good addition. My only hesitation is in giving direct access to the Socket. This seems like a pretty major departure from our current system. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: question re: cookies
Oleg, thanks for the hint. Gil, if you're using version 2.0, instead of hacking the HttpClient code, you can go where others have gone before: write your own GetMethod/PostMethod. Just derive the regular ones, then override addCookieRequestHeader() to do nothing. Then you can setHeader() your cookies. Optionally, you can also override method processResponseHeaders() to do nothing, so the incoming set-cookie headers will not be parsed either. cheers, Roland Kalnichevski, Oleg [EMAIL PROTECTED] 25.03.2004 09:29 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:RE: question re: cookies Gil, Roland Pluggable cookie policies as well as ability to manually set cookie headers are supported in the development branch only. For 2.0 there is no way around forking HttpClient Oleg -Original Message- From: Roland Weber [mailto:[EMAIL PROTECTED] Sent: Thursday, March 25, 2004 8:39 To: Commons HttpClient Project Subject: RE: question re: cookies Ah yes, cookie headers that were manually set used to get overridden. As far as I remember, that changed a while back. Though I cannot tell whether the change went into 2.0 or only into the development branch. cheers, Roland Alvarez, Gil [EMAIL PROTECTED] 25.03.2004 08:04 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:RE: question re: cookies Thanks, yes, the old code pulled it out of the header directly, but the rest of the story is that I save that cookie for later submittal in a url request. I tried using addRequestHeader(Cookie, ...) and that didn't work. I surmised that it was because httpclient liked to operate with higher-level abstractions, so I switched to using real Cookie objects. I'd much rather do a getHeader()/setHeader() operation or getCookie()/setCookie()operation; I don't want to mix the semantics (such as getHeader()/setCookie()). Sounds like the cookie policy is the way to go. -Original Message- From: Roland Weber [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 10:51 PM To: Commons HttpClient Project Subject: Re: question re: cookies Hello Gil, two options. If you only need to get the cookie for your application, then access the header directly instead of looking into the http state. That's probably what your old code did, right? Otherwise, implement and configure your own cookie policy. Copy the default implementation that best fits your needs, then modify the validity check for the cookie path. And don't forget to complain with the site admin about the cookie standard violation. You may first want to check whether there is an alternative URL with path /X/b/c by which you can query the cookie. There's got to be some reason why the cookie is set with that path. cheers, Roland *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: question re: cookies
Hello Gil,
two options. If you only need to get the cookie for
your application, then access the header directly
instead of looking into the http state. That's probably
what your old code did, right?
Otherwise, implement and configure your own cookie
policy. Copy the default implementation that best fits
your needs, then modify the validity check for the
cookie path.
And don't forget to complain with the site admin
about the cookie standard violation.
You may first want to check whether there is an
alternative URL with path /X/b/c by which you can
query the cookie. There's got to be some reason
why the cookie is set with that path.
cheers,
Roland
Alvarez, Gil [EMAIL PROTECTED]
25.03.2004 07:37
Please respond to Commons HttpClient Project
To: [EMAIL PROTECTED]
cc:
Subject:question re: cookies
Hi, we're porting some old code to use httpclient, and I was having
trouble with the manual cookie stuff that we do.
We hit a 3rd party web-site (AOL) for some info, and it sets a cookie
that we want to grab.
I obfuscated the url's and data, but the gist of it is that we hit the
url:
2004/03/24 19:06:25:295 PST [DEBUG] wire - - GET /a/b/c/aol
HTTP/1.1[\r][\n]
We get back a Set-Cookie:
2004/03/24 19:06:25:535 PST [DEBUG] wire - - Set-Cookie:
badsc=cookie-value;path=/X/b/c[\r][\n]
I then see this:
2004/03/24 19:06:25:944 PST [WARN] HttpMethodBase - -Cookie rejected:
$Version=0
; badsc=cookie-value; $Path=/X/b/c. Illegal path attribute /X/b/c.
Path of origin: /a/b/c/aol
and when I try to look for this cookie in HttpState it isn't there. The
above msg is due to this code in CookieSpecBase:
if (!path.startsWith(cookie.getPath())) {
throw new MalformedCookieException(
Illegal path attribute \ + cookie.getPath()
+ \. Path of origin: \ + path + \);
}
So the problem is that the path of the cookie starts with /X, when the
path of the request started with /a.
Our old code worked fine (using std java.net classes) and was able to
pull out this cookie. I assume this validity check is due to some RFC
requirement. I did try the different policies and got the same error
each time. But given that this is 3rd party behavior that we need to
support, what is the recommended way to deal with this situation (short
of commenting out the code above)??
Thanks.
RE: question re: cookies
Ah yes, cookie headers that were manually set used to get overridden. As far as I remember, that changed a while back. Though I cannot tell whether the change went into 2.0 or only into the development branch. cheers, Roland Alvarez, Gil [EMAIL PROTECTED] 25.03.2004 08:04 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:RE: question re: cookies Thanks, yes, the old code pulled it out of the header directly, but the rest of the story is that I save that cookie for later submittal in a url request. I tried using addRequestHeader(Cookie, ...) and that didn't work. I surmised that it was because httpclient liked to operate with higher-level abstractions, so I switched to using real Cookie objects. I'd much rather do a getHeader()/setHeader() operation or getCookie()/setCookie()operation; I don't want to mix the semantics (such as getHeader()/setCookie()). Sounds like the cookie policy is the way to go. -Original Message- From: Roland Weber [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 10:51 PM To: Commons HttpClient Project Subject: Re: question re: cookies Hello Gil, two options. If you only need to get the cookie for your application, then access the header directly instead of looking into the http state. That's probably what your old code did, right? Otherwise, implement and configure your own cookie policy. Copy the default implementation that best fits your needs, then modify the validity check for the cookie path. And don't forget to complain with the site admin about the cookie standard violation. You may first want to check whether there is an alternative URL with path /X/b/c by which you can query the cookie. There's got to be some reason why the cookie is set with that path. cheers, Roland
Re: NTLM credentials.
Hello Brian, JDK for Windows uses Windows specific code to get the user's login credentials. HttpClient does not use Windows specific code, hence you're out of luck. You could analyse what the JDK does and replicate that in your application. But I guess you'd have to write native code to access the Windows API. cheers, Roland Russell, Brian [EMAIL PROTECTED] 22.03.2004 12:09 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:NTLM credentials. Hi, I am attempting to use the httpClient component to authenticate on a proxy which uses NTLM authentication. I have managed to use it successfully, but only when I explicitly provide the data for the NTCredentials for the HttpClient.getState().setProxyCredentials(). In JDK 1.4.2, if I use the java.net.URLConnection, it will authenticate automatically, without me having to determine the users credentials. Is there some way that I can use httpClient to automatically pick up the data required for it's NTLM authentication? Or, alternatively, is there someway to determine the required data for the NTCredentials to pass to setProxyCredentials()? Any help would be appreciated. Brian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leaks when web server hangs
Hello Eric, by using the same connection manager for each HttpClient, you avoid the biggest penalty for creating new clients. But still, each new client uses up some heap space, which will have to be garbage collected sooner or later. There are state objects, and parameter objecs, and probably some more that will be created. Nothing that hurts much, but what gain do you expect from creating new HttpClient objects? You don't have to. cheers, Roland Eric Bloch [EMAIL PROTECTED] 22.03.2004 07:03 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: Memory Leaks when web server hangs Oh... and I just want to know if that's not the httpclient way, too? That is, should I be reusing the client? What will that get me if I'm already reusing the connection manager? Thanks again, Eric Eric Bloch wrote: I am creating one MultiThreadedHttpConnectionManager and creating/destroying HttpClient each time but always constructing with the same connection manager. Thanks, Eric Michael Becke wrote: Hi Eric, What exactly do you mean by thread thrashing? Which connection manager are you using? Mike On Mar 19, 2004, at 1:21 PM, Eric Bloch wrote: Hey there, I create/destroy http clients but always have them use the same connection manager. Will that cause thread thrashing? Thanks, -Eric Roland Weber wrote: Hello Srini, you should *not* create a new HTTP Client for each request! This will also create a new connection manager, and a new cleanup thread. It beats the whole purpose of connection management. You should create *one* HTTP Client object for the lifetime of your application. Then, the connection manager of that client will reuse and free connections as appropriate. best regards, Roland Srinivas Vemula [EMAIL PROTECTED] 02.02.2004 11:56 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc:Subject:Re: Memory Leaks when web server hangs Oleg, We are using JDK1.4.1 and connection time out is set to 30Ms and read time out to 60Ms. We are trying to connect to a IP Camera, and send a heart beat command to the camera to check for its availability every 30 Secs from the time we find it is un available. If the web server is down, we feel that HttpClient is not cleaning up failed connections properly and thats resulting in Memory Leaks at the server side. The code we use is the standard way of using HttpClient and all the code is in a method and new HttpClient object is created for every request. Are there any ways to make sure the connections are all being purged properly? Are there any precautionary measures or flags we can set on HttpClient API when communicating with a web server (running on firm ware) with relatively less RAM and processing power (IpCamera with built in web server)? Thanks for your time and help. Srini Kalnichevski, Oleg wrote: Mike and Oleg, the stack trace Srini included indicates that HttpClient is attempting to create a new timeout thread on every connection - does this always occur or is it just one timeout thread per httpclient instance? It would be ideal if we could reduce this to one static thread as starting threads is never nice for server side apps. Not sure how feasible that is though. Hi Srini, HttpClient uses an additional controller thread to work around the limitation of older ( 1.4) JDKs which do not provide a possibility to set connect timeout. If you do not really need to control connect timeout (for instance, when communicating with an intranet site with good availability) simply set connect timeout to. That will prevent HttpClient from spawning an additional thread per request. Adrian, et al Another possibility to use reflection to set connect timeout using the Socket methods when running in JVM 1.4 or above Oleg -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Monday, February 02, 2004 09:03 To: Commons HttpClient Project Subject: Re: Memory Leaks when web server hangs On 2/2/04 2:00 PM, Srinivas Vemula [EMAIL PROTECTED] wrote: Hi All, We are seeing thread leaks when having client open connections to a web server that hangs. Has any one seen this happening?? How do we ensure that the library correctly closes socket connections on failures, cleaning up system resources, and threads actually finish in the timeout period and get freed up. Would using MultiThreadedHttpConnectionManager file:///D:/silkroad/http-commons/commons-httpclient-2.0-rc3/docs/ threading.ht ml#MultiThreadedHttpConnectionManager be of any help?? Hi Srini, If you're using the same HttpClient instance across multiple threads, you must use
Re: Multithreaded Connection manager question and 400+ servers
Hello Andre, you should try to get some real-life data to decide on connection management. Like a trace on how many connections are made to which hosts in what frequency. Then you can verify whether the frequently used hosts support connection keep-alive or not. I agree with Michael's assessment that a single connection per thread is the best way to go in this situation, unless you are sure there is some gain in connection reuse. By implementing a custom connection manager, you have full control over how long connections are kept alive, so you can manage that risk. Servers that cannot handle more than one request per connection are supposed to send connection: close headers back, and/or use HTTP 1.0. Connections will only be reused for servers that clearly indicate by the HTTP protocol version and connection headers that they are capable of handling another request. cheers, Roland Andre John Mas [EMAIL PROTECTED] 19.03.2004 21:11 Please respond to Commons HttpClient Project To: 'Commons HttpClient Project' [EMAIL PROTECTED] cc: Subject:Multithreaded Connection manager question and 400+ servers Hi, At the company I work for we are developing a middleware application that routes SOAP messages from one party too another, using HTTP. I have suggested that we use the MultithreadedConnectionManager, though at the moment there is some reluctence. The issue seems to be because we are potentially connecting to 400+ different servers. The danger of keeping a connection open could mean that there are no connections left to connect to another server to send the messages. There are also worries that some of the parties we connect to have basic HTTP implementations (there are a lot of homebrew solutions in C/C++) and therefore don't handle more than one query/answer on the same connection. I should mention that at the moment we create a new HTTPClient for every connection and the client is not reused across any threads. Because of the shear volume of traffic we are likely to be handling I am wanting to find ways of optimizing the use of every API we use, while not breaking anything. Has anyone used HTTPClient in this sort of situation? What is the best way to go about using HTTPClient for this? Is there anything else I should know? regards Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repost: Authentication question
Hello, use HttpMethod.setDoAuthentication(false). Then, your application will get the 40x response directly and can check the returned headers for the auth scheme and parameters. If it's basic auth, you should enable preemptive authentication after providing the credentials, to avoid unnecessary round trips. If you are using the development version of HttpClient, it's even simpler. Implement the interface ...auth.CredentialsProvider and all the information you require will be passed in as method arguments to getCredentials() cheers, Roland mclovis [EMAIL PROTECTED] 19.03.2004 15:01 Please respond to Commons HttpClient Project To: Jakarta Commons HttpClient mailing list [EMAIL PROTECTED] cc: Subject:Repost: Authentication question In 2.0 release is there a way to find (query) the server to get the authentication scheme in order to know what Credentials to use? I an new at this and would appreciate any help. Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cookie version info
Hello, there are two versions of the Cookie spec, the old one (RFC 2109) and the new one (RFC 2965). Cookies that adhere to the new spec include version info when sent back to the server. RFC 2965 also includes information about compatibility with older servers. http://www.ietf.org/rfc/rfc2965.txt My guess is that the server supports the new cookies, but the application running on the server does not. cheers, Roland Imabayashi, Kazuya [EMAIL PROTECTED] 19.03.2004 08:56 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:cookie version info Hi there, I have a small question regarding cookie handling. When I execute GetMethod to some host, cookies are returned. However, each cookie has its version info, like $version=0. An application of the target host cannot process this properly. When I took some http traces via IE, no version info specified. Does anybody have any idea on this? Regards, Kazuya Imabayashi
RE: cookie version info
Hello, I can't tell for what reasons IE behaves as it does. Cookies with version 0 are always formatted using CookiePolicy.NETSCAPE. You can search for the cookie in the HttpState, then use setVersion() to change the version number. Then, the cookie will be formatted by the default CookiePolicy, which you can replace. That's for the HttpClient version in CVS HEAD. When thinking about it, this sounds a lot like a hack. I wonder why the application sends a Netscape style cookie if it can't handle it when it comes back. Or maybe the application does *not* send a Netscape style cookie, but fails to provide appropriate version info. Kayzuya, which version of HttpClient are you using? And could you post a wire log, so we can see what cookie headers are actually received from and sent back to the server? http://jakarta.apache.org/commons/httpclient/logging.html cheers, Roland Imabayashi, Kazuya [EMAIL PROTECTED] 19.03.2004 09:26 Please respond to Commons HttpClient Project To: 'Commons HttpClient Project' [EMAIL PROTECTED] cc: Subject:RE: cookie version info Thanks a lot for your reply. Then why IE does not pass it to server? Is there any way to strip it off using httpclient? Regards, Kazuya Imabayashi -Original Message- From: Roland Weber [mailto:[EMAIL PROTECTED] Sent: Friday, March 19, 2004 5:16 PM To: Commons HttpClient Project Subject: Re: cookie version info Hello, there are two versions of the Cookie spec, the old one (RFC 2109) and the new one (RFC 2965). Cookies that adhere to the new spec include version info when sent back to the server. RFC 2965 also includes information about compatibility with older servers. http://www.ietf.org/rfc/rfc2965.txt My guess is that the server supports the new cookies, but the application running on the server does not. cheers, Roland Imabayashi, Kazuya [EMAIL PROTECTED] 19.03.2004 08:56 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:cookie version info Hi there, I have a small question regarding cookie handling. When I execute GetMethod to some host, cookies are returned. However, each cookie has its version info, like $version=0. An application of the target host cannot process this properly. When I took some http traces via IE, no version info specified. Does anybody have any idea on this? Regards, Kazuya Imabayashi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anmelden am Server
Yes, that should work. You may want to set the preemptive authentication flag on the method, to avoid an authentication required response for the initial request. cheers, Roland martin hilpert [EMAIL PROTECTED] 18.03.2004 13:34 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Anmelden am Server Hallo Roland, nun mal auf deutsch weil mein englisch an seine grenzen kommt. mit client.getState().setCredentials(null,null, new UsernamePasswordCredentials(Name,Password)); sollte das doch gehen oder? was ich will ist, mich an einen websever(linux), der mit .htaccess -datei geschützt ist anmelden. gruß martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Oleg wrote: I really think Java 1.3 does not bring anything to the table as far as HTTP communication is concerned. Ok, I agree. Just wanted to make sure we didn't miss a chance. cheers, Roland
Re: httpclient dont support ö ?
Hello Martin, that's probably a missing content encoding or character set in the file part you are trying to send. This problem pops up on a regular basis, you will find information in the mailing list archive not too far back. By the way, if you expect anyone else to answer your questions, you will have to write mails in english. It's the official language for this mailing list. I don't know how long I can answer german mails until folks start picking on me. It is impolite to post non-english mails in an english mailing list repeatedly, and it may be considered impolite to encourage this behavior by answering. cheers, Roland martin hilpert [EMAIL PROTECTED] 18.03.2004 14:10 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:httpclient dont support ö ? Danke Ronald, hat geklappt. nun habe ich noch das problem das er kein Dateien mit umlauten versenden kann,z.b Übung1.txt irgendeine idee das zu lösen? gruß martin PS: Ronald, du bist mir eine große hilfe. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: question about SimpleHttpConnectionManager
Hello Eric, you send a connection: close header with the request. I'm not sure whether using HTTP/1.0 has the same effect. cheers, Roland Eric Bloch [EMAIL PROTECTED] 19.03.2004 05:04 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:question about SimpleHttpConnectionManager I feel like this has been asked before I'm wondering how I force a socket to close when I'm using this manager. I couldn't find the api. Thanks, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TestWebappBasicAuth fails on IIS
Hi Dan, I haven't looked into the test cases yet, so I don't know about how many uid/pwd combinations we are talking here. If it's only a few, you could create Windows users for them. IIS still checks the Auth header, but it lets the request pass through since it knows the user. If that is not an option and resequencing of the IIS plugins doesn't help, I'm out of ideas here. cheers, Roland Dan Tran [EMAIL PROTECTED] 18.03.2004 20:06 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:Re: TestWebappBasicAuth fails on IIS Roland, I have IIS connecting to tomcat containing httpclienttest.war via iis_redirector, and run httpclienttest against iis. As you have said, IIS does intercept the header. I can either add the user/password hardcoded in the httpclienttest to IIS and run the test again, or I can figure out how to make IIS not to intercept the basic authentication. The later one is the perfer way. but still no clue yet. -Dan From: Roland Weber [EMAIL PROTECTED] Reply-To: Commons HttpClient Project [EMAIL PROTECTED] To: Commons HttpClient Project [EMAIL PROTECTED] Subject: Re: TestWebappBasicAuth fails on IIS Date: Thu, 18 Mar 2004 07:31:27 +0100 Hello Dan, IIS will try to verify the authentication headers it gets. If your users and passwords are known to Windows, the requests should pass through just fine. What exactly is an httpclient servlet? Have you checked which plugins are active in IIS? Maybe you can move the plugin of your servlet engine in front of the IIS authentication, so the servlet gets the request before IIS authenticates it. I'm just guessing here, I only conducted a few authentication experiments with IIS last year. cheers, Roland Dan Tran [EMAIL PROTECTED] 17.03.2004 17:28 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:TestWebappBasicAuth fails on IIS Hello, I think IIS rejects any Basic Authentication request. Is there a way to configure IIS to allow these request to passthru to httpclient servlets? Any suggestions? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Find a broadband plan that fits. Great local deals on high-speed Internet access. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags
Hello Eric, I was thinking about some kind of metrics, too. Not as advanced as yours, of course :-) But then I felt that a ranking is not the best approach. It may lure people to use tricks just to improve their ranking. There should be something that indicates the kind and volume of contributions, sure. Like that many mails, that many bug reports, and so on. But instead of trying to compute a ranking from it, I would prefer a randomized order, with the kind and volume of contributions listed for each person. Maybe with some hall of fame into which the major contributors can be voted. Somehow I feel that the social issues should not be tackled with a purely technical solution. cheers, Roland Eric Johnson [EMAIL PROTECTED] 15.03.2004 22:52 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: @author tags At the risk of adding fuel to an unproductive discussion, I thought I'd throw in my comments: [...snip...] Having noted some of the social issues, I do have to say that this mailing list has been very friendly and welcoming, and my compliments to everyone for keeping it that way. While not an entirely accurate measure, I have an urge to suggest a mathematical and statistical recognition metric, combining: * # of emails written to developer list * # of patches submitted * # of responses to bugzilla issues, wherein said person is not the reporter of the particular issue. * # of bugzilla issues reported, wherein reporting does not result in an INVALID categorization * negative points for each INVALID Bugzilla report (people wasting time and energy on behalf of the group) * Other contributions? My gut instinct is that some of these contributions should be weighted more than others, but seeing as this is a quagmire, I'm not sure I'd want to suggest what that weighting would be - at least not yet. The resulting number could be used to generate a ranking, and possibly a weighting of each contributor. With each release, the tally should be accumulated for some time period prior to that release (6 months?), and those people should be recognized in the release notes, and perhaps also on the web site. Such a metric would at least be an improvement over what we have now. It would at least recognize people who do nothing more than track down bugs. It would also give us some visibility into the size and involvement of the HttpClient community. Darts welcome! -Eric. Michael Becke wrote: The ASF has recently recommended that we discontinue use of @author tags. When first starting out I always enjoyed seeing my name in lights, though I do agree with the ASF's opinion on this matter. If we come to a consensus to remove @authors I suggest that we remove them from all existing code, as well as leave them out of new additions. Any comments? Mike Begin forwarded message: ASF Board Summary for February 18, 2004 snip - author tags are officially discouraged. these create difficulties in establishing the proper ownership and the protection of our committers. there are other social issues dealing with collaborative development, but the Board is concerned about the legal ramifications around the use of author tags - it is quite acceptable and encouraged to recognize developers' efforts in a CHANGES file, or some other descriptive file which is associated with the overall PMC or release rather than individual files. snip - 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]
Re: @author tags
Hello Michael, I hope this mail is still readable once it is converted to text-only format... Fuel to this fire, I think, is fine. Why not talk it out? Primarily because this mailing list is not for legal discussion, and we'll never ever talk it out. You are a lawyer, most of us are not. Your views are founded in your knowledge of the law of the country you work in, while ours are based on news reports about seemingly nonsensical lawsuits filed in the US. You can't convince us because we don't have the background knowledge to verify your arguments. For my part, I believe that there will always be at least one lawyer that represents the opposite of your views, if paid enough money. That's why it takes judges to make verdicts, right? * Based on what I've read, Would you spell out what [you've] read to make you think this? What kind of allegations? What kind of analysis of code? How does this relate to ASF? You are too dark here. Let us know what you actually are thinking? www.groklaw.net should be a good starting point. I remember that one example of stolen code involves indentical comments that go back to a common code base from which both, the proprietary and the open source software, got the same code. Or something like that. cheers, Roland
RE: @author tags
Hello all, Michael McGrady wrote: This is a really good idea, Oleg. I am surprised, frankly, that we allow people to use the @author tags without having signed the agreement first. That would be a real problem. So that is one of the reasons for this discussion. If you feel that @authors without CLA should not be tagged, I happily agree that there is no problem with the rest. Whoever signed a CLA will have given adequate thought to legal implications. Thanks for your information about the roles of judge and jury. I'll keep that in mind. And also that there are laws for punishing people who file dumb lawsuits :-) Michael also wrote: What are these social issues? I keep hearing the label but don't know the reality. Are they important? The author tag is a recognition that the named author has contributed. It's something to remember and tell your friends about. Kind of an I was here graffiti. Doesn't it feel good to know that somewhere in the world, people you never even heard of are browsing the source code and suddenly read your name? I once filed a bug report and fix for the GNU linker. Years ago, but I still remember. (Gee, I forgot to check whether my name was mentioned in the change log ;-) I think it is important, since some people will be less inclined to participate in the community if they are afraid their share in the result is not attributed to them. Oleg wrote: I think a simple extension to the existing changelog in a form of 'proposed by', 'inspired by', 'contributed by', 'verified by' 'helped by', 'tested by' clauses per major change/commit would be sufficient for the time being. Until the dust settles at the Jakarta PMC level What I like best about this proposal is the option to define new kinds of recognition on the fly. inspired by - that's cool :-) cheers, Roland
RE: [Cactus] Gump build failures for the past 2 weeks
Hello Vincent,
the code should not add an Authorization header.
HttpClient does that automatically, and probably
removes the one you set in the process. Instead:
- store uid/pwd in the HttpState as default credential
- enable preemptive authentication on the HttpMethod
The correct Authorization header will then be
generated by the HttpClient. You don't have to
care about the header format and base64
encoding in the application.
cheers,
Roland
Vincent Massol [EMAIL PROTECTED]
15.03.2004 08:09
Please respond to Commons HttpClient Project
To: 'Commons HttpClient Project'
[EMAIL PROTECTED]
cc: 'Cactus Developers List' [EMAIL PROTECTED]
Subject:RE: [Cactus] Gump build failures for the past 2
weeks
Hi Oleg,
Thanks very much for your help. Here's the code that adds basic
authentication (by adding authorization HTTP header):
public void configure(WebRequest theRequest,
Configuration theConfiguration)
{
// According to HTTP 1.0 Spec:
// basic-credentials = Basic SP basic-cookie
// basic-cookie = base64 encoding of userid-password,
// except not limited to 76 char/line
// userid-password = [ token ] : *TEXT
//
// see setName and setPassword for details of token and TEXT
String basicCookie = getName() + : + getPassword();
String basicCredentials = Basic
+ new String(base64Encode(basicCookie.getBytes()));
theRequest.addHeader(Authorization, basicCredentials);
}
Then, we use HttpClient to send the request:
[...]
// Add the cookies
HttpState state = CookieUtil.createHttpState(theRequest, url);
// Open the connection and get the result
HttpClient client = new HttpClient();
HostConfiguration hostConfiguration = new HostConfiguration();
hostConfiguration.setHost(url.getHost(), url.getPort(),
Protocol.getProtocol(url.getProtocol()));
client.setState(state);
client.executeMethod(hostConfiguration, this.method);
// Wrap the HttpClient method in a java.net.HttpURLConnection
object
return new org.apache.commons.httpclient.util.HttpURLConnection(
this.method, url);
Let me know if you need more details to understand it.
Do I have to assume that these changes in httpclient are not
backward-compatible and there's no compatibility layer, right? Thus if
Cactus moves to 2.1-dev, we'll need to deliver cactus with httpclient
2.1-dev bundled. Thus there is a risk that httpclient 2.1-dev is not
stable at that point (we'll be releasing a new version of Cactus next
week). Of course, we could build a compatibility layer in Cactus itself
to support both httpclient 2.0 and 2.1-dev. Frankly, I think it makes
more sense for httpclient to do this. It could get dropped once 2.1
final is out. It would really be good if 2.1 was backward compatible (it
could of course introduce new APIs). Lots of persons are using
httpclient and breaking an API is not a very good migration path... :-)
What do you suggest?
Thanks
-Vincent
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: 15 March 2004 00:52
To: Commons HttpClient Project
Subject: RE: [Cactus] Gump build failures for the past 2 weeks
Vincent,
From the cursory examination the problem appears to have been caused
by
HttpClient not finding the required credentials. The way credentials
are
set in the HTTP state has changed. Could you please give the code
snippet containing calls to HttpState#setCredentials() method(s)? This
method may be the cause of the problem.
More tomorrow
Oleg
On Mon, 2004-03-15 at 00:40, Vincent Massol wrote:
It seems the attachment was stripped. I've uploaded it on:
http://cvs.apache.org/~vmassol/test_client.log
Thanks
-Vincent
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: 15 March 2004 00:30
To: 'Commons HttpClient Project'
Cc: [EMAIL PROTECTED]
Subject: [Cactus] Gump build failures for the past 2 weeks
Hi guys,
I've finally tracked down the Cactus gump build problem we've been
having for the past 2 weeks. It appears to be caused by some
change in
commons-httpclient.
The build is working fine with version 2.0 and failing on some
authentication code with a commons-httpclient built from CVS HEAD.
I'm attaching the cactus log file (which contains httpclient logs)
in
case it helps.
Any idea what can have changed?
Thanks
-Vincent
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: @author tags
Hi folks, let me add a few lines to the discussion... Dan Christopherson wrote: I think that owner is intended in the sense of the primary person responsible for maintaining, not in the sense of the legel owner. Yes, that was - and is - exactly my understanding of the term code owner. However, the discussion that ensued highlights the only point I really wanted to make with my posting: The recommendation found by Chris Lampert contradicts itself when applied in the context of the HttpClient. Jeff, and others, my apologies for not making clear in my posting that I was referring to the code owner, not the owner in a legal sense. Unfortunately, my mailer does not reasonably support inline quoting, so the context of my statement may have been lost. Michael McGrady wrote: Bravo, author of code and especially code parts does not mean owner in any sense. Author means author, which is accurate. The recommendation quoted by Chris Lampert is: One of the most important pieces of information that should appear in the source file is the author's name -- not necessarily who edited the file last, but the owner. Attaching responsibility and accountability to source code does wonders in keeping people honest ... So it recommends that the author tags be used to indicate code ownership. I take it your Bravo was meant for the author of the book _The Pragmatic Programmer_. Michael McGrady also wrote: On the first issue, I am a lawyer and I can assure you that this worry is, frankly, silly. Right now, there is a company with three capital letters on the loose, which is suing other companies (including another one with three capital letters) for reasons that most of the open source community considers to be silly. But it may be an expensive and lengthy enterprise to prove in court that a silly thing is a silly thing. If removing author tags may reduce the risk of being sued, then rip them out. As a replacement: what about a list that indicates how many classes and/or methods a contributor has contributed to? I'd keep it in alphabetical or random order rather than as a ranking, to make it more of a collaboration and less of a competition. And finally, since this discussion tangles legal matters, let me add that the views expressed in this, previous, and following postings are strictly my own and not those of my employer, which happens to have three capital letters. cheers, Roland
Re: @author tags
Hello Chris, I don't see that either. But if some of the top Apache guys feel, believe or know otherwise, that's good enough for me. If the only purpose of the tags is to feature contributor names in a prominent place - namely the source code - then the real question becomes whether we can achieve this goal in some other way with reasonable effort. If so, then why not do the above mentioned the favor? Concerning the CVS log, you have to be aware that the committer is not always the contributor. A contributor may put a patch in bugzilla, which is then comitted by someone else. In general, I don't believe that the removal of author tags is to disguise from where the code came. Rather, some people may be afraid to find their name in the author tag of code which has no longer anything to do with what they actually contributed long ago. Then it would become their problem to dig through the CVS logs, bugzilla, and the mailing list archives to prove that they are *not* the author. cheers, Roland Chris Lamprecht [EMAIL PROTECTED] 12.03.2004 09:30 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: @author tags a silly thing is a silly thing. If removing author tags may reduce the risk of being sued, then rip them out. One reason cited for removing the @author tags is for legal protection -- and it's a good reason. But I don't see how removing @author tags can offer any legal protection, unless you also clean out the CVS logs (which store who committed each change to each file, down to the exact lines of code they changed). Not to mention the bugzilla database, this message forum, etc. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags
Hello Michael, it was never my intention to involve in a legal discussion. I kind of feel dragged into this, probably because my use of the term owner was mistaken as a legal term. Also, some not clearly specified legal issues were mentioned as the reason why the use of the author tag has been discouraged. Lets just accept that author tags are discouraged and go on to discuss whether there are good reasons to keep them anyway. Michael, thank you for bringing a new non-legal aspect into this discussion: When we see certain authors, then we know that we don't have to double check the code too much. We might even stop for that reason alone to see what they do. Other authors, maybe we do the opposite. This is not unimportant. Code is submitted in form of patches, which get reviewed before they are committed. At the time of the review, the patch contributor is known, and the amount of review needed can be determined accordingly. When stopping by to see how something has been done, I am usually interested in the architecture or design of the solution. Once a patch has been committed, all architectural or design decisions have been discussed between a lot of people and agreed upon. The author tag will not help me to track down where someone left his or her traces on that level. Which leaves implementation details as something to attribute to a particular developer through the author tag. Is this important enough? We can also see where people are interested in or good at various aspects of coding. Is this something that should be visible from the source code? There are lots of reasons to know who did what and when as well as for what reason. Reasoning takes place on the mailing list and in bugzilla. Reasons are documented in bugzilla, and possibly in comments throughout the source code. The when is documented in CVS. Not in author tags. There is no reason that has been given that I find at all persuasive to not know who coded something. Quoting from Michael Beckes original mail: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=6200 The ASF has recently recommended that we discontinue use of @author tags. For me, that is reason enough to remove the author tags in the absence of better reasons to keep them. I trust the ASF implicitly to have discussed this matter thoroughly. If I didn't trust them, I'd search whether that discussion is documented online, possibly in some other mailing list. Someone got a link at hand? cheers, Roland Michael McGrady [EMAIL PROTECTED] 12.03.2004 13:24 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: @author tags THE PRACTICAL ASPECT OF THIS DISCUSSION IS AT BEST DUBIOUS The use of @author tags has a lot more than ownership or braggadocio to recommend itself to us. When we see certain authors, then we know that we don't have to double check the code too much. We might even stop for that reason alone to see what they do. Other authors, maybe we do the opposite. This is not unimportant. We can also see where people are interested in or good at various aspects of coding. There are lots of reasons to know who did what and when as well as for what reason. There is no reason that has been given that I find at all persuasive to not know who coded something. The deliberate creation of ignorance about these matters should be suspicious to our common sense. THE LEGAL ASPECT IN THIS DISCUSSION IS JUST PLAIN MISTAKEN Roland Weber wrote: Right now, there is a company with three capital letters on the loose, which is suing other companies (including another one with three capital letters) for reasons that most of the open source community considers to be silly. But it may be an expensive and lengthy enterprise to prove in court that a silly thing is a silly thing. If removing author tags may reduce the risk of being sued, then rip them out. 1. There is no legal liability engendered by the @author tags. If there is, please indicate how so. Wild speculations about other suits is not helpful. 2. Any alternative to @author tags will face exactly the same legal liability. With respect to everyone involved in this decision to break something that is not broken, this is all really not very smart. Some of the best programmers in the world are on these lists. Unfortunately, some of the worst jail house lawyers are also on this list. The list needs to know that this is all legal baloney. There is NOTHING fixed or protected legally by doing something with the @author tags. Anyone who thinks so is simply way off beam. All this talk about legal liability is nothing but well-intentioned smoke and mirrors. There is NO REALITY to the legal aspect of this discussion. Please get a real decision on this by someone that knows what they are talking about in the legal arena or stop this wild speculating
Re: @author tags
That's exactly the problem: not necessarily who edited the file last, but the owner There are people who see a chance to contribute an enhancement or bug fix. We'd like to have them listed as someone who contributed, but *without* the responsibility of being the owner of the code. cheers, Roland Chris Lamprecht [EMAIL PROTECTED] 11.03.2004 09:54 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: @author tags I'm currently reading _The Pragmatic Programmer_, and I just came across the following in a section entitled Comments in Code on page 250: One of the most important pieces of information that should appear in the source file is the author's name -- not necessarily who edited the file last, but the owner. Attaching responsibility and accountability to source code does wonders in keeping people honest ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Downloading Images
Except for error handling and stuff, this is the right approach. To store the image, you have to create a FileOutputStream and copy the response data there. See also the section Read the Response in the tutorial: http://jakarta.apache.org/commons/httpclient/tutorial.html cheers, Roland Saifadam Pathan [EMAIL PROTECTED] 11.03.2004 10:54 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Downloading Images Hi ... How do i do the following... I have specified the url as a link to an image, ( example : url =3D = http://www.google.co.in/images/hp0.gif; ). And then I am calling the = following... HttpMethod method =3D new GetMethod(url); statusCode =3D client.executeMethod(method); . . ** Is this the right way. How do i store this image? Thanks in advance.=20 Saif- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: file transfer through firewall
Hello Ramakrishna, if you are developing the server system, then HttpClient is not the way to go. If you are developing a client application, then it is. Yes, users should authenticate. cheers, Roland Ramakrishna Kuppa (Bangalore) [EMAIL PROTECTED] 03.03.2004 08:59 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:file transfer through firewall Hi, I am new to HttpClient...so bear with me if I am asking a wrong question(s). I am developing an application wherein my customer should be able to transfer a large XML file over the internet to my server system, which is behind a firewall. (An example scenario is the customer sitting in the airport lounge, and using wireless network connectivity, be able to transfer the file.) Please help me in the following: is HttpClient the way to go? should the user authenticate with my server (before being able to update my application DB with his/her data in the XML file - this will be taken care of by the server end of my application) what would be a good architecture for the same? Please share any ideas you might have around this. Regards Ramakrishna - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] provide request entities in a more abstract way
Hello Odi,
is this meant as an extension or as a replacement for
directly passing the InputStream? In the second case,
I would add something like isRepeatable() to handle cases
where it is indeed not possible to read the data twice.
I'd prefer an explicit check to some exception being
thrown from getAsStream(), where every implementor
may decide for a different class and/or message.
Can you fill me in on the details of the POST request:
does the InputStream provide the full HTTP message
body (entity) for the request, or is it possible to send
multiple parameters, each of them being a file or string
or something else? In the second case, RequestEntity
is probably a misleading name for the interface.
cheers,
Roland
Ortwin Glück [EMAIL PROTECTED]
26.02.2004 10:46
Please respond to Commons HttpClient Project
To: Commons HttpClient Project
[EMAIL PROTECTED]
cc:
Subject:[RFE] provide request entities in a more abstract
way
Providing only an InputStream as a request body is not enough. We can
not automatically repeat such a request since we are unable to reset the
input stream without buffering it. I suggest we introduce an abstraction
for the source of request entities such as:
interface RequestEntity {
/**
* Provides an input stream of the request entity. The method may be
called
* more than once and must provide a virgin stream upon each call.
*/
InputStream getAsStream();
}
We can then provide convenience classes that implement this interface,
such as:
* class StringRequestEntity implements RequestEntity
* class FileRequestEntity implements RequestEntity
etc.
What does everybody think about this?
Odi
--
_
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer [email] [EMAIL PROTECTED]
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
RE: [RFE] provide request entities in a more abstract way
Hello Moh, you are assuming preemptive authentication. In general, authentication is triggered by a 40x response from the server, which means the request has already been sent. best regards, Roland Rezaei, Mohammad A. [EMAIL PROTECTED] 26.02.2004 15:57 Please respond to Commons HttpClient Project To: 'Commons HttpClient Project' [EMAIL PROTECTED] cc: Subject:RE: [RFE] provide request entities in a more abstract way Both authentication and closed connections should occur long before we read the input stream to send the request body. So why would you want to reset the stream? Thanks Moh
Re: Cookie rejected problem
Hello Xavier, your first action should be to contact the administrator of that web site and tell him that the cookie configuration is all screwed up. No browser should accept a cookie for .smals-mvm.be coming from socialsecurity.be, let alone HttpClient. It would be a security violation to do so. Next, you should check whether you need the cookie at all. I doubt there are many browsers that fail to filter that cookie. So the site may work without it. Finally, you can implement your own InsecureGetMethod, derived from GetMethod, where you override the method processResponseHeaders. Then you create a cookie that has the originating domain instead of the invalid domain, and add that cookie to the state. cheers, Roland Xavier Frisaye [EMAIL PROTECTED] 24.02.2004 12:33 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Cookie rejected problem Hi all, I'm using httpclient 2.0 and i'm encountering this problem when i try to connect to https://www.socialsecurity.be/login/login_fr?j_target_url=%2Fsrd%2Findex .jsp using a get method : 24-fevr.-2004 11:58:35 org.apache.commons.httpclient.HttpMethodBase processResponseHeaders ATTENTION: Cookie rejected: JSESSIONID=A7vh20mc7kV8j1gNcy0utYApOrPTzn2ZLLbX2zeY633eHw1xw5If!1167850 366!freyr.smals-mvm.be!8090!-1. Illegal domain attribute .smals-mvm.be. Domain of origin: socialsecurity.be I know this is a security/policy cookie problem and i try all available cookie policies but it doesn't work... Does anyone have a solution for this? Thanks a lot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: two post requests
Hello Diana, there are some possible cases... you'll have to analyse the page returned as the response to the first POST request. Easy case: The second POST request is just a generic request with fixed data, such as parameter confirm set to true. You extend your program to send that fixed second POST request after the first one. Tricky case: The second POST request contains the parameters from the first POST request. If your program remembers them, you can extend it to send the second POST request after the first one. If you're lucky, you may even detect some indicator parameter (confirm-true or so) that is the only difference between the first and second POST. Which means you could forget about the first POST and send the second first... eh... you know what I mean, don't you? Hard case: The second POST request contains dynamic data, such as a random number, session ID or something. Then you'll need an HTML parser to get the data out of the HTML page so you can send the second POST request. HTML parsing is out of the scope of HttpClient. See the mailing list archive for links to HTML parsers. hope that helps, Roland Diana Steffen [EMAIL PROTECTED] 23.02.2004 18:02 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:two post requests Hello, I'm new in using HttpClient and I have the following problem: There is an external web application using a post form. When the user provides the values for the form fields, he receives a new post form, under the same URL. Here he must push a submit button, to confirm that the values he just provided are correct. Now I'm trying to do all this using HttpClient. My application makes the first post request and gets the second post form as result (getResponseBody()). Unfortunately I don't know how to make the second post request. Can you give me a hint? Thank you. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookie Problem
Hello Hareesh, the cookie shouldn't include commas in the first place, that's a violation of the respective specification. But since you have to access that page, try setting a different cookie policy. Check out the options in org.apache.commons.httpclient.cookie.CookiePolicy Try NETSCAPE and BROWSER_COMPATIBILITY. cheers, Roland hareesh babu [EMAIL PROTECTED] 16.02.2004 12:21 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:Cookie Problem Hi, I am working on website using apache commons library of http client. I was able to login into the website using my code and not able navigate into website. I was facing one problem with apache http client at cookie assumption. website is sending cookie like this way, Set-Cookie: usr2__com=jzu,aa,czj,dm;path=/;domain=..com; But apache http client is dividing the cookie into 4. Cookie: usr2_xxx_com=jzu[\r][\n] Cookie: aa=[\r][\n] Cookie: czj=[\r][\n] Cookie: ON_VAT2=103556810351170501155924063287[\r][\n] Cookie: dm=[\r][\n] So next when I send a new get method it sending the website 4 cookies instead of one. I am thinking due this problem I was not able to navigate into website. Http client lib i am working on http://mirrors.xtria.com/apache/jakarta/commons/httpclient/source/commons-httpclient-2.0-rc3-src.zip Suggest me if am thinking right. Hareesh. Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Forms Login with Iframe
Hello Jeannie, where exactly do you want to use the HttpClient? Are you writing a Java browser, like HotJava? Do you want to connect from an applet? A standalone Java application? A servlet? Logging in and fetching the page can of course be done. I just wonder how to show the content in an iframe, unless your application is (in) a browser. cheers, Roland jeanniepb97 [EMAIL PROTECTED] 16.02.2004 16:01 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:Forms Login with Iframe Hi, I would like to use the HttpClient to do the following: 1. Using HttpClient, log into http://www.blah.com/secure/login.jsp. 2. Display http://www.blah.com/secure/test.jsp in an iframe. Has anyone tried this? Any help or insights would be greatly appreciated. Thanks! Jeannie - Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online
Re: Forms Login with Iframe
Hello Jeannie, if it's on WebSphere, then it's running on a server and not in the browser. Yes, you can perform login and fetch a page. Bringing it into an IFrame is just a question of how to invoke your JSP or servlet - it won't know the difference between showing pages in an IFrame, in a regular frame or in a browser window. But keep in mind that the page you fetch from a different server most likely has hyperlinks to that server. So you'll have to find all links in the page and rewrite them to point to your own application if you want it to work properly. HttpClient won't help you with that task. Performing login on behalf of the browser user and pointing the browser directly to the original page is tricky, since in most cases a server will not be able to set a cookie for another server. cheers, Roland jeanniepb97 [EMAIL PROTECTED] 16.02.2004 17:04 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:Re: Forms Login with Iframe Hi Roland, Yes, my application would be in a browser. It will be a JSP/servlet application running in WebSphere. Thanks! Jeannie Roland Weber [EMAIL PROTECTED] wrote: Hello Jeannie, where exactly do you want to use the HttpClient? Are you writing a Java browser, like HotJava? Do you want to connect from an applet? A standalone Java application? A servlet? Logging in and fetching the page can of course be done. I just wonder how to show the content in an iframe, unless your application is (in) a browser. cheers, Roland jeanniepb97 16.02.2004 16:01 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject: Forms Login with Iframe Hi, I would like to use the HttpClient to do the following: 1. Using HttpClient, log into http://www.blah.com/secure/login.jsp. 2. Display http://www.blah.com/secure/test.jsp in an iframe. Has anyone tried this? Any help or insights would be greatly appreciated. Thanks! Jeannie - Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online - Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online
RE: GetMethod Performance
Hello Ben, without digging into details, I'd say the profile indicates some problems with the crypto algorithms. They seem to get interpreted, instead of being compiled by a JIT or branching into native code. Since your test only fetches on page in a single request, it won't make much of a difference whether the connection is kept alive or not. I think you should try to profile the native socket version, and try to find out which crypto service provider is used for the SSL connection there. If it's a different one than used by the HttpClient, modify the SecureProtocolSocketFactory to use the faster crypto service provider. cheers, Roland Ben Wong [EMAIL PROTECTED] 16.02.2004 23:39 Please respond to Commons HttpClient Project To: 'Commons HttpClient Project' [EMAIL PROTECTED] cc: Subject:RE: GetMethod Performance Oleg, Both didn't make a difference. I have attached the CPU profile that is generated using -Xprof. The profile for Sun will be attached to this email, another mail will be sent for the Windows profile. Any help would be appreciated. Thanks, Ben Sun Solaris 8 on Sparc -- Flat profile of 17.72 secs (450 total ticks): main Interpreted + native Method 5.6%18 + 6java.math.BigInteger.mulAdd 3.3%14 + 0sun.security.provider.SHA.computeBlock 3.0%13 + 0java.math.BigInteger.addOne 2.8%11 + 1sun.nio.cs.StreamDecoder.read 1.9% 0 + 8java.lang.Throwable.fillInStackTrace 1.6% 0 + 7java.net.Inet4AddressImpl.lookupAllHostAddr 1.4% 6 + 0java.math.BigInteger.montReduce 1.4% 0 + 6sun.nio.cs.UTF_8$Decoder.decodeArrayLoop 1.2% 0 + 5 com.telstra.deon.test.HttpClientPerformance.main 1.2% 3 + 2sun.nio.cs.StreamDecoder.read0 1.2% 0 + 5 org.apache.commons.httpclient.HttpMethodBase.init 0.9% 0 + 4java.lang.String.charAt 0.9% 2 + 2sun.text.ComposedCharIter.findNextChar 0.7% 0 + 3sun.nio.cs.ISO_8859_1$Decoder.decodeArrayLoop 0.7% 0 + 3java.lang.ClassLoader.defineClass0 0.7% 1 + 2java.lang.System.arraycopy 0.7% 0 + 3java.lang.String.length 0.7% 0 + 3java.lang.StringBuffer.expandCapacity 0.5% 2 + 0java.util.HashMap.hash 0.5% 0 + 2java.nio.Buffer.position 0.5% 0 + 2java.util.zip.Inflater.inflateBytes 0.5% 0 + 2java.lang.ref.Reference.get 0.5% 2 + 0org.apache.log4j.spi.LoggingEvent.init 0.5% 0 + 2java.lang.StringBuffer.setLength 0.5% 1 + 1java.lang.String.getChars 44.9%96 +96Total interpreted (including elided) Compiled + native Method 10.0%40 + 3java.lang.StringBuffer.append 7.0%30 + 0sun.nio.cs.StreamDecoder.read0 6.5% 8 +20org.apache.commons.httpclient.Wire.wire 6.5%28 + 0java.lang.Integer.toUnsignedString 6.3%27 + 0java.nio.charset.CoderResult$Cache.get 3.0%13 + 0sun.nio.cs.StreamDecoder$CharsetSD.implRead 2.8%12 + 0sun.nio.cs.StreamDecoder.read 2.3%10 + 0java.lang.Integer.hashCode 2.1% 9 + 0sun.nio.cs.US_ASCII$Decoder.decodeArrayLoop 1.4% 6 + 0java.nio.charset.CharsetDecoder.decode 1.2% 5 + 0sun.nio.cs.US_ASCII$Decoder.decodeLoop 1.2% 5 + 0java.nio.CharBuffer.put 0.9% 3 + 1java.lang.StringBuffer.expandCapacity 0.5% 2 + 0java.math.BigInteger.mulAdd 0.5% 2 + 0java.nio.Buffer.init 0.2% 1 + 0java.nio.Buffer.position 52.6% 201 +24Total compiled Thread-local ticks: 4.9%22 Blocked (of total) 2.3%10 Class loader 0.2% 1 Unknown: no last frame Flat profile of 0.02 secs (1 total ticks): DestroyJavaVM Thread-local ticks: 100.0% 1 Blocked (of total) Global summary of 17.82 seconds: 100.0% 463 Received ticks 1.7% 8 Received GC ticks 57.9% 268 Compilation 2.2%10 Class loader 0.2% 1 Unknown code -Original Message- From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] Sent: Tuesday, 17 February 2004 12:27 AM To: Commons HttpClient Project Subject: RE: GetMethod Performance Ben, Try the following: (1) disable stale connections check SimpleHttpConnectionManager connman = new SimpleHttpConnectionManager(); connman.setConnectionStaleCheckingEnabled(false); HttpClient client = new HttpClient(connman); http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/ httpclient/SimpleHttpConnectionManager.html#setConnectionStaleCheckingEn abled(boolean) (2) configure HttpClient to use HTTP/1.0 instead of HTTP/1.1 GetMethod get = new
Re: GetMethod Performance
Hi Ben,
that is indeed a big difference. Two questions:
1. The HttpClient example uses IP address 192.168.0.1,
the Socket example connects to 192.168.0.11
Is that a typo, or do you indeed access a different host?
If that different host is a caching proxy, that would be an
explanation.
2. Did you check how much of the delay is due to the
initialization of HttpClient? Please set a checkpoint
after new HttpClient() and before new GetMethod.
Since the client only has to be created once for your
application, that would be a fairer comparison.
I trust you ran your examples immediately after one
another while there was not much load on the network.
cheers,
Roland
Ben Wong [EMAIL PROTECTED]
16.02.2004 06:40
Please respond to Commons HttpClient Project
To: [EMAIL PROTECTED]
cc:
Subject:GetMethod Performance
Hi,
I have noticed significant performance difference between using
HttpClient and Socket.
I tried to use GetMethod to download a 2MB file from a Webserver sitting
in the LAN. When I do it with HttpClient, it takes around 13-15 seconds
while it will only take less than half a second with Socket.
I was running the code below on a Sun Blade 100 with Solaris 8
installed. J2SDK1.4.2_03 and HttpClient 2.0 final were used.
Any help would be appreciated.
Thanks,
Ben
HttpClient code:
HttpClient client = new HttpClient();
GetMethod get = new
GetMethod(http://192.168.0.1/commons-httpclient-2.0-final.zip;);
int statusCode = client.executeMethod(get);
System.out.println(Status Code: + statusCode);
int size = 0;
InputStream in = get.getResponseBodyAsStream();
byte [] data = new byte[1];
int read = 0;
while ((read = in.read(data)) 0) {
size += read;
}
in.close();
get.releaseConnection();
Socket Code:
Socket soc = new Socket(192.168.0.11, 80);
InputStream in = soc.getInputStream();
OutputStream out = soc.getOutputStream();
String command = GET
http://192.168.0.1/commons-httpclient-2.0-final.zip
HTTP/1.0\nUser-Agent: Jakarta Commons-HttpClient/2.0final\nHost:
10.0.3.11\n\n;
byte [] send = command.getBytes();
out.write(send);
byte b[] = new byte[4096];
int size = 0;
int count = 0;
while( (size = in.read(b)) = 0) {
count += size;
}
in.close();
out.close();
soc.close();
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
RE: GetMethod Performance
Hello Ben,
I remember reading about problems with particular JVM versions,
and with stale connection checks in this mailing list. But I didn't
track these issues, so someone else will have to help out. Or you
check the mailing list archive and the bugzilla database for known
issues. There's a good chance you'll find something about your
problem.
cheers,
Roland
Ben Wong [EMAIL PROTECTED]
16.02.2004 07:30
Please respond to Commons HttpClient Project
To: 'Commons HttpClient Project'
[EMAIL PROTECTED]
cc:
Subject:RE: GetMethod Performance
Thanks Michael and Roland for the quick responses.
Roland, in fact, that was a typo and it was not caused by the
initialization of HttpClient AFAIK.
I had very close result when I ran the whole thing on my laptop, which
runs WinXP. Both could finish in less than a second.
However, when I put exactly the same code to Sun Solaris 8 on a Sun
Blade 100, I got a totally different story. Test finishes quick when I
used Socket, but it takes significantly longer when httpClient was used.
Did I miss out something that I should do when I execute Java class from
console on Sun box? Or do they have a different JVM configuration?
-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Monday, 16 February 2004 5:25 PM
To: Commons HttpClient Project
Subject: Re: GetMethod Performance
Hi Ben,
that is indeed a big difference. Two questions:
1. The HttpClient example uses IP address 192.168.0.1,
the Socket example connects to 192.168.0.11
Is that a typo, or do you indeed access a different host?
If that different host is a caching proxy, that would be an
explanation.
2. Did you check how much of the delay is due to the
initialization of HttpClient? Please set a checkpoint
after new HttpClient() and before new GetMethod.
Since the client only has to be created once for your
application, that would be a fairer comparison.
I trust you ran your examples immediately after one
another while there was not much load on the network.
cheers,
Roland
Ben Wong [EMAIL PROTECTED]
16.02.2004 06:40
Please respond to Commons HttpClient Project
To: [EMAIL PROTECTED]
cc:
Subject:GetMethod Performance
Hi,
I have noticed significant performance difference between using
HttpClient and Socket.
I tried to use GetMethod to download a 2MB file from a Webserver sitting
in the LAN. When I do it with HttpClient, it takes around 13-15 seconds
while it will only take less than half a second with Socket.
I was running the code below on a Sun Blade 100 with Solaris 8
installed. J2SDK1.4.2_03 and HttpClient 2.0 final were used.
Any help would be appreciated.
Thanks,
Ben
HttpClient code:
HttpClient client = new HttpClient();
GetMethod get = new
GetMethod(http://192.168.0.1/commons-httpclient-2.0-final.zip;);
int statusCode = client.executeMethod(get);
System.out.println(Status Code: + statusCode);
int size = 0;
InputStream in = get.getResponseBodyAsStream();
byte [] data = new byte[1];
int read = 0;
while ((read = in.read(data)) 0) {
size += read;
}
in.close();
get.releaseConnection();
Socket Code:
Socket soc = new Socket(192.168.0.11, 80);
InputStream in = soc.getInputStream();
OutputStream out = soc.getOutputStream();
String command = GET
http://192.168.0.1/commons-httpclient-2.0-final.zip
HTTP/1.0\nUser-Agent: Jakarta Commons-HttpClient/2.0final\nHost:
10.0.3.11\n\n;
byte [] send = command.getBytes();
out.write(send);
byte b[] = new byte[4096];
int size = 0;
int count = 0;
while( (size = in.read(b)) = 0) {
count += size;
}
in.close();
out.close();
soc.close();
-
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]
Re: setting User agent? Parsing HTML?
Hello Tom, You can set the USER_AGENT property in the HttpMethodParams. HTML parsing is totally out of scope of the HTTP client. There are other projects that provide HTML parsers, including one on Sourceforge: http://sourceforge.net/projects/javahtmlparser You may also want to check the open source software from W3C: http://www.w3.org/Status There's a list of components towards the bottom of the page. cheers, Roland TP Diffenbach [EMAIL PROTECTED] 09.02.2004 01:40 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:setting User agent? Parsing HTML? Using the jakarta commons httpclient api, is there an easier way of setting the User-agent header than adding it to each HttpMethod, as in: HttpMethod method = new GetMethod(loginUrl); method.setRequestHeader( User-Agent, useragent ) ; Once I've gotten a response body, are there any classes to parse it into an HTML tree? I'm particularly interested in finding forms and their attributes, so as to fill in the form and POST it. Thanks, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Performance - ConnectionManager vs none?
Hello André-John, if you continue to create a new HTTP Client in each thread, there is no point in using the multi threaded connection manager. That makes sense only if several threads share the same HTTP Client. That's more effort than just changing a single line of code. As Odi pointed out, you can save the overhead of establishing a new connection for each request. How much that is depends on your infrastructure: network latency, authentication overhead,... Once you have a single HTTP Client with multi threaded connection manager, you can also tune the parameters of the connection manager. Primarily the total number of connections, and the number of simultaneous connections to the same host. These values must be chosen with respect to the number of threads that do the SOAP calls, and to the frequency of these calls. Please keep that in mind if you write a test program. If I remember correctly, the default number of connections to the same host is rather low. cheers, Roland André-John Mas [EMAIL PROTECTED] 03.02.2004 16:51 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:Performance - ConnectionManager vs none? Yesterday under the topic ' Memory Leaks when web server hangs' it was suggested that using the class MultiThreadedHttpConnectionManager would be safer in multithreaded environments, than using SimpleHttpConnectionManager That much makes sense. Now, currently in the project I am working in we create a new HTTPClient in each thread we call, of the form HttpClient hc = new HttpClient(); Now I am wondering how much of performance increase, if any, there would be in using a connection manager, of the form: HttpClient hc = new HttpClient(myConnectionManager); where 'myConnectionManager' would be of the threaded sort. I should also note that we are regularly using the same destination addresses, since the program is a SOAP client. Although I could spend a bit of time trying to find this out from a test program, I am hoping to save a little time and get an answer from someone who already has any knowledge about this issue. regards Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 10794] - User interaction for authentication
Hi Oleg, I trust you on this. Unfortunately, I currently haven't got the time to look at the patch. From the discussion I got the feeling that we agree. cheers, Roland Kalnichevski, Oleg [EMAIL PROTECTED] 02.02.2004 11:36 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:RE: DO NOT REPLY [Bug 10794] - User interaction for authentication Odi, Roland Do you think you can live with this implementation? Can I commit the patch? Oleg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, January 30, 2004 22:09 To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 10794] - User interaction for authentication 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=10794. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794 User interaction for authentication --- Additional Comments From [EMAIL PROTECTED] 2004-01-30 21:09 --- Oleg, Good point. Code-wise everything looks good to me now. With a little CredentialsProvider Javadocs it is good to commit. Mike - 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]
Re: Promote HttpClient out of commons?
Hello folks, after taking a look on the project list at http://jakarta.apache.org/, I'd feel comfortable to see the HTTP Client among them. It sure wouldn't hurt it's visibility either. I see two major points why it should not be promoted to top level status. The technical reason is the pendig API overhaul. We know it's going to change fundamentally, so I wouldn't like to lure new users to the current API. And the new one isn't even started yet. The organizational reason is Oleg's announcement last year that he's going to scale back his efforts after the API overhaul. I'm sure this will cause some disruption in the development and support process. Unless the committers feel strongly that they can handle the transition smoothly, I recommend to cook this project on the lower flame of Jakarta rather than on the top level. just my 0.02 (Euro), Roland
Re: access denied exception
Hello,
this looks like a Java2 security problem. Two options:
Hack: Disable Java2 security.
Clean: grant your application the necessary permissions
in the java.policy file
The file should be in ${JAVA_HOME}/jre/lib/security/
I hope someone else can come up with the exact
permission entries required for the HTTP Client.
best regards,
Roland
D Alvarado [EMAIL PROTECTED]
30.01.2004 06:36
Please respond to Commons HttpClient Project
To: [EMAIL PROTECTED]
cc:
Subject:access denied exception
Hi, I was hoping someone could help me with this
exception. I'm trying to POST some data to a
remote site using https. The code is almost
directly from jakarta:
// Create an instance of HttpClient.
HttpClient client = new HttpClient();
client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
// Create a method instance.
PostMethod method = new
PostMethod(https://www.thirdparty.com;);
method.setRequestBody(data);
// Execute the method.
int statusCode = -1;
int attempt = 0;
// We will retry up to 3 times.
while (statusCode == -1 attempt 3) {
try {
// execute the method.
statusCode =
client.executeMethod(method);
} catch (HttpRecoverableException
e) {
System.err.println(A
recoverable exception occurred, retrying. +
e.getMessage());
} catch (IOException e) {
System.err.println(Failed to download file.);
e.printStackTrace();
}
}
// Check that we didn't run out of retries.
if (statusCode == -1) {
System.err.println(Failed to
recover from exception.);
}
I am running WebLogic 5.1 sp12, with the lastest
version of JSSE. But the above code generates
the following exception:
java.security.AccessControlException: access
denied (java.security.SecurityPermission
getProperty.ssl.SocketFactory.provider)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at
java.security.Security.getProperty(Security.java:879)
at javax.net.ssl.SSLSocketFactory$1.run(DashoA6275)
at
java.security.AccessController.doPrivileged(Native
Method)
at javax.net.ssl.SSLSocketFactory.a(DashoA6275)
at
javax.net.ssl.SSLSocketFactory.getDefault(DashoA6275)
at
org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:112)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:663)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:661)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529)
at
jsp_servlet._ma._thinkwell._student.__tw_student_redirect._jspService(__tw_student_redirect.java:238)
at lycea.ui.LyceaJspServlet.service(Unknown Source)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:138)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:945)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:909)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:269)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:392)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:274)
at
weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)
Any thoughts? Thanks for your time, Dave
Care2 make the world greener!
Think twice before eating farmed salmon. Find out why:
http://www.care2.com/go/z/11051/1067
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: Why on earth do we differenciate between proxy and host credentials?
Hello Oleg, from a technical standpoint, host and port would be sufficient to differentiate between a proxy and HTTP server on the same machine. But if a dialog is presented to a user, that dialog should state whether the user is supposed to enter uid/pwd for the proxy or for the host. Most users will not be able to make this distinction based on the port number. I wonder whether most programmers can? ;-) cheers, Roland Kalnichevski, Oleg [EMAIL PROTECTED] 29.01.2004 15:08 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Why on earth do we differenciate between proxy and host credentials? While going through the Odi's latest patch, I got hit by an idea. Why on earth do we differentiate between proxy and host credentials? At the end of the day do we care? The distinction between proxies and target hosts is not relevant from the HttpState standpoint as long as credentials can be uniquely identified by realm/host/port. All we need to ability to differentiate credentials by authentication realm, host AND port. I think we would make API much simpler and authentication code much cleaner by deprecating HttpState#get/setProxyCredentials stuff for good. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PostMethod.setFollowRedirects(true); - do nothing
Hello Jean-Remi, 1. make the POST request 2. look for the Location header 3. make the GET request to the Location The output you copied shows only the requests you send. The Location header is not in the request, it is in the response to step 1. Therefore, I suspect you made a mistake in step 2, possibly by looking in the wrong place. You need to do the following: Header location = postMethod.getResponseHeader(Location); where 'postMethod' is the method you executed in step 1. I hope this helps, Roland JEAN REMI LECQ [EMAIL PROTECTED] 29.01.2004 14:56 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:PostMethod.setFollowRedirects(true); - do nothing Sorry to come again with the same question, but I do not know what to do... I read carefully your replies and do what you said but... My problem is that I have to send my first GET request to a specific URL (I can not modify that, it is not mine), this page fill a form with my parameters and submit them automatically to an another URL (in the same domaine, I know this second URL). The submission is automatic and is in POST methode, I have to follow it to catch the resuls... I catched the cookies. I tried to make the first request in POST to send my parameters and make the second in GET to the forward URL(http://www.XXX.com/mirror/etape2h.cfm?ref=0144259402). But I have always the same error message even if I put the setFollowRedirects method at TRUE : 29 janv. 2004 14:53:33 org.apache.commons.httpclient.HttpMethodBase processRedirectResponse INFO: Redirect requested but followRedirects is disabled I also tried to make the first request under POST for catching the location header, but there is nothing like that in anyone of the redirection: GET http://www.XXX.com/mirror/listehotels.cfm?Vilarr=MRSDatDep=300104DatArr=0 10204Adultes=2ENFANTS=0BEBES=0ref=0144259402 HTTP/1.0 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */* Accept-Language: fr Cookie: CFID=41696517; CFTOKEN=19746368 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: www.XXX.com Proxy-Connection: Keep-Alive POST http://www.XXX.com/mirror/etape2h.cfm?ref=0144259402 HTTP/1.0 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */* Referer: http://www.XXX.com/mirror/listehotels.cfm?Vilarr=MRSDatDep=300104DatArr=0 10204Adultes=2ENFANTS=0BEBES=0ref=0144259402 Accept-Language: fr Content-Type: application/x-www-form-urlencoded Proxy-Connection: Keep-Alive User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: www.XXX.com Content-Length: 234 Pragma: no-cache Cookie: CFID=41696517; CFTOKEN=19746368 destination=228Date_Depart=30%2F01%2F2004Date_Retour=01%2F02%2F2004Date_D epart_h=30%2F01%2F2004Date_Retour_h=01%2F02%2F2004AllerRetour=1ADULTES=2 ENFANTS=0BEBES=0dated=300104dater=010204ref=0144259402codego=261ville_ hotel=GET http://www.XXX.com/mirror/habillage_go/page/styleaac.css HTTP/1.0 Accept: */* Referer: http://www.XXX.com/mirror/etape2h.cfm?ref=0144259402 Accept-Language: fr Proxy-Connection: Keep-Alive If-Modified-Since: Tue, 13 Jan 2004 16:25:09 GMT If-None-Match: d1062f51-1-b4c-40041be5 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: www.XXX.com Cookie: CFID=41696517; CFTOKEN=19746368 help... :-( jeanremi -Message d'origine- De : Ortwin Glück [mailto:[EMAIL PROTECTED] Envoyé : mercredi 21 janvier 2004 08:35 À : Commons HttpClient Project Objet : Re: PostMethod.setFollowRedirects(true); - do nothing Eric Johnson wrote: Redirect on a POST request is *not supported* This stems from fundamental architectural limitations of the current HttpClient 2.0 design. Actually the problem is two-fold: 1. redirect in HttpClient means: The *same* request ist sent to a different URL (on the same host). The HTTP Protocol (RFC 2616) explicitly forbids this kind of redirection for entity enclosing methods without any user interaction. That's why the flag is set to false. 2. A Location (redirect) header as a response to a POST request is handled as a GET request to the new URL by browsers. HttpClients design does not currently allow chaning the method on the fly. That's why you need to handle this yourself. Odi -- _ NOSE applied intelligence ag ortwin glück [www] http://www.nose.ch software engineer [email] [EMAIL PROTECTED] hardturmstrasse 171 [pgp key] 0x81CF3416 8005 zürich [office] +41-1-277 57 35 switzerland [fax] +41-1-277 57 12
Re: Connection Reset Error
Hi Eric, from RFC 2616 (HTTP 1.1), section 10.1: A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Our HTTP Client handles this correctly. cheers, Roland Eric Johnson [EMAIL PROTECTED] 27.01.2004 19:30 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: Connection Reset Error I'm pretty sure a 100 response can only be sent once according to the spec. If that approach did happen to work, it would be sheer chance. -Eric. Roland Weber wrote: I wonder wheter a status 100 response can be used for this purpose. HttpClient would simply ignore it and wait for the next response. regards, Roland Ortwin Glück [EMAIL PROTECTED] 27.01.2004 08:10 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: Connection Reset Error Why not let the servlet send some heartbeats. i.e. every minute send back some string that informs about the progress or just a simple I am still alive. Odi David Webb wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connection Reset Error
I wonder wheter a status 100 response can be used for this purpose. HttpClient would simply ignore it and wait for the next response. regards, Roland Ortwin Glück [EMAIL PROTECTED] 27.01.2004 08:10 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: Connection Reset Error Why not let the servlet send some heartbeats. i.e. every minute send back some string that informs about the progress or just a simple I am still alive. Odi David Webb wrote: 2) HP-UX / JDK1.4.X - Runs for about 15 minutes then throws the following exception: Exception thrown: java.net.SocketException: Connection reset Is there anything I can do in HttpClient to prevent this from happening? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Odd problem
Hello Brett, the 11b should be part of the chunked encoding used by the server to send back the error page. No reason to worry. I wonder why the server reports a missing page / although that's not the page you requested. Without knowledge of the server application, it is hard to tell how the server determines the page it should return. Here is my guess... HttpClient: Referer: https://target.com/app/login/nllogin.nl[\r][\n] IE: Referer: https://target.com/pages/login.jsp?rdt=%2Fapp%2Fcenter%2Fmyroles.nl You could try to set a different Referer header in your request. best regards, Roland Brett Knights [EMAIL PROTECTED] 27.01.2004 06:15 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Odd problem Hi, I am using RC3 with jdk 1.4.2_03 When I use http client to get to the site I get a 404 (http client wire log follows then grinder generated IE trace). I just can't see what is going wrong. Any suggestions are appreciated. This is part of a larger scripted operation so I am wondering if if is possible that I am stepping on something by not releasing connections correctly. The 11b at 26 Jan 2004 20:54:20,38726 Jan 2004 20:54:20,387 seems rather odd. DEBUG [main] httpclient.wire - GET /app/center/myroles.nl HTTP/1.1[\r][\n]: 26 Jan 2004 20:54:20,247 DEBUG [main] httpclient.wire - User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461)[\r][\n]: 26 Jan 2004 20:54:20,247 DEBUG [main] httpclient.wire - Referer: https://target.com/app/login/nllogin.nl[\r][\n]: 26 Jan 2004 20:54:20,247 DEBUG [main] httpclient.wire - Host: target.com[\r][\n]: 26 Jan 2004 20:54:20,247 DEBUG [main] httpclient.wire - Cookie: NS_VER=9.1[\r][\n]: 26 Jan 2004 20:54:20,247 DEBUG [main] httpclient.wire - Cookie: JSESSIONID=536c011ea00848b78315913117b9c243.mkbxr2PEmlnva30N-BbQmkLz-A Tzr6Lzn6rzqwTxpQOUc30KaNDvmQbJrkTOokTBrxyL8Q5xmReHoA5Qmh0KaMTvmQbO-kDv rA4Ka3aIqRnvp6iIpAjOp6jynQjM-AbJpgaTax4SbwbCpQPz8QvJpkixn6jAmljGr5XDqQ LvpAe_[\r][\n]: 26 Jan 2004 20:54:20,247 DEBUG [main] httpclient.wire - Cookie: lastUser=ACCT102534_3_3[\r][\n]: 26 Jan 2004 20:54:20,257 DEBUG [main] httpclient.wire - Cookie: T16:byMeU53W=[\r][\n]: 26 Jan 2004 20:54:20,257 DEBUG [main] httpclient.wire - [\r][\n]: 26 Jan 2004 20:54:20,257 DEBUG [main] httpclient.wire - HTTP/1.1 404 Not Found[\r][\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - Date: Tue, 27 Jan 2004 04:54:26 GMT[\r][\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - Server: Oracle9iAS/9.0.2 Oracle HTTP Server[\r][\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - Transfer-Encoding: chunked[\r][\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - Content-Type: text/html; charset=iso-8859-1[\r][\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - 1: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - 1: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - b: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - [\r]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - [\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN[\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - HTMLHEAD[\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - TITLE404 Not Found/TITLE[\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - /HEADBODY[\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - H1Not Found/H1[\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - The requested URL / was not found on this server.P[\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - HR[\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - ADDRESSOracle HTTP Server/1.3.22 Server at target.com Port 444/ADDRESS[\n]: 26 Jan 2004 20:54:20,387 DEBUG [main] httpclient.wire - /BODY/HTML[\n]: 26 Jan 2004 20:54:20,397 DEBUG [main] httpclient.wire - [\r]: 26 Jan 2004 20:54:20,397 DEBUG [main] httpclient.wire - [\n]: 26 Jan 2004 20:54:20,397 DEBUG [main] httpclient.wire - 0: 26 Jan 2004 20:54:20,397 DEBUG [main] httpclient.wire - [\r]: 26 Jan 2004 20:54:20,397 DEBUG [main] httpclient.wire - [\n]: 26 Jan 2004 20:54:20,397 DEBUG [main] httpclient.wire - [\r]: 26 Jan 2004 20:54:20,397 DEBUG [main] httpclient.wire - [\n]: 26 Jan 2004 20:54:20,397 When I use IE I get the page expected: -- localhost:2290-target.com:443 -- GET /app/center/myroles.nl HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, application/x-shockwave-flash, application/vnd.ms-excel, */* Referer: https://target.com/pages/login.jsp?rdt=%2Fapp%2Fcenter%2Fmyroles.nl Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461) Host: target.com Connection: Keep-Alive Cache-Control: no-cache Cookie: lastUser=ACCT102534_3_3; NLVisitorId=GEVsNmOJAOKYoS-W;
Re: Horseplay - https
Hello Charles, you suspect correctly, the login form comes from https://reg.racingpost.co.uk/cde/login_iframe.sd as you can easily verify by accessing that URL directly in your browser. From there, the login form is sent as a POST request to reg.racingpost.co.uk HttpClient can deal with the requests that need to be sent to the server. Unfortunately, there is plenty of JavaScript in www.racingpost.co.uk, and HttpClient won't help you with that. Also, the interaction between www.racingpost.co.uk and reg.racingpost.co.uk needs further analysis. In the easiest case, reg.racingpost.co.uk sets a cookie for .racingpost.co.uk as the result of the successful login. Then, you can use HttpClient without a problem. I suggest you try and send the equivalent of the POST request that is generated in the login IFrame and see what comes back. If you have problems with SSL support, you can refer to the SSL guide at http://jakarta.apache.org/commons/httpclient/sslguide.html and to the mailing list archives. cheers, Roland Charles Johnson [EMAIL PROTECTED] 11.01.2004 21:44 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Horseplay - https My objective is to log in to this site using httpclient: http://www.racingpost.co.uk/horses The first problem is that I can't see the connection between the following request (gleaned from my browser + proxy) and the login form you see at the top of the page. Evidently this GET request (why no POST?) has an encrypted parameter string. Where has it come from? Where has the parameter name come from? Is it anything to do with this, which is in the page?: IFRAME SRC=https://reg.racingpost.co.uk/cde/login_iframe.sd; etc. Can httpclient cope? Here's the request: 2. Then log in using the button at the top: -- REQUEST --- GET /horses/?MIval=rp_reg_initTMP_CK_CK=%7Fv%7Dw5u%2F2%23%24%22VML%5BCUGBJY HTTP/1.1 Host: www.racingpost.co.uk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1 Accept-Language: en-gb Accept-Encoding: gzip, deflate, compress;q=0.9 Accept-Charset: utf-8, * Keep-Alive: 300 Cookie: session.ID=IDa200fff6130d72; PermRpLogin=httpclient - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: refresh header proxy
Hello David, are you sure the browsers are handling the HTTP header field and not the contents of the HTML document returned? The syntax of the header field resembles the typical HTML refresh statement: meta http-equiv=refresh content=0; URL=... It is common (maybe even standard?) behaviour for browsers to interpret this meta tag, which does not mean they interpret the corresponding HTTP header. The header never became a standard, as pointed out by others. Have you tried to return a Refresh: header for a document that does definitely not contain the meta tag? cheers, Roland David Rosenstark [EMAIL PROTECTED] 12.01.2004 15:16 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:RE: refresh header proxy ok, good point. I tried out just resending the requests twice and it did not work, so it obviously needs to be studied more and would probably require some additional headers be sent. By studying the logs, i found that the proxy server must be blue coat. One more thing. While it may not be standard - mozilla and IE handle this header just fine. I sent you the log (and not the list) as i was unsure whether the list rules would want something like that sent. Thanks, David -Original Message- From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] Sent: Mon, January 12, 2004 3:25 PM To: Commons HttpClient Project Subject: RE: refresh header proxy I think all you need to know is what the header looks like, as i did look at the logs. It simply ignores the header. The header looks like this: Refresh: 0; URL=https:// Well, things _may_ be a little bit more complicated than that. Therefore, the complete wirelog might be beneficial. Besides, the wirelog would also tell me what proxy server you are using. At the moment, having done some googling I failed to find any references to a 'refresh' header definition. If the header in question is a proprietary feature of the proxy server that you are using, I doubt it warrants the inclusion into the stock version of HttpClient. I believe the connection refresh stuff can be easily implemented with a little bit of code on top of standard HttpClient. Oleg -Original Message- From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] Sent: Mon, January 12, 2004 2:51 PM To: Commons HttpClient Project Subject: RE: refresh header proxy David, No, it is not. However, as we are currently in the process of reengineering authentication/proxy code, if you provide the wirelog/debug of the HTTP session in question, we might be able to add such feature to the development branch of HttpClient in the forthcoming weeks For details on logging in HttpClient please refer to the HttpClient logging guide http://jakarta.apache.org/commons/httpclient/logging.html Cheers Oleg -Original Message- From: David Rosenstark [mailto:[EMAIL PROTECTED] Sent: Monday, January 12, 2004 13:47 To: Commons HttpClient Project Subject: refresh header proxy Is the refresh header supposed to be supported by httpclient (latest version)? I have been trying to connect to a site (SSL) through our proxy and it send me back a header with refresh: 0, URL=https://. and httpclient is not requesting it from there. TIA, David - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Make HttpClient pick Basic Auth over NTLM?
Hello, try client.getState().setAuthenticationPreemptive(true); I'm not sure whether HTTP Client evaluates this flag for proxy and target server, or just for the target server. In the first case, it should have the desired effect. My guess is that when HTTP Client has the choice between Basic and NTLM Auth, it picks NTLM. By enabling preemptive authentication, it has to choose Basic because that's the only thing for which there are credentials. regards, Roland anon permutation [EMAIL PROTECTED] 04.12.2003 06:16 Please respond to Commons HttpClient Project To: [EMAIL PROTECTED] cc: Subject:Make HttpClient pick Basic Auth over NTLM? Hi, I am using a proxy server that supports both NTLM and Basic Authentications. How do I make HttpClient use Basic Auth. instead of NTLM? I am using 2.0-rc2. Following is my code: HttpClient client = new HttpClient(); HttpMethod method = null; client.getState().setProxyCredentials(null, new UsernamePasswordCredentials(user,passwd)); HostConfiguration hc = client.getHostConfiguration(); hc.setProxy(10.0.0.2, 80); method = new GetMethod(url); client.executeMethod(method); byte[] responseBody = method.getResponseBody(); - I am getting this error: Credentials cannot be used for NTLM authentication Thanks. _ Browse styles for all ages, from the latest looks to cozy weekend wear at MSN Shopping. And check out the beauty products! http://shopping.msn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Make HttpClient pick Basic Auth over NTLM?
Hello Eric, it's a question of interpretation, isn't it? If we provide an option to prefer Basic auth over NTLM, we violate the RFC. If we provide an option to *disable* NTLM in certain cases, HttpClient would no longer understand it, and has to select Basic following the rules of the RFC :-) cheers, Roland Eric Johnson [EMAIL PROTECTED] 04.12.2003 15:31 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: Make HttpClient pick Basic Auth over NTLM? I'm not sure that HttpClient should do anything different. According to section 4.6 of RFC 2617, A user agent MUST choose to use the strongest auth- scheme it understands and request credentials from the user based upon that challenge. Since Basic is pretty darn weak, I'd say NTLM wins out every time. Is this a point on which HttpClient should have an option to override the RFC mandated behavior? As somewhat of a fanatic about security, my take is that you should be forced to do the right thing, and if you really want to, the source is there for you to modify. -Eric. anon permutation wrote: Hi, I am using a proxy server that supports both NTLM and Basic Authentications. How do I make HttpClient use Basic Auth. instead of NTLM? I am using 2.0-rc2. Following is my code: HttpClient client = new HttpClient(); HttpMethod method = null; client.getState().setProxyCredentials(null, new UsernamePasswordCredentials(user,passwd)); HostConfiguration hc = client.getHostConfiguration(); hc.setProxy(10.0.0.2, 80); method = new GetMethod(url); client.executeMethod(method); byte[] responseBody = method.getResponseBody(); - I am getting this error: Credentials cannot be used for NTLM authentication Thanks. _ Browse styles for all ages, from the latest looks to cozy weekend wear at MSN Shopping. And check out the beauty products! http://shopping.msn.com - 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]
Re: Cookies, Chunked-Post Threads
Hello Sven, browsers make requests in parallel for *one* user! Meaning that all the cookies returned end up in the same cookie store, as they do here. A proxy servlet will make requests for different users (browsers) and therefore has to maintain a different state for each user. That state is typically associated with the session between the browser and servlet. I have rewritten our own proxy servlet to optionally use the HTTP Client instead of the HttpURLConnection, and I didn't encounter problems with parallel requests by now. Which could also indicate that I didn't have enough time to test it thoroughly yet :-) Anyway, I handle cookie and set-cookie headers manually and use a single state object that does never store any cookies. And when manually handling the cookies, I use a CookieBox class that gets instantiated once for each session. It's either that, or different state objects for each session. But you can't just throw all cookies returned for all users into a single state and expect the HTTP client to figure out which cookie belongs to which user. regards, Roland Sven Köhler [EMAIL PROTECTED] 12.11.2003 15:40 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: Cookies, Chunked-Post Threads unless you have taken special precautions, the state object is used to store cookies. Using the same state from different threads can mix up the cookies from different clients pretty badly. Once you have the cookie problem solved, there is no issue with using the same state object. I dimly remember seeing some synchronized statements in there. Anyway, except for storing cookies, it is accessed read-only. Well, it's a that odd application of the HttpState-Object since every browser makes multiple requests to a server in parrallel. So this would be a feature i would request. Well, most methods of HttpState seem to be synchronized, but as i already mentioned, it's pretty easy to easy to solve any bad mix-up. What i don't want is to serialize (meaning executing one after another) the HTTP-Requests. I want them to execute in parralel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies, Chunked-Post Threads
Hello Sven, 1. Cookie Container: Let every session use it's own HttpState object. That's where HTTP Client stores it's cookies. The only problem is that it's not serializable, so it won't work with persistent sessions. 2. Thread Safety: HTTP Client is thread safe as long as you use a thread safe connection manager. 3. Unlimited Requests: Adjust the parameters of the MultiThreadedConnectionManager to change the maximum number of simultaneous requests. Your servlet container most likely has some load limitation policy, so you don't have to allow much more connections than there are threads to execute servlets. (no clue about content length in POST requests) regards, Roland Sven Köhler [EMAIL PROTECTED] 12.11.2003 01:55 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Cookies, Chunked-Post Threads Hi, i'm working on a so called ProxyServlet which uses the Information provided by the ServletContainer to deliver the Requests to another Web-Server. At present, i'm using the HttpMethod-Objects (GetMethod, PutMethod, ...) and HttpClient.execute() to deliver the Requests to the other Web-Server. I hope you can provide me with some sollutions to the following Problems: - I like to maintain one Cookie-Container for each Session (Session = Session-Object offered by the Servlet-Container) - I like my Servlet to be Thread-safe and be abled to deliver many (unlimited) requests at a time - I tried to avoid the Content-Length Header in POST requests by using Chunked Transfer-Encoding, but the Apache-Server i'm using for testing seems to deny chunked POST-requests. Well, how's cookie-management done in Commons-HttpClient? Does each HttpClient-Object maintain it's own Cookie-Container? HttpClient.execute() doesn't seem to be thread-safe. I like chunked Transfer-Encoding since is more like a stream and not like that huge block of data that's usually used (content-length header etc.) Are chunked POST-Requests not allowed? Well, i'm setting the content-length header right now if it is provided to the servlet. So that's a big proble, but i'm just curious. Thx Sven - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
