Re: [ANNOUNCE] HttpClient is now a separate project in [Bugzilla] issue tracking system
We should be able to arrange for someone to have bugzilla admin privileges so they can do it. At the very least someone from the Jakarta PMC should be able to do it. Adrian. On 12/10/2004, at 7:36 PM, Oleg Kalnichevski wrote: On Tue, 2004-10-12 at 03:42, Michael Becke wrote: Hi Oleg, How do we go about adding versions, target milestones, etc? Mike Mike, We still will have to ask the Infrastructure. The good news is creating new versions and milestones in Bugzilla takes no special trickery, so it _should_ be relatively easy. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 3420 4584 0422236329 35 Prenzler St Upper Mount Gravatt 4122 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Re: HttpClient with Applet to upload files using MultipartPost is required....
Hi Srinivas, Sorry for the delay in getting back to you. There really is nothing different about using HttpClient in an applet compared to an application. I suggest you first get HttpClient working for you in a standalone application and then move it into an applet. If you have trouble getting HttpClient to work in an application please post the code you're using and if possible the debug log (see http://jakarta.apache.org/commons/httpclient/logging.html ). Regards, Adrian Sutton. On 08/10/2004, at 7:01 PM, Srinivas Velidanda wrote: Hi Adrian Sutton, thanks for the mail. I need some help regarding using Applet with HttpClient. I am able to make the signed applet get opened in the Internet Explorer, but I got stuck up 1. couldn't grant permissions to read a particular folder at client side. 2. Even If I do that I am not clear with pass the multipart request created in the applet to the servlet. I have been working with it since 1 week but couldn't find the right solution. As far as I know applet can communicate to the servlet using the URLConnection, URLEncoder but how can I make the MultiparPost request linked to the request from applet. Pl. suggest me a solution., thank you, Srinivas. Adrian Sutton [EMAIL PROTECTED] wrote: On 08/10/2004, at 5:21 PM, Srinivas Velidanda wrote: Hi, can I get the sample java code to make the signed applet with HttpClient. No unfortunately we develop a commercial product so I can't release the code. However, the usage of HttpClient is exactly the same in an applet as an application. You do however need to make sure the applet is signed and that you are using at least Java 1.3 (ie: you can't be using the Microsoft JVM that is the default in Windows IE). When you load the applet it should bring up a security dialog asking if you want to give the applet permission to run, click yes and you have full permissions. If you don't see that dialog then the applet isn't correctly signed. thanks, Srinivas. Regards, Adrian Sutton -- Intencha tomorrow's technology today Ph: 3420 4584 0422236329 35 Prenzler St Upper Mount Gravatt 4122 Australia QLD www.intencha.com ATTACHMENT part 2 application/pgp-signature x-mac-type=70674453; name=PGP.sig - Do you Yahoo!? Yahoo! Mail - You care about security. So do we. -- Intencha tomorrow's technology today Ph: 3420 4584 0422236329 35 Prenzler St Upper Mount Gravatt 4122 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Bugzilla
Hi all, Oleg has done a fantastic job in finally getting HttpClient converted from a component to a real project in bugzilla. There are a couple of things remaining that some help could be used on: 1. Check that everything looks right after the migration (the standard bugzilla installation on nagoya should now show the migrated version). 2. Decide if we now want to convert over to JIRA or stay with Bugzilla. Most of our issues with bugzilla should be solved now that we're a full project, however JIRA is much better supported than Bugzilla so we may want to move anyway. Let me know your thoughts and we'll unleash evil comrade Oleg on the infrastructure team again. :) Three big cheers to Oleg for following through on this. I don't mean to steal the thunder of the announcement but figured I'd keep the messages flowing during the night shift (aka: Australian day time). Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 3420 4584 0422236329 35 Prenzler St Upper Mount Gravatt 4122 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Re: HttpClient with Applet to upload files using MultipartPost is required....
On 08/10/2004, at 4:43 PM, Srinivas Velidanda wrote: Hi, I got a sample signed applet working that is given at the links you specified. but need help using it with HttpClient... Pl let me know if somebody already worked with applet using HttpClient. Hi Srinivas, We use HttpClient extensively from within a signed applet. As long as an applet is correctly signed, it has the same permissions as a stand-alone application. thanks. Srinivas. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 3420 4584 0422236329 35 Prenzler St Upper Mount Gravatt 4122 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Re: HttpClient with Applet to upload files using MultipartPost is required....
On 08/10/2004, at 5:21 PM, Srinivas Velidanda wrote: Hi, can I get the sample java code to make the signed applet with HttpClient. No unfortunately we develop a commercial product so I can't release the code. However, the usage of HttpClient is exactly the same in an applet as an application. You do however need to make sure the applet is signed and that you are using at least Java 1.3 (ie: you can't be using the Microsoft JVM that is the default in Windows IE). When you load the applet it should bring up a security dialog asking if you want to give the applet permission to run, click yes and you have full permissions. If you don't see that dialog then the applet isn't correctly signed. thanks, Srinivas. Regards, Adrian Sutton -- Intencha tomorrow's technology today Ph: 3420 4584 0422236329 35 Prenzler St Upper Mount Gravatt 4122 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Re: Documentation Updates
Oops, sorry I forgot about branches. That's now done. Regards, Adrian Sutton. On 03/08/2004, at 8:57 PM, Michael Becke wrote: Hi Adrian, Could you add these to 2.0 as well? The site is currently built from 2.0. Mike -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Re: Documentation Updates
These updates have now been committed and will go live whenever the
site is next deployed.
Regards,
Adrian Sutton.
On 02/08/2004, at 9:53 PM, Michael Becke wrote:
Sounds good.
Mike
On Aug 2, 2004, at 3:41 AM, Adrian Sutton wrote:
Some minor documentation updates:
* Remove To be completed from the index pages. Those pages were
completed long ago.
* Moved the call to releaseConnection into a finally block in the
tutorial (that code is getting copied into a lot of projects so we
should probably get it right).
* Added a note that users should ensure that log4j is configured to
avoid performance problems. (Bug 29973)
Patch is inline below, if I don't hear any complaints I'll commit it
later on tonight or tomorrow.
Regards,
Adrian Sutton.
Index: logging.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/logging.xml,v
retrieving revision 1.13
diff -u -r1.13 logging.xml
--- logging.xml 5 Jul 2004 20:47:53 - 1.13
+++ logging.xml 2 Aug 2004 07:35:07 -
@@ -142,6 +142,11 @@
log4j.logger.org.apache.commons.httpclient=DEBUGbr /
/blockquote
/p
+ pNote that the default configuration for Log4J is very
+ inefficient as it causes all the logging information to
be
+ generated but not actually sent anywhere. The Log4J
manual is the
+ best reference for how to configure Log4J. It is
available at a
+
href=http://logging.apache.org/log4j/docs/manual.html;http://
logging.apache.org/log4j/docs/manual.html/a
/subsection
/section
/body
Index: tutorial.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/tutorial.xml,v
retrieving revision 1.5
diff -u -r1.5 tutorial.xml
--- tutorial.xml 23 Feb 2004 23:05:43 - 1.5
+++ tutorial.xml 2 Aug 2004 07:35:07 -
@@ -207,39 +207,44 @@
// Create a method instance.
HttpMethod method = new GetMethod(url);
-
-// Execute the method.
-int statusCode = -1;
-// We will retry up to 3 times.
-for (int attempt = 0; statusCode == -1 attempt 3;
attempt++) {
- 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();
-System.exit(-1);
+
+try {
+ // Execute the method.
+ int statusCode = -1;
+ byte[] responseBody = null;
+ // We will retry up to 3 times.
+ for (int attempt = 0; statusCode == -1 attempt 3;
attempt++) {
+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();
+ System.exit(-1);
+}
+ }
+ // Check that we didn't run out of retries.
+ if (statusCode == -1) {
+System.err.println(Failed to recover from
exception.);
+System.exit(-2);
}
-}
-// Check that we didn't run out of retries.
-if (statusCode == -1) {
- System.err.println(Failed to recover from
exception.);
- System.exit(-2);
-}
-// Read the response body.
-byte[] responseBody = method.getResponseBody();
+ // Read the response body.
+ responseBody = method.getResponseBody();
-// Release the connection.
-method.releaseConnection();
+} finally {
+ // Release the connection.
+ method.releaseConnection();
+}
// Deal with the response.
// Use caution: ensure correct character encoding and is
not binary data
System.err.println(new String(responseBody));
+
}
}
]]/source
Index: userguide.xml
===
RCS file: /home/cvs/jakarta-commons/httpclient/xdocs/userguide.xml,v
retrieving revision 1.2
diff -u -r1.2 userguide.xml
--- userguide.xml 21 Aug 2003 16:08:54 - 1.2
+++ userguide.xml 2 Aug 2004 07:35:07 -
@@ -30,13 +30,13 @@
/tr
Re: Away until Aug 9 - will not be moderating the list
Jeff, Are you the only moderator for the HttpClient list? If so, I'd be happy to be added as a moderator to help out and to cover things while you're away. Regards, Adrian Sutton. On 31/07/2004, at 3:37 PM, Jeff Dever wrote: I'll be away on holiday untill April 9th. During this time, I will not be moderating the mailing list. On average, there are about 5 messages a day posted to the Httpclient-dev mailing list, but about 98% of those are spam messages that get filtered out. -jsd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Re: [VOTE] 2.0.1 release
+1 On 19/07/2004, at 12:21 PM, Michael Becke wrote: Pending the patch to bug #29897, I propose that we mark the latest code in CVS HTTPCLIENT_2_0 as 2.0.1 and proceed with a release. Please vote as follows: --- --- Vote: HttpClient 2.0.1 release [ ] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). --- --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Re: Cannot use HttpClient to search google
htmlheadtitle403 Forbidden/title blockquoteH1Forbidden/H1Your client does not have permission to get URL code/search?hl=enamp;ie=UTF-8amp;q=sql+server+trace/code from this server. (Client IP address: xx.xx.xx.xx)brbrPlease see Google's Terms of Service posted at http://www.google.com/terms_of_service.html I guess the main reason is google uses akamai's network to distribute loads. No it means you should read the terms of service, specifically the part about not using screen-scraping techniques to programatically perform searches (which is what you're trying to do). You should use the Google SOAP search service instead as it will make your life a lot easier. It would not be appropriate to discuss ways around the technical limitations Google uses to enforce their terms of service on an Apache Software Foundation mailing list. The particular section of the Google ToS that I believe applies here is listed under the Personal Use Only and No Automated Querying headings. Information on Google's SOAP APIs is available at http://www.google.com.au/apis/ (note they also have terms of service) Finally, sorry if this seems abrupt, it is important for the ASF to clearly not support use of their products in any way that may cause legal trouble. If you feel you are following the terms of services for Google and I've missed something then my apologies. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Re: Cannot use HttpClient to search google
Hi Vincent, While I appreciate that your intentions are not malicious and that you may well be within the terms of Google's service, I would very much prefer to avoid the potential issues altogether by not working around Google's technical limitations. For experimenting with HttpClient I'd suggest you just pick a different URL - http://jakarta.apache.org would be a good one. If you do come across this problem or ones like it at other sites where the terms of service are less risky then we can certainly help you work how to get HttpClient to access the site. You'll find in the list archives that we've helped quite a number of people get HttpClient to work with sites that for some reason pose technical problems (usually because of their lack of standards compliance). Regards, Adrian Sutton. On 12/07/2004, at 11:36 AM, Vincent Chain wrote: Well, I view this as a technical question. I have no intention to use the code for automated querying and this is for my experiment of the HttpClient. Google happens to be the URL i choose. There could be another host that does similar things as google, but does not enforce similar terms. And the issue would still be there right? I am asking a technical question here, but your points are taken. Thanks -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Re: NTLM authentication to an MS Exchange web page account using HTTP Client V2.0
Hi Steve, There's no way that I know of to do this, however the builtin handling for the JRE seems to manage it so there's probably a com.sun class around somewhere that makes it possible. It would definitely be possibly using JNI. It's on my todo list to investigate how this is done but it's a fairly low priority (not a single user has complained yet - presumably because few of our users use NTLM). If you do find out how to do it please do let us know. Regards, Adrian Sutton. On 24/06/2004, at 2:31 AM, Steve Johnson wrote: Hi All, Thanks again Adrian, very helpful. The NTCredentials API shows that the user, password, host, and domain can be set. Is it possible to use the logged-in users credentials? This way it would allow a user to be authenticated without reentering user/pw. Thanks for the help, Steve -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 22, 2004 4:20 PM To: Commons HttpClient Project Subject: Re: NTLM authentication to an MS Exchange web page account using HTTP Client V2.0 This sounds very much like the webserver isn't really using NTLM but is using Digest/Basic instead. If it really were using NTLM passing in DOMAIN\User would definitely not work because HttpClient doesn't check for that case. That would also explain why the realm isn't what you expect. I'd say a wire log should shed a lot of light on the situation (see http://jakarta.apache.org/commons/httpclient/logging.html ) Regards, Adrian Sutton On 23/06/2004, at 3:43 AM, Steve Johnson wrote: Hi All, Using HTTPClient version 2.0 We are using HTTPClient to login to a MS Exchange web page account. We can only get it to work by passing in the realm as null, and putting the domain back on to the front of the user to pass into NTCredentials(). new NTCredentials(authUserNameAppendDomainWithBackSlash + settings.getAuthUserName(), settings.getAuthPassword(), settings.getHost(), settings.getAuthDomain()) The comments on the interface say that only the username should be passed in, and NOT the domain. For other NTLM pages it works to use only the user, but this page has not worked for us without the domain like this myDomain\myUser. On State.setCredentials() we have tried passing the host, null, and the string realm in without the domain appended to user. All these attempts fail. We would prefer to use the API without the domain on the user. client.getState().setCredentials( null, //realm, null, settings.getHost()- settings.getHost(), new NTCredentials(authUserNameAppendDomain + settings.getAuthUserName(), settings.getAuthPassword(), settings.getHost(), settings.getAuthDomain()) ); Is there some documentation on how the realm interacts with authentication? Thanks for your time and effort, 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 -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Re: NTLM authentication to an MS Exchange web page account using HTTP Client V2.0
This sounds very much like the webserver isn't really using NTLM but is using Digest/Basic instead. If it really were using NTLM passing in DOMAIN\User would definitely not work because HttpClient doesn't check for that case. That would also explain why the realm isn't what you expect. I'd say a wire log should shed a lot of light on the situation (see http://jakarta.apache.org/commons/httpclient/logging.html ) Regards, Adrian Sutton On 23/06/2004, at 3:43 AM, Steve Johnson wrote: Hi All, Using HTTPClient version 2.0 We are using HTTPClient to login to a MS Exchange web page account. We can only get it to work by passing in the realm as null, and putting the domain back on to the front of the user to pass into NTCredentials(). new NTCredentials(authUserNameAppendDomainWithBackSlash + settings.getAuthUserName(), settings.getAuthPassword(), settings.getHost(), settings.getAuthDomain()) The comments on the interface say that only the username should be passed in, and NOT the domain. For other NTLM pages it works to use only the user, but this page has not worked for us without the domain like this myDomain\myUser. On State.setCredentials() we have tried passing the host, null, and the string realm in without the domain appended to user. All these attempts fail. We would prefer to use the API without the domain on the user. client.getState().setCredentials( null, //realm, null, settings.getHost()- settings.getHost(), new NTCredentials(authUserNameAppendDomain + settings.getAuthUserName(), settings.getAuthPassword(), settings.getHost(), settings.getAuthDomain()) ); Is there some documentation on how the realm interacts with authentication? Thanks for your time and effort, 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 -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
Re: [VOTE][RESULT] 3.0 alpha 1 release
Does this need to be CC'd to pmc? It would probably be a good idea anyway. Thanks for your efforts Mike. Regards, Adrian Sutton. On 17/05/2004, at 10:36 AM, Michael Becke wrote: The vote to release 3.0 alpha 1 has passed with the following votes: +1 Michael Becke - mbecke at apache.org +1 Oleg Kalnichevski - olegk at apache.org +0 Ortwin Glück - oglueck at apache.org +1 Adrian Sutton - adrian at apache.org +0 Mohammad Rezaei - mohammad.rezaei at gs.com vote thread: http://nagoya.apache.org/eyebrowse/BrowseList?listName=commons- [EMAIL PROTECTED]by=threadfrom=767418 I will tag HEAD and proceed with a release. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3.0 alpha 1 release
With that all dealt with: +1 :) On 14/05/2004, at 7:50 PM, Ortwin Glück wrote: +0 with the patch for #28728 that was just committed. cheers Odi Michael Becke wrote: I propose that we mark the latest code in CVS HEAD as 3.0 alpha 1 and proceed with a release. Please vote as follows: -- -- -- Vote: HttpClient 3.0 alpha 1 release [ ] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). -- -- -- -- _ 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] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Migrate HttpClient issue tracking from Bugzilla to Jira
+1 I'm now on the infrastructure list btw and would be happy to take charge of getting this project done (I have no actual administrative powers but I do at least see what's going on). Regards, Adrian Sutton. On 10/05/2004, at 7:03 PM, Kalnichevski, Oleg wrote: Please vote as follows: - Vote: Migrate HttpClient issue tracking from Bugzilla to Jira [ ] +1 I am in favor of the proposal, and will help support it. [ ] +0 I am in favor of the proposal, but am unable to help support it. [ ] -0 I am not in favor of the proposal. [ ] -1 I am against this proposal (must include a reason). - Migration process is described here http://nagoya.apache.org/wiki/apachewiki.cgi?JIRABugzillaMigration Oleg -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS (NTLM) + proxy server (NTLM or basic) problem
Lili, Truth to be told, NTLM proxy + NTLM host authentication has never been properly tested, because none of us (HttpClient developers) has got access to a Microsoft Proxy installation. I would not be surprised if it did not work at all with HttpClient 2.0. I know for a fact that BASIC proxy + NTLM host should work. I have been using Squid proxy to run the tests, though. Woops, I didn't notice this fact. There is absolutely no way that HttpClient can authenticate with both an NTLM proxy and an NTLM host at the same time. The protocol just doesn't allow for it, mostly because either the host or the proxy will close the connection half way through the other's process of authentication, effectively resetting the authentication. If someone wanted to take the time to reverse engineer the process IE is using while talking to the proxy and the server and work out how it does it I'd be most interested in finding out. Last time I investigated this all the references I could find said it wasn't possible to do. In my tests with IE 5.5 and IIS as proxy and host I couldn't make the authentication work either. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS (NTLM) + proxy server (NTLM or basic) problem
It's already mentioned at http://jakarta.apache.org/commons/httpclient/authentication.html : 3. NTLM authenticates a connection and not a request, so you need to authenticate every time a new connection is made and keeping the connection open during authentication is vital. Due to this, NTLM cannot be used to authenticate with both a proxy and the server, nor can NTLM be used with HTTP 1.0 connections or servers that do not support HTTP keep-alives. On 04/05/2004, at 10:01 PM, Ortwin Glück wrote: Adrian Sutton wrote: There is absolutely no way that HttpClient can authenticate with both an NTLM proxy and an NTLM host at the same time. The protocol just doesn't allow for it, It would be worth mentioning that in a sentence or two in our authentication guide. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][PROPOSAL][RESULT] Promote HttpClient to Jakarta Level
The vote has passed. We will put forth the proposal below to the Jakarta PMC to move HttpClient to a Jakarta level project. The vote details are below: +1 votes - Adrian Sutton [EMAIL PROTECTED] Oleg Kalnichevski [EMAIL PROTECTED] Michael Becke [EMAIL PROTECTED] dIon Gillard [EMAIL PROTECTED] +0 votes - Ortwin Glück [EMAIL PROTECTED] Vote thread - http://nagoya.apache.org/eyebrowse/BrowseList?listName=commons-httpclient-de [EMAIL PROTECTED]by=threadfrom=681919 (0) RATIONALE HTTP is the main protocol used today on the internet. Although the JDK includes basic support for building HTTP-aware client applications, it doesn't provide the flexibility or ease of use needed for many projects. The current package in Jakarta-Commons is a widely used implementation with a strong community behind it. The size of it's community and it's project has significantly outgrown the commons project and a move to a Jakarta level project would provide better support for that community and for the on going development of HttpClient. (1) SCOPE The project shall create and maintain a Java library implementing the client side of the HTTP 1.0 and 1.1 protocol, as defined in RFC 1945, RFC 2616 and RFC 2617. HttpClient also supports the following RFCs. * RFC 2109 for HTTP state management mechanism (Cookies) - an upgrade to RFC 2965 is planned for a future version of HttpClient * RFC 2396 Uniform Resoruce Identifiers (URI): Generic Syntax * RFC 1867 Form-based File Upload in HTML The package should: * Have an API which should be as simple to use as possible * Be as easy to extend as possible * Provide unconditional support for HTTP/1.1 The package is quite different from the HTTP client provided as part of the JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods being sent (instead of making that transparent to the user), and generally allows more interaction with the lower level connection. The JDK client is also not very intuitive to use. The package is used by a wide range of projects both within the ASF and from third parties. These include: * Jakarta Slide * Jakarta Commons Latka * Nortel Networks * HtmlUnit * Jakarta Cactus * JSR 147 * NOSE Applied Intelligence ag * MindIQ's Design-a-Course * ContactOffice * Newknow * de4d2c * Furies * Term Highlighting for Verity Ultraseek search results * Mule - Universal Message Objects * many more. (1.5) Interaction With Other Packages HttpClient relies on: * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) * Jakarta commons-logging (Version 1.0 or later) * Jakarta commons-codec (Version 1.2 or later) (2) INITIAL SOURCE OF THE PACKAGE The initial codebase exists as a sub-project of Jakarta-Commons, in the httpclient subdirectory of the jakarta-commons cvs tree. The proposed package name for the new sub-project is org.apache.httpclient. (3) REQUIRED JAKARTA RESOURCES * CVS Repository - New module, jakarta-httpclient in the CVS repository. * Initial Committers - The list is provided below. All of the proposed committers are currently jakarta-commons committers. * Mailing List - Two new mailing lists will be required: [EMAIL PROTECTED] and [EMAIL PROTECTED] These will be used for developer discussions and user discussions respectively. CVS commit messages will be sent to the httpclient-dev list. * Bugzilla - New product category HttpClient, with appropriate version identifiers as needed. Existing bugs in the HttpClient component under the Commons product category will need to be migrated. (4) INITIAL COMMITTERS The initial committers on the HttpClient component shall be: * Michael Becke * Jeff Dever * dIon Gillard * Ortwin Glück * Oleg Kalnichevski * Adrian Sutton Adrian Sutton -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][PROPOSAL][RESULT] Promote HttpClient to Jakarta Level
On 29/3/04 8:47 PM, Adrian Sutton [EMAIL PROTECTED] wrote: The vote has passed. We will put forth the proposal below to the Jakarta PMC to move HttpClient to a Jakarta level project. The vote details are below: I also want to note that I've received replies from Rodney Waldhoff and Sung-Gu. Rodney wants to retain his emeritus committer status but doesn't currently have time to contribute to HttpClient - I assurred him that he can return to full active committer status at any stage. Sung-Gu is keen to rejoin the ranks of active HttpClient committers and apparently is faxing through his CLA at which point we will likely hear from him on this list. Regards, Adrian Sutton -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Hi all, Are there any further comments on this or are we ready to put it to a vote? I have not had any response from any of the inactive committers and figure a week is long enough to wait. They can of course be reinstated as a committer at any time in the future by just requesting it (and sorting out the CLA if need be). The proposal below is unchanged from the last draft with the only suggested change being moving the dependency to Java 1.3 - the consensus seems to be that there's no real cause for dropping Java 1.2 support at this stage. If there are no further suggestions I'll get a vote thread started in the next couple of days. Regards, Adrian Sutton. (0) RATIONALE HTTP is the main protocol used today on the internet. Although the JDK includes basic support for building HTTP-aware client applications, it doesn't provide the flexibility or ease of use needed for many projects. The current package in Jakarta-Commons is a widely used implementation with a strong community behind it. The size of it's community and it's project has significantly outgrown the commons project and a move to a Jakarta level project would provide better support for that community and for the on going development of HttpClient. (1) SCOPE The project shall create and maintain a Java library implementing the client side of the HTTP 1.0 and 1.1 protocol, as defined in RFC 1945, RFC 2616 and RFC 2617. HttpClient also supports the following RFCs. * RFC 2109 for HTTP state management mechanism (Cookies) - an upgrade to RFC 2965 is planned for a future version of HttpClient * RFC 2396 Uniform Resoruce Identifiers (URI): Generic Syntax * RFC 1867 Form-based File Upload in HTML The package should: * Have an API which should be as simple to use as possible * Be as easy to extend as possible * Provide unconditional support for HTTP/1.1 The package is quite different from the HTTP client provided as part of the JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods being sent (instead of making that transparent to the user), and generally allows more interaction with the lower level connection. The JDK client is also not very intuitive to use. The package is used by a wide range of projects both within the ASF and from third parties. These include: * Jakarta Slide * Jakarta Commons Latka * Nortel Networks * HtmlUnit * Jakarta Cactus * JSR 147 * NOSE Applied Intelligence ag * MindIQ's Design-a-Course * ContactOffice * Newknow * de4d2c * Furies * Term Highlighting for Verity Ultraseek search results * Mule - Universal Message Objects * many more. (1.5) Interaction With Other Packages HttpClient relies on: * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) * Jakarta commons-logging (Version 1.0 or later) * Jakarta commons-codec (Version 1.2 or later) (2) INITIAL SOURCE OF THE PACKAGE The initial codebase exists as a sub-project of Jakarta-Commons, in the httpclient subdirectory of the jakarta-commons cvs tree. The proposed package name for the new sub-project is org.apache.httpclient. (3) REQUIRED JAKARTA RESOURCES * CVS Repository - New module, jakarta-httpclient in the CVS repository. * Initial Committers - The list is provided below. All of the proposed committers are currently jakarta-commons committers. * Mailing List - Two new mailing lists will be required: [EMAIL PROTECTED] and [EMAIL PROTECTED] These will be used for developer discussions and user discussions respectively. CVS commit messages will be sent to the httpclient-dev list. * Bugzilla - New product category HttpClient, with appropriate version identifiers as needed. Existing bugs in the HttpClient component under the Commons product category will need to be migrated. (4) INITIAL COMMITTERS The initial committers on the HttpClient component shall be: * Michael Becke * Jeff Dever * dIon Gillard * Ortwin Glück * Oleg Kalnichevski * Adrian Sutton -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][PROPOSAL] Promote HttpClient to Jakarta Level
Hi all, Continuing to push this forward, I propose that we adopt the proposal below as our formal proposal to the Jakarta PMC to promote HttpClient to a Jakarta level project. Please vote as follows: - Vote: Promote HttpClient to Jakarta level [ ] +1 I am in favor of the proposal, and will help support it. [ ] +0 I am in favor of the proposal, but am unable to help support it. [ ] -0 I am not in favor of the proposal. [ ] -1 I am against this proposal (must include a reason). - Regards, Adrian Sutton. (0) RATIONALE HTTP is the main protocol used today on the internet. Although the JDK includes basic support for building HTTP-aware client applications, it doesn't provide the flexibility or ease of use needed for many projects. The current package in Jakarta-Commons is a widely used implementation with a strong community behind it. The size of it's community and it's project has significantly outgrown the commons project and a move to a Jakarta level project would provide better support for that community and for the on going development of HttpClient. (1) SCOPE The project shall create and maintain a Java library implementing the client side of the HTTP 1.0 and 1.1 protocol, as defined in RFC 1945, RFC 2616 and RFC 2617. HttpClient also supports the following RFCs. * RFC 2109 for HTTP state management mechanism (Cookies) - an upgrade to RFC 2965 is planned for a future version of HttpClient * RFC 2396 Uniform Resoruce Identifiers (URI): Generic Syntax * RFC 1867 Form-based File Upload in HTML The package should: * Have an API which should be as simple to use as possible * Be as easy to extend as possible * Provide unconditional support for HTTP/1.1 The package is quite different from the HTTP client provided as part of the JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods being sent (instead of making that transparent to the user), and generally allows more interaction with the lower level connection. The JDK client is also not very intuitive to use. The package is used by a wide range of projects both within the ASF and from third parties. These include: * Jakarta Slide * Jakarta Commons Latka * Nortel Networks * HtmlUnit * Jakarta Cactus * JSR 147 * NOSE Applied Intelligence ag * MindIQ's Design-a-Course * ContactOffice * Newknow * de4d2c * Furies * Term Highlighting for Verity Ultraseek search results * Mule - Universal Message Objects * many more. (1.5) Interaction With Other Packages HttpClient relies on: * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) * Jakarta commons-logging (Version 1.0 or later) * Jakarta commons-codec (Version 1.2 or later) (2) INITIAL SOURCE OF THE PACKAGE The initial codebase exists as a sub-project of Jakarta-Commons, in the httpclient subdirectory of the jakarta-commons cvs tree. The proposed package name for the new sub-project is org.apache.httpclient. (3) REQUIRED JAKARTA RESOURCES * CVS Repository - New module, jakarta-httpclient in the CVS repository. * Initial Committers - The list is provided below. All of the proposed committers are currently jakarta-commons committers. * Mailing List - Two new mailing lists will be required: [EMAIL PROTECTED] and [EMAIL PROTECTED] These will be used for developer discussions and user discussions respectively. CVS commit messages will be sent to the httpclient-dev list. * Bugzilla - New product category HttpClient, with appropriate version identifiers as needed. Existing bugs in the HttpClient component under the Commons product category will need to be migrated. (4) INITIAL COMMITTERS The initial committers on the HttpClient component shall be: * Michael Becke * Jeff Dever * dIon Gillard * Ortwin Glück * Oleg Kalnichevski * Adrian Sutton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][PROPOSAL] Promote HttpClient to Jakarta Level
On 24/3/04 5:24 PM, Adrian Sutton [EMAIL PROTECTED] wrote: Hi all, Continuing to push this forward, I propose that we adopt the proposal below as our formal proposal to the Jakarta PMC to promote HttpClient to a Jakarta level project. Please vote as follows: - Vote: Promote HttpClient to Jakarta level [x] +1 I am in favor of the proposal, and will help support it. [ ] +0 I am in favor of the proposal, but am unable to help support it. [ ] -0 I am not in favor of the proposal. [ ] -1 I am against this proposal (must include a reason). - Here's my +1. Regards, Adrian Sutton. (0) RATIONALE HTTP is the main protocol used today on the internet. Although the JDK includes basic support for building HTTP-aware client applications, it doesn't provide the flexibility or ease of use needed for many projects. The current package in Jakarta-Commons is a widely used implementation with a strong community behind it. The size of it's community and it's project has significantly outgrown the commons project and a move to a Jakarta level project would provide better support for that community and for the on going development of HttpClient. (1) SCOPE The project shall create and maintain a Java library implementing the client side of the HTTP 1.0 and 1.1 protocol, as defined in RFC 1945, RFC 2616 and RFC 2617. HttpClient also supports the following RFCs. * RFC 2109 for HTTP state management mechanism (Cookies) - an upgrade to RFC 2965 is planned for a future version of HttpClient * RFC 2396 Uniform Resoruce Identifiers (URI): Generic Syntax * RFC 1867 Form-based File Upload in HTML The package should: * Have an API which should be as simple to use as possible * Be as easy to extend as possible * Provide unconditional support for HTTP/1.1 The package is quite different from the HTTP client provided as part of the JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods being sent (instead of making that transparent to the user), and generally allows more interaction with the lower level connection. The JDK client is also not very intuitive to use. The package is used by a wide range of projects both within the ASF and from third parties. These include: * Jakarta Slide * Jakarta Commons Latka * Nortel Networks * HtmlUnit * Jakarta Cactus * JSR 147 * NOSE Applied Intelligence ag * MindIQ's Design-a-Course * ContactOffice * Newknow * de4d2c * Furies * Term Highlighting for Verity Ultraseek search results * Mule - Universal Message Objects * many more. (1.5) Interaction With Other Packages HttpClient relies on: * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) * Jakarta commons-logging (Version 1.0 or later) * Jakarta commons-codec (Version 1.2 or later) (2) INITIAL SOURCE OF THE PACKAGE The initial codebase exists as a sub-project of Jakarta-Commons, in the httpclient subdirectory of the jakarta-commons cvs tree. The proposed package name for the new sub-project is org.apache.httpclient. (3) REQUIRED JAKARTA RESOURCES * CVS Repository - New module, jakarta-httpclient in the CVS repository. * Initial Committers - The list is provided below. All of the proposed committers are currently jakarta-commons committers. * Mailing List - Two new mailing lists will be required: [EMAIL PROTECTED] and [EMAIL PROTECTED] These will be used for developer discussions and user discussions respectively. CVS commit messages will be sent to the httpclient-dev list. * Bugzilla - New product category HttpClient, with appropriate version identifiers as needed. Existing bugs in the HttpClient component under the Commons product category will need to be migrated. (4) INITIAL COMMITTERS The initial committers on the HttpClient component shall be: * Michael Becke * Jeff Dever * dIon Gillard * Ortwin Glück * Oleg Kalnichevski * Adrian Sutton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
On 18/3/04 10:24 PM, Roland Weber [EMAIL PROTECTED] wrote: (1.5) Interaction With Other Packages HttpClient relies on: * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) I wonder whether this would be the right time to drop support for JDK 1.2 and require 1.3 ? I generally find the right time is when there's a good reason to. Was there a 1.3 only method we wanted to use? I know 1.4 has some cool stuff but we're not going to be getting to use that for quite some time yet. cheers, Roland Regards, Adrian Sutton. === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
On 18/3/04 12:54 AM, Jeff Dever [EMAIL PROTECTED] wrote: Just the active ones. You must leave off Sun-gu and Sean, since they don't have CLA on file their committer status has been suspended. I agree with Oleg about the handling of the others. Sounds good to me. I'll take care of chasing down the committers that are in the current draft proposal this afternoon. I'll also do up a second draft proposal with the feedback I've received. Thanks for all the feedback. -jsd Regards, Adrian Sutton. === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Hi all, I thought I'd get the ball rolling on creating this proposal - sorry if I've stepped on someone's toes. I had a few unexpected spare cycles. From http://jakarta.apache.org/site/management.html our Proposal needs to have the following things: Scope of the Project Initial source from which the project is to be populated Identify the mailing lists if any to be created Identify the initial set of committers Questions that I can see (all fairly trivial): Should we create a separate dev and user mailing list? If not should we just have a [EMAIL PROTECTED] mailing list or a [EMAIL PROTECTED] mailing list? Should we have a separate list for CVS commit messages? These generally go to the dev list which is good for oversight but it may be a bit much if it's a combined dev/user list. Should all the committers come across or just the currently active ones? I think this should be all of them, in which case - should we attempt to contact them and ask for their preference? I've currently taken the list from project.xml. What's a Jyve FAQ (we requested one in our initial proposal) and are we still using it? Has anyone noticed that our current proposal includes: The initial committers on the Digester component shall be:... (note Digester instead of HttpClient). I guess it's bad form to go back and change that now. Here's what I've come up with basically from just updating the current Proposal to be Jakarta level instead of Commons level. Thoughts, comments, criticisms and generally tearing all this to shreds would be appreciated. Regards, Adrian Sutton. - (0) RATIONALE HTTP is the main protocol used today on the internet. Although the JDK includes basic support for building HTTP-aware client applications, it doesn't provide the flexibility or ease of use needed for many projects. The current package in Jakarta-Commons is a widely used implementation with a strong community behind it. The size of it's community and it's project has significantly outgrown the commons project and a move to a Jakarta level project would provide better support for that community and for the on going development of HttpClient. (1) SCOPE The project shall create and maintain a Java library implementing the client side of the HTTP/1.1 protocol, as defined in RFC 2616 and RFC 2617. The package should: * Have an API which should be as simple to use as possible * Be as easy to extend as possible * Provide unconditional support for HTTP/1.1 The package is quite different from the HTTP client provided as part of the JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods being sent (instead of making that transparent to the user), and generally allows more interaction with the lower level connection. The JDK client is also not very intuitive to use. The package is used by the Slide proejcct to build a WebDAV client library supporting WebDAV level 2. (1.5) Interaction With Other Packages HttpClient relies on: * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) (2) INITIAL SOURCE OF THE PACKAGE The initial codebase exists as a sub-project of Jakarta-Commons, in the httpclient subdirectory of the jakarta-commons cvs tree. The proposed package name for the new sub-project is org.apache.httpclient. (3) REQUIRED JAKARTA RESOURCES * CVS Repository - New module, jakarta-httpclient in the CVS repository. * Initial Committers - The list is provided below. All of the proposed committers are currently jakarta-commons committers. * Mailing List - A new mailing list will be required: [EMAIL PROTECTED] Both user and development discussions will take place on this list. * Bugzilla - New product category HttpClient, with appropriate version identifiers as needed. Existing bugs in the HttpClient component under the Commons product category will need to be migrated. (4) INITIAL COMMITTERS The initial committers on the HttpClient component shall be: * Michael Becke * Jeff Dever * dIon Gillard * Ortwin Glück * Sung-Gu * Oleg Kalnichevski * Sean C. Sullivan * Adrian Sutton * Rodney Waldhoff === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] suspend use of @author tags
On 17/3/04 12:02 PM, Michael Becke [EMAIL PROTECTED] wrote: Given the current ambiguity regarding @author tags I propose that we suspend their use for contributors without a CLA on file. This is meant to be a temporary solution until something official is endorsed by the ASF board. Mike -- Vote: Suspend use of @author tags [X] +1 I am in favor of the proposal [ ] -1 I am against this proposal (must include a reason). +1 === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags
Hi all, I understand that people have a lot to say on this topic, however this is most definitely not the list to say it on. No one on this list has the legal authority to represent or make decisions on behalf of the ASF and this is an ASF decision. The recommendation that author tags not be used came down from the board of the ASF which does have the ability to make such decisions, nothing we say here will change that. I certainly don't intend to tell people not to voice their opinions on this matter, every decision in the ASF can potentially be reversed but such issues need to be taken to the ASF board or at least the PMC (the PMC is apparently already hotly debating this topic). My biggest problem at the moment is thinking of a list that non-committers can subscribe to that would be appropriate for this conversation. license@ is closed, community@ is closed board@ is closed, pmc@ is closed. Where exactly is the best place for these conversations to take place in a manner that is open to contributions from everyone? Regards, Adrian Sutton. === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proxy detection in the Sun plugin
On 12/3/04 7:34 AM, Bruce McHaffie [EMAIL PROTECTED] wrote: Hi Adrian, I hadn't heard about the problem in 1.4.2. Do you have any other information about it? I don't at the moment unfortunately. It may be that I'm the only person seeing it for all I know right now. We haven't received any problem reports come in from any of our customers yet, though there are very few of them who actually use automatic proxy settings anyway. I'm desperate to get this darn product release out today and I may have time to investigate it after that. Generally though if you're not seeing any problems on 1.4.2 it's probably just me. The class is completely missing on my system. Bruce. Regards, Adrian Sutton. === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proxy detection in the Sun plugin
On 10/3/04 2:36 AM, Ortwin Glück [EMAIL PROTECTED] wrote: Bruce McHaffie wrote: It even parses proxy.pac files correctly. I guess the browser parses the proxy.pac, not the Sun classes. AFAIK proxy.pac is written in JavaScript. That's the reason why HttpClient does not try to interprete proxy.pac files. Maybe one can use Rhino at some point to do that No actually Sun's classes parse the pac file. Unfortunately it really doesn't do it very well. Some commonly used functions are effectively no-ops but it seems to manage to work well enough in most cases. There is actually a similar API available in Java 1.3 but it's a different class with a different interface, another change appears to have been made in 1.4.2 which breaks the method Bruce mentioned (at least, it breaks it sometimes but not always). Needless to say, this is a very unsupported feature. Regards, Adrian Sutton === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags
On 10/3/04 5:02 PM, Oleg Kalnichevski [EMAIL PROTECTED] wrote: I personally regret this decision. I feel the author tag may be pretty much the only motivating factor for casual contributions. But I will not object I'm a big fan of author tags (I like to know who to blame mostly :). I won't argue against them going though but I think we need to be quicker to add people to the list of contributors on the website to provide some credit that way. Oleg Regards, Adrian Sutton. === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote HttpClient to Jakarta level
On 10/3/04 1:58 PM, Michael Becke [EMAIL PROTECTED] wrote: This topic has been pretty quiet since I last brought it up, so I guess it's time for a vote. I suggest that we promote HttpClient to a Jakarta level project. Please vote as follows: -- Vote: Promote HttpClient to Jakarta level [ ] +1 I am in favor of the move, and will help support it. [ ] +0 I am in favor of the move, but am unable to help support it. [ ] -0 I am not in favor of the move. [ ] -1 I am against this proposal (must include a reason). -- Mike +1 About time too. :) Adrian. === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 302
On 23/2/04 2:40 PM, Emre Sokullu [EMAIL PROTECTED] wrote: Hi, I think there is a problem with header location : When a URL returns 302 as http status code, the location header of this URL is still a null value. Even if it is a well-known redirected site : Can you inform me about this issue? Am I wrong? I use the code proposed on the official site. Most likely the site is either using JavaScript to redirect or is just completely broken. Can you provide either the URL in question or a HTTP trace log (http://jakarta.apache.org/commons/httpclient/logging.html). Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLM or NTLMv2?
It is possible to set the minimum security that is used for programs that use the NTLM Security Support Provider (SSP) by modifying a registry key. So anybody may set level 5 which does not accept NTLM but NTLMv2 only. Do you refer to that by naming Windows 2003 Server? If so that would mean NTLMv2 is not supported by HttpClient. Correct? Hi Steven, The information you quote is for Windows NT 4.0 and Windows 2000, as far as can be determined, HttpClient is fully compatible with these OS's, the only problem (and it is theoretical as we haven't received any actual reports of it not working) is with Windows 2003 Server in a specific configuration. As I understand it, the configuration isn't so much a new version of NTLM as adding a cryptographic key to the messages such that only Windows can be compatible with it. It is essentially an attempt by Microsoft to break SAMBA (the linux-based project). From what you've sent through I would say that HttpClient does support NTLMv2 however I have to stress that there are no published specs for NTLM (any version) and as such the only real way to know if it works for you is to test it. Stefan Dingfelder Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Release of Commons HttpClient 2.0 Final
On 17/2/04 1:14 PM, Michael Becke [EMAIL PROTECTED] wrote: Hi Vincent, Thanks for adding the jar to ibiblio. I added the jar to '/www/www.apache.org/dist/java-repository/commons-httpclient/' and thought this was supposed to replicate with ibiblio. Perhaps this is not working correctly. There's no real reason it's called 2.0 final I guess. This was just the value I chose. We can certainly rename it to just 2.0. What does everyone think? Mike 2.0 is a lot more predictable so I'd change to that instead. We postfix all our development versions anyway so it's clear that it's the final version by the lack of a postfix. BTW, great work to all involved in the release! It's nice to finally have it out the door. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2.0 final release
+1 On 15/2/04 12:48 AM, Michael Becke [EMAIL PROTECTED] wrote: I propose that we mark the latest code in CVS HTTPCLIENT_2_0_BRANCH as 2.0 final and proceed with a release. Please vote as follows: -- Vote: HttpClient 2.0 final release [ ] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Performance - ConnectionManager vs none?
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,... I've recently been doing some profiling work and was surprised to discover that instantiating HttpClient is actually a reasonably expensive operation. As a result, I'd say you'd probably get just as much of a speed up from not having to instantiate a new HttpClient each time as you would from the connection pooling. I would absolutely recommend making the code changes to use a single HttpClient instance - it's really not that difficult anyway. We actually make ours a static instance that's shared across the JVM as much as possible. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Performance - ConnectionManager vs none?
Adrian Sutton wrote: I've recently been doing some profiling work and was surprised to discover that instantiating HttpClient is actually a reasonably expensive operation. Sounds interesting! Do you know what the reason is? Where is all that time spent? I mean, HttpClient doesn't do that much. I rather ties together some configuration and state. I didn't pay a huge amount of attention to it actually because while it's smack bang on the critical path for our load time it's only there for the first instance of the applet that loads so speeding it up only helps the first load. I believe a large part of it is that the first reference to HttpClient causes a lot of classes to be loaded (I profile using an application version of our product so there's no network overhead for class loading), but I would have to play some more with the profiler to see exactly what it is. I've been wanting to profile HttpClient carefully for quite a while but with 3 products being released in a month of each other I'm a little bit frazzled at the moment. I always appreciate being pestered about these things so if you're interested in me doing up some optimization patches for HttpClient do keep pestering me or I'll just forget. Speaking of things I've been meaning to do for ages, I can confirm that NTLM proxy authentication works correctly in the 2.0 branch - I have a log I could send you but I can't tell you the password because I had to use a real account on our domain. Setting up a dummy password is back on my list of things to do... Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 the MultiThreadedHttpConnectionManager or you'll run into strange problems. If you're using separate HttpClient instances, you may as well stick with the single threaded (default) connection manager. In terms of connections hanging - you probably want to look into the setConnectionTimeout and setTimeout methods of the HttpClient class. These allow you to control how long HttpClient waits when making a connection and how long it waits for data once the connection is established. If you have set either of these to 0 (not sure what the default is, it may be platform specific) the connection will never timeout which sounds a lot like what you're seeing. 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. Srini Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - 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?
On 30/1/04 1:32 AM, Roland Weber [EMAIL PROTECTED] wrote: Hello Oleg, from a technical standpoint, host and port would be sufficient to differentiate between a proxy and HTTP server on the same machine. Actually it's not. It's quite possible to have a proxy and a webserver running on the same port on the same machine (using the same interface with the same IP address for what it's worth). We actually have this setup at work on a Windows 2000 box. I believe it works because the proxy is essentially just a module in IIS so it's really just the one program that behaves differently depending on it's input. I believe the same can be achieved with Apache using the right module. It would be technically possible to require (or for users to desire) the use of different credentials with such a proxy/web server combination. I would definitely concede that it's a very unusual case so I'm certainly not against combining the credentials. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrated Windows authentication
On 2/12/03 6:05 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is the HTTPClient able to work for proxy configured with integrated windows authentication? I read from the Microsoft website (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechno l/windowsserver2003/proddocs/standard/sec_auth_intwinauth.asp) that this authentication is formerly known as NTLM. However, it also says that it does not work over HTTP proxy connection and is suited only for intranet environment. HttpClient does support NTLM authentication and it does work with proxies. There has been a few issues lately so if you're having trouble it would be worth mentioning the specific problems you're having and we should be able to help out. For general info take a look at the authentication guide on the website (http://jakarta.apache.org/commons/httpclient/) I believe the specific page is http://jakarta.apache.org/commons/httpclient/authentication.html Regards, Adrian Sutton -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cactus-13-1.5-rc and commons-httpclient-2.0-rc2.jar works on jdk1.4 and above only?
On 29/10/03 8:12 AM, Michael Becke [EMAIL PROTECTED] wrote: I think I've found the problem. In 1.4, Sun added StringBuffer.append(StringBuffer) to compliment the existing StringBuffer.append(Object). The problem is that STUPID me ran maven for this release with 1.4. The method call was bound to the append(StringBuffer) method, since it is the best option in 1.4. It looks like the build will have to be regenerated with 1.2.2. That's probably the best option for redoing the rc2 release, however we should change the code to be something like: StringBuffer buf1 = new StringBuffer(); ... buf1.append(getOtherStringBuffer().toString()); The .toString() will make sure that we always use the .append(String) method regardless of which JVM the build is compiled on, thus avoiding this problem in the future. Does anyone what JVM is used for nightlies? I would have thought it would be 1.4 so that projects which depend on 1.4 would compile correctly, besides GUMP is all about using the latest of everything. Mike Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLM Question
On 23/10/03 2:29 PM, Thamm, Russell [EMAIL PROTECTED] wrote: Hi, I am interested in using NTLM for authentication on my Apache based webdav server. I am using the Slide client (based on httpclient) I understand that HttpClient supports NTLM but requires me to supply the user credentials. I want to obtain the user's logon credentials from the OS and avoid requiring the user to reenter his userid and password. Any ideas on how I do that under java. You can't. You will have to write native code to do this as it's inherently platform specific. Having said that, Java 1.4.2_02 released recently does include support for NTLM authentication without prompting the user for their password so if you can work out how they did that and find a way to take advantage of it with pure Java it would make a superb addition to the contrib package. Personally, I haven't revisited the problem since 1.4.2 came out so I can't shed too much light on it. thanks Russell Thamm Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Release Prime
On 15/10/2003 11:33 PM, Jandalf [EMAIL PROTECTED] wrote: Hello everyone, I had been acting as the release prime for HttpClient, but unfortunately must resign. My job has changed, and my new life path does not leave me free time for much these days. I would like to stay on as the mailing list moderator (its amazing how much junk mail needs to be filtered from the list!). I'd like to nominate Michael Becke as the new release prime. He has been consistant and insightful in the development of HttpClient. +1 and a big thanks for the time and effort you have put in Jandalf. Jandalf. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Prompting user for authentication?
On 30/09/2003 10:12 PM, Steve Vaughan [EMAIL PROTECTED] wrote:
One of our engineers developed a patch for HttpClient which allows a callback
handler to be registered with an HttpClient instance. A registered handler
could prompt the user for username/password. When a handler isn't
registered, the HttpClient works as it does now.
-Steve
The recommended way (at least as far as I'm concerned) of doing this is to
do it outside of HttpClient since it is in effect outside of what a HTTP
library should handle. The HTTP library handles talking to the server, your
code handles displaying the appropriate GUI and dealing with errors. So
what you do is deal with an unauthorized response like you would other
recoverable errors (excuse the poor code, Entourage keeps capitalising
things):
For (int count = 0; count MAX_ATTEMPTS; count++) {
GetMethod get = new GetMethod(http://auth.com;);
int response = httpclient.execute(get);
if (response = 200 response 300) {
// Yay it worked.
} else if (response == 407) {
// Authorization required (I think 407 is right)
showAuthDialogAndSetCredentials(theRealm, isNTLM,...);
// Lets give them unlimited authorization attempts
count = 0;
} else if (response == 404) {
// Aw shucks, we're out of luck.
} else if (...) {
// redirect ?
// Server too busy, try again later
}
}
That's the basic idea anyway. I thought everyone used that pattern with
HttpClient anyway?
Regards,
Adrian Sutton.
--
Intencha tomorrow's technology today
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is HttpClient with MultiThreadedHttpConnectionManager a connectio n pool?
Hi Christian, I didn't find a user list for HttpClient so I'm posting this to the dev list. This list functions as both the development and user list for HttpClient. Though you could use the commons-user list for user queries as well it's easier to keep everything together here and increases your chances of getting a quick response. We are switching our backend from JDBC to XML via HTTP. At peak hours we need to make up to 20 asynchronous requests per second. We are looking for a HTTP lib that provides some kind of connection pooling so that each request does not result in a new HTTP connection negotiation. The threading section of the HttpClient docs states: In general the connection manager makes an attempt to reuse connections for a particular host while still allowing different connections to be used simultaneously. Connection are reclaimed using a least recently used approach. Does this mean that an instance of HttpClient with MultiThreadedHttpConnectionManager provides the functionality we are looking for? Yes, MultiThreadedHttpConnectionManager will pool connections for reuse. It is important to note that you may need to tweak the way it works to optimise it for your application. By default it limits itself to creating 2 simultaneous connections to any one host and has an upper limit to the total number of connections as well. Both these limits can be configured and depending on your exact use case may need to be increased to avoid threads blocking while waiting for a connection to become available. Kind regards Christian Nedregård Hope that helps, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ConnectionTimeoutException doesn't releaseConnection()
On 12/09/2003 8:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
I have noticed that when a ConnectionTimeoutException is thrown,
HttpConnection
doesn't seem to release the connection. If a lot of timeouts are encountered,
this eventually results in a hang when no more connections are available.
Instead, the connection seems to be correctly released to the
MultiThreadedHttpConnectionManager if a read timeout occurs,ie a
java.net.SocketTimeoutException is thrown.
Hi,
It's generally considered a bad idea to depend on anyone but yourself to
release the connection. Essentially it follows the you took it, you put it
back method. So you should use a pattern like:
Try {
method.execute(...);
method.getResponseBodyAsString();
} catch (Exception e) {
...
} finally {
method.releaseConnection();
}
That will guarantee that the method is always released. A more detailed
example showing the best way to use HttpClient is in the tutorial
http://jakarta.apache.org/commons/httpclient/tutorial.html
Hope that helps,
Adrian Sutton.
--
Intencha tomorrow's technology today
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet to handle fileupload example - missing
On 01/09/2003 4:01 PM, Dan Tran [EMAIL PROTECTED] wrote: Thanks Michael. Was there any reason why HttpClient does not include one? Usually it would be a big help for a newbie not to figure this out first. -D Hi Dan, HttpClient doesn't include one because it focuses on the client side of HTTP transactions and so the server side is out of scope. Additionally if we were to ship FileUpload we'd have to deal with all the problems that go along with it such as support load and synchronizing the release schedule so we ship a stable and up to date FileUpload. We probably should improve our documentation about file uploading though. I've added it to my todo list (that doesn't seem to be getting done lately so feel free to jump in). On a side note, I think I need to move my todo list into bugzilla since it's become pretty big and I'm not keeping up with it. I've added that to my todo list too. :) Does anyone have any objections to using bugzilla in a more informal method like that? Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help -- Proxy continue
Hi Mike, Even though it works now, I still do not know any meanings of domain and host in the NTCredentials's Constructor. The documentation for this has just recently been updated in CVS. Essentially, domain is the NT domain you are authenticating with. If you have your user name in the form DOMAIN\user then DOMAIN is your domain and you should specify the user as just user. The host parameter is the host from which the authentication request is coming from - in other words, the current machine name. If you haven't already, check out the authentication guide at http://jakarta.apache.org/commons/httpclient/authentication.html Hope that helps, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com Thanks again Mike _ Help protect your PC: Get a free online virus scan at McAfee.com. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - 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: newbie questions
On 21/08/2003 9:04 AM, Yue Luo [EMAIL PROTECTED] wrote: Hi, I am new to httpclient. I have a few general questions about the library and wonder if you could help me. I think you've probably already found the stuff on our website, but people who are new to HttpClient should definitely read through the tutorial (http://jakarta.apache.org/commons/httpclient/tutorial.html) before trying to write code that uses HttpClient. 1. HTTP 1.1 standard supports pipelining (RFC2616 section 8.1.2.2). I looked at HttpMethodBase.java. It seems that httpclient does not allow pipelining. Is it true? Is pipelining used in any popular browsers? No, HttpClient does not use pipelining, though it does support connection reuse. There are enough problems with connections being dropped unexpectedly (as allowed by the standard) with persistent connections let alone using pipelining with that. IE does not seem to use pipelining and I think by default mozilla doesn't either though it has recently acquired an option to do so. 2. I did not see httpclient using java.nio package. So I guess that it does not provide asynchronous API either. Is there any plan to take advantage of the nio package and add asynchronous API? HttpClient supports Java 1.2 and above and as such nio is not available. If you need asynchronous downloads you should spawn a separate thread (or utilise a thread pool). 3. The links to mailing lists on the page: http://jakarta.apache.org/commons/httpclient/mail-lists.html does not work. Will anyone put the correct link on the web? The archive links do appear to be broken (though subscribe and unsubscribe seem to be right). I'm not sure what the URL for the official archives are - anyone know? Should we just point to one of the other external archives that are available? Yue Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Grabbing a header from the server's response
On 20/08/2003 9:34 AM, Mark Castillo [EMAIL PROTECTED] wrote: After sending a GET request to a server, how to I pick out the name/value of a specific header from the server's response? Thank you. Take a look at the getResponseHeader and associated methods in the GetMethod object (actually defined by the HttpMethod interface). Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NTLM class
Howdy all, In the docs for the org.apache.commons.httpclient.NTLM class is the note: @deprecated this class will be made package access for 2.0beta2 However the class is still public. At this stage of the release should we just leave the class public for 2.0 and remove it in 2.1 (or 3.0?) or should we make it package access as planned? Also, could someone a little more familiar with JCE and particularly with alternate JCE implementations enlighten me as to whether or not some of the problems people are having with using non-Sun JVMs or non-Sun JCE implementations could be related to the static section in NTLM.java. In particular the lines: String secProviderName = System.getProperty(httpclient.security.provider, com.sun.crypto.provider.SunJCE); java.security.Provider secProvider = (java.security.Provider)Class.forName(secProviderName).newInstance(); Security.addProvider(secProvider); Since I don't think we actually document the property httpclient.security.provider anywhere (yet) I doubt people are setting it, and thus we'd be registering the SunJCE provider if it was anywhere on the class path. I'd imagine that may cause a few problems, but I know practically nothing about JCE so hopefully I'm wrong. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons-user list
Hi all, I'm on holidays this week and next week and while I'll still be receiving email from httpclient-dev and hopefully finally getting some of the things off my HttpClient todo list, I'm not monitoring the commons-user list particularly regularly and so questions about HttpClient can tend to get ignored over there. It would be really great if someone could subscribe to the commons-user list and help people out where they can and redirect any questions you can't answer over to this list where there is a wealth of knowledge. Generally my emails along that vein point out the HttpClient tutorial (http://jakarta.apache.org/commons/httpclient/tutorial.html), the trouble shooting guide (http://jakarta.apache.org/commons/httpclient/troubleshooting.html), the logging guide (http://jakarta.apache.org/commons/httpclient/logging.html) and then direct them to this list if that doesn't help. Thanks in advance, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] BasicAuthenticationExample Cosmetic changes
On Thursday, August 14, 2003, at 06:30 PM, Kalnichevski, Oleg wrote: Also, should the update to the docs be included in the 2-0 branch as well as head? I think so. Done. I also merged the note about JCE which was previously only in HEAD. Oleg Adrian. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] BasicAuthenticationExample Cosmetic changes
On Thursday, August 14, 2003, at 03:31 AM, Rowe, David (CAG-CC MIS) wrote: I know, it was missing an 'i' in Authentication, just for consistency. Also, My credentials were incorrect, talking to the Proxy people here, I was told to use a fully-qualified username, which meant tacking the domain on the front of the username, So essentially, I was sending it Domain\Domain\Username, as opposed to Domain\Username. Many apologies and thanks for your help! Absolutely no need to apologize, this is a failing in the documentation. I have updated the authentication guide to record this. I have made a note that when I get to starting my review of javadocs that this is added to the NTCredentials documentation. Also, should the update to the docs be included in the 2-0 branch as well as head? I notice the note on adding JCE to your class path is not in the 2-0 branch but is in HEAD. Dave Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Challenge Parser Changes
Hi all, Somewhere along the way, probably for a good reason, AuthChallengeParser was changed so that a challenge string like: Basic realm=test, noValue would parse so that in the returned Map, noValue would equate to an empty string instead of null as it previously did. I only notice this because I've got a test sitting around for it here that I haven't checked in yet and it broke. I just wanted to check what the actual behaviour should be. If it were intended as an external API I'd expect the value to be null so there's a distinction between noValue and noValue= but since it's mostly an internal API that's public defaulting to an empty string would be okay (and may be required by the spec?). Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons-user list
Mike, Oleg, et al, I had been monitoring the user list since about the time I appeared on the HttpClient scene and didn't think too many request had slipped by me in that time, though every now and then I do miss some. About every two weeks I'd send through a post for a particular topic which points to this list, so I'm not sure that asking people to send their questions here would be much use since people would likely have either solved the problem, found this list or just given up on HttpClient by now anyway. I don't think it would hurt though. Thanks for subscribing and helping out here, it will be good to have a few more knowledgeable people on the user list. Having said that, I think it works well if I can handle as much of the standard, send-us-your-wire-log type tech support so that you guys can focus on actually getting some work done on HttpClient. On Wednesday, August 13, 2003, at 11:28 PM, Michael Becke wrote: Quite so. I will also subscribe. Do you want to send out a message asking people to resubmit their HttpClient questions if they went unanswered? Mike Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] BasicAuthenticationExample Cosmetic changes
Not at all, I was just starting a full review of the NTLM related javadocs. On Thursday, August 14, 2003, at 07:13 PM, Kalnichevski, Oleg wrote: Adrian, Would it be a big deal for you to update javadoc of the NTCredentials class as well? Oleg -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLM class
I believe these initializations should be removed completely. They can never have been more than a convenience in the first place. You are correct that they were to avoid having to avoid playing with the java.security file. I originally wrote the NTLM support with our applet in mind which absolutely must install without any active effort on the users part so editing the java.security file is right out. On a side note it is nigh on impossible to use JCE from an applet anyway since it closes the jar file which later causes the class loader to crash, so we actually have a modified HttpClient that uses a standalone DES encryption class instead of JCE. My only concern with removing the code now is that we are so close to a release and this is a change that clearly does have some fallout even if we anticipate it to be very small. The only negative impact I can think of is for those that got SSL running without registering the JSSE provider properly. These people would have the choice between adding a line to their java.security file, or putting the three lines of initialization code in their own program. The first choice is better for creating an installation on a particular machine, the second is better for packaging a program with HTTP client and JSSE that has to run on a variety of host JVMs. But those who care about this difference will have done the appropriate thing anyway and won't notice any change at all. We will need to make this *very* clear in the documentation as the error message you get when the JCE provider isn't registered properly is extremely misleading and gives no hint that the java.security file should be edited. regards, Roland If anyone does have any objections or know of likely problems removing this code would cause please do speak up now. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Challenge Parser Changes
On Thursday, August 14, 2003, at 06:28 PM, Kalnichevski, Oleg wrote:
Adrian,
With the present implementation of the authentication challenge parser
Basic realm=realm, test
will produce param name: 'test', param value: null, whereas
Basic realm=realm, test=
will produce param name: 'test', param value: ''
I think such behavior is correct. Do you see it differently?
I have no problem with the behavior at all, just wanted to clarify that
the change was deliberate. In fact, the change was not to do with how
empty parameters at all, but rather that parameters are now stored in
lower case form instead of preserving the original case. I think this
is valid but it happens to break my test case while still passing yours
(I had the same code but used noValue instead of test).
Oleg
The code I'm using (and which passes) is now:
public void testParamsNoParamValue() throws Exception {
Map params = AuthChallengeParser.extractParams(Basic realm=\test\,
noValue);
assertNull(params.get(novalue));
assertTrue(params.containsKey(novalue);
}
Regards,
Adrian Sutton.
--
Intencha tomorrow's technology today
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gentoo Linux has a HttpClient package
Yes, the install (from source no less) works smoothly. Unfortunately it's not a good way to manage java packages since it's just too mixed up with the rest of the system for my liking and it makes it too hard to track what my project is actually using. I do note that the build process is using the ant build file instead of maven though. Regards, Adrian Sutton. On Wednesday, August 6, 2003, at 06:45 PM, Ortwin Glück wrote: They have individual packages of Jakarta subprojects: http://www.gentoo.org/dyn/pkgs/dev-java/commons-httpclient.xml Very nice! Odi -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connection break
My second point is related to retrying you have in your docs (http://jakarta.apache.org/commons/httpclient/tutorial.html - catch block of HttpRecovableException). When I do something like this, I found out that I had to call method.recycle() in the catch block, or the connection was not reinitialized and everything fails. Could you enlighten me on this? Is it a bug in the guide? (I have tried it on 2.0-b1). Yep, it's a bug in the guide. The GetMethod should be created inside the while loop so that a new one is created for each retry. Calling recycle would also work. I've added it to my todo list to fix. I'll leave someone more knowledgeable to answer your other questions as I'm not entirely sure. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fw: unable to find line starting with HTTP error
On Friday, August 1, 2003, at 11:04 PM, [EMAIL PROTECTED] wrote: I tried sending a GET request but I catch always the same error unable to find line starting with HTTP. thanks again.. Hi, The server is not responding with a valid HTTP response as it doesn't include a status line. Even wget can't manage to connect: [EMAIL PROTECTED] perl]$ wget www.computerhistory.org --23:18:41-- http://www.computerhistory.org/ = `index.html' Resolving www.computerhistory.org... done. Connecting to www.computerhistory.org[64.60.242.254]:80... connected. HTTP request sent, awaiting response... 23:18:42 ERROR -1: Malformed status line. It is unreasonable to call this server a Http server let alone expect HttpClient to work with it. You should report the problem to the system administrator of the server. Also, from your latest log it still looks like some method is being executed before the GET method is and the trailing /html is being left behind on the connection - Roland is very much right in pointing out the problems caused by a server returning data for a HEAD request and you may also be running into this problem. Also of interest is: [EMAIL PROTECTED] perl]$ telnet www.computerhistory.org 80 Trying 64.60.242.254... Connected to 64-60-242-254.cust.telepacific.net. Escape character is '^]'. GET /index.html\ Host: www.computerhistory.org !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE404 Not Found/TITLE /HEADBODY H1Not Found/H1 The requested URL /index.html\ was not found on this server.P HR ADDRESSApache/1.3.20 Server at A HREF=mailto:[EMAIL PROTECTED]computerhistory.org/A Port 80/ADDRESS /BODY/HTML Connection closed by foreign host. I wonder how they managed to configure Apache to not return a status line. Anyway, past my bed time. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons-HttpClient conflict with WebDAVClient
On Thursday, July 24, 2003, at 06:02 PM, Daniel Joshua wrote: Yes actually, but it's a bit of a nasty hack that was done before slide was actually updated to HttpClient 2.0 (there were a lot of API changes between 1.0 and 2.0). before slide was actually updated? so now the latest WebDAVClient has which version of HttpClient ? eg. HttpClient 2.0 beta 1 or 2 ? I have no idea, I do know that it was updated in the past few months and they were planning to keep it in sync with HttpClient releases. I'd suggest you download the slide source code, rip out the HttpClient classes then compile your own jar against whatever version you like (beta 2 would be my recommendation). You may need to tweak a few things in Slide, but most likely it will just work. You will have a lot more luck asking these questions on the slide mailing list since they've actually looked at the code in the past year. :) Regards, Daniel Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] HttpClient 2.0 RC1
Absolutely. +1 On Thursday, July 24, 2003, at 10:34 PM, Kalnichevski, Oleg wrote: We have had just one (what I see as a real) bug since 2.0 beta2. I think it is time we moved past 'beta' into 'final release' phase with 2.0 branch Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: Commons-HttpClient conflict with WebDAVClient
On Thursday, July 24, 2003, at 10:47 PM, Michael Becke wrote: On Thursday, July 24, 2003, at 08:33 AM, Adrian Sutton wrote: There are a few options here: a. Check out the slide sources and build against HttpClient beta 2 instead of HEAD (all the compile errors that I can see are due to the changes on the HEAD branch and won't be in the 2.0 release). Yes, the errors are because Slide is using deprecated methods in 2.0 that were removed in 2.1. There's also the int/long change for getResponseContentLength() which causes the compile to break on one or the other. Perhaps we should rethink the decision to just change that return type? b. Update Slide to compile with HttpClient CVS HEAD - Note that slide will then no longer compile with older HttpClient versions. I can do up a patch if the slide developers want to do it this way. It should be possible for things to compile with 2.1 and 2.0. Again it's only because of deprecated method use that things are broken now. Mike Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: Commons-HttpClient conflict with WebDAVClient
There are a few options here: a. Check out the slide sources and build against HttpClient beta 2 instead of HEAD (all the compile errors that I can see are due to the changes on the HEAD branch and won't be in the 2.0 release). b. Update Slide to compile with HttpClient CVS HEAD - Note that slide will then no longer compile with older HttpClient versions. I can do up a patch if the slide developers want to do it this way. c. Release HttpClient 2.0 (planned very soon) and Slide x.x (???) then take option b. d. Something else? I'll open a bug report on this in a moment, Daniel I'd suggest you add yourself to the CC list. Regards, Adrian Sutton. On Thursday, July 24, 2003, at 10:12 PM, Daniel Joshua wrote: Can somebody make a release soon in that case... I really need a WebDAVClient which can be use with either a Commons-HttpClient beta 1 or 2? Regards, Daniel -Original Message- From: Christopher Lenz [mailto:[EMAIL PROTECTED] Sent: Thursday, 24 July, 2003 7:53 PM To: Slide Users Mailing List Subject: Re: FW: Commons-HttpClient conflict with WebDAVClient Martin Holz wrote: Daniel Joshua [EMAIL PROTECTED] writes: We use the latest beta releases of HttpClient with a CVS build of the WebDAV client. Works fine. Fisrt, I have checked http://jakarta.apache.org/site/binindex.cgi and the latest release build for download is Slide 1.0.16. Also, I was looking at the Slide documentation and there is mention of Slide 2.0.0 Where can I download this. Slide 2.0 is not released and there is no such thing as nightly build. You have to build it from CVS. There *are* automated nightly builds: http://cvs.apache.org/builds/jakarta-slide/nightly/ But the builds have been faily for weeks now :-/ http://cvs.apache.org/builds/gump/latest/jakarta-slide.html (Apparently due to an incompatible change in HttpClient) -chris - 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] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: Commons-HttpClient conflict with WebDAVClient
They're two separate projects with little interaction these days. Slide depends on HttpClient and we do try our best not to break their build but I don't think there are any committers on both teams. Regards, Adrian Sutton. On Friday, July 25, 2003, at 02:30 PM, Daniel Joshua wrote: Just curious is there any co-ordination going on between the Commons-HttpClient and the Slide developers? Or are the 2 Jakarta projects developing totally independant of each other? Regards, Daniel -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Thursday, 24 July, 2003 8:33 PM To: Commons HttpClient Project Cc: 'Slide Users Mailing List' Subject: Re: FW: Commons-HttpClient conflict with WebDAVClient There are a few options here: a. Check out the slide sources and build against HttpClient beta 2 instead of HEAD (all the compile errors that I can see are due to the changes on the HEAD branch and won't be in the 2.0 release). b. Update Slide to compile with HttpClient CVS HEAD - Note that slide will then no longer compile with older HttpClient versions. I can do up a patch if the slide developers want to do it this way. c. Release HttpClient 2.0 (planned very soon) and Slide x.x (???) then take option b. d. Something else? I'll open a bug report on this in a moment, Daniel I'd suggest you add yourself to the CC list. Regards, Adrian Sutton. On Thursday, July 24, 2003, at 10:12 PM, Daniel Joshua wrote: Can somebody make a release soon in that case... I really need a WebDAVClient which can be use with either a Commons-HttpClient beta 1 or 2? Regards, Daniel -Original Message- From: Christopher Lenz [mailto:[EMAIL PROTECTED] Sent: Thursday, 24 July, 2003 7:53 PM To: Slide Users Mailing List Subject: Re: FW: Commons-HttpClient conflict with WebDAVClient Martin Holz wrote: Daniel Joshua [EMAIL PROTECTED] writes: We use the latest beta releases of HttpClient with a CVS build of the WebDAV client. Works fine. Fisrt, I have checked http://jakarta.apache.org/site/binindex.cgi and the latest release build for download is Slide 1.0.16. Also, I was looking at the Slide documentation and there is mention of Slide 2.0.0 Where can I download this. Slide 2.0 is not released and there is no such thing as nightly build. You have to build it from CVS. There *are* automated nightly builds: http://cvs.apache.org/builds/jakarta-slide/nightly/ But the builds have been faily for weeks now :-/ http://cvs.apache.org/builds/gump/latest/jakarta-slide.html (Apparently due to an incompatible change in HttpClient) -chris - 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] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.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] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Odd Host Header Problem
Here's an odd heads up for you. I've come across an IIS server which doesn't like: GET /eljconfig.xml HTTP/1.1 User-Agent: test // Note the server interrupts at this point without waiting for the rest of the request Content-HTTP/1.1 500 Server Error Server: Microsoft-IIS/5.0 Date: Tue, 22 Jul 2003 05:50:21 GMT Content-Type: text/html Content-Length: 102 But likes: GET /eljconfig.xml HTTP/1.1 Host: 216.144.36.166 User-Agent: test 200 OK ... It appears that unless the Host header is the first header provided, the server returns a 500 response. No idea why or how they get IIS to do that, but I'll be creating a patch to add the Host header first for our use so if people would like it for HttpClient I can send it through. And in case I haven't mentioned it before - I hate non-compliant servers Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21754] - NullPointerException when releasing connection
and be able to have more control. I would just tend to do this by using the HttpClient class and providing the appropriate interface (eg HttpConnectionManager) for HttpClient to callback to your existing code instead of using it's own. I don't know, maybe even that doesn't suit your purpose at all. From a HttpClient development perspective we will definitely need to stabilize the internals anyway just for maintainability, but we need to get it right first and currently we're scheduling getting it completely right for the 3.0 release so it will take a bit of time to get there. Mike I'd love to be able to work through your use case some more so I can show you exactly how I'd go about it (possibly creating fictional methods to add configurability to HttpClient if required). That way we can both see just how feasible it is to use the HttpClient class in your particular case. Again, thanks for bringing this up. Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: NTLM Error
On Tuesday, July 22, 2003, at 09:28 AM, Andre Augusto de Oliveira Aragao wrote: Adrian, By the way, I couldn´t find about JCE anywhere in the httpclient home page. Analyzing the log I sent before, I found the following: 2003-07-21 18:41:44,472 [main] DEBUG org.apache.commons.httpclient.HttpClient - SunJCE 1.42: SunJCE Provider (implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC-MD5, HMAC-SHA1) Does it means that httpclient detected JCE correctly?? Hmm, it would seem to have detected it correctly. We're really going to need the actual error message that coming out of the NTLM class then and our current exception handling doesn't seem to provide that. I don't currently have time to do up a test build which prints the exception but if you wouldn't mind grabbing the sources from CVS and trying it yourself, I think you should find the details fairly useful. Essentially, look through org.apache.commons.httpclient.NTLM and make sure it prints out the stack trace for every exception it catches. If not, I can take a better look into this tonight when I get home. It is possible that export policies are biting you here, and it may be worth doing up a simple test app that creates the NTLM type 3 message using the NTLM class or better just tries to encrypt something with DES to see if it works. There are test cases in the source code that will try to generate a type 3 message and they may be quite informative as well. I'd actually try running the tests before modifying the HttpClient code as mentioned above. Andre Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: NTLM Error
Odi, We do need to improve tests, mostly in the area of keeping the connection alive correctly, however we actually do have a test for this particular case (and it passes). There's just something screwy going on and we need to get the original exception out so we can try to track it down. Better test cases all round and particularly with better no-host simulated connections is on my list of things to do. Adrian. On Tuesday, July 22, 2003, at 03:47 PM, Ortwin Glück wrote: Adrian Sutton wrote: On Tuesday, July 22, 2003, at 09:28 AM, Andre Augusto de Oliveira Aragao wrote: 2003-07-21 18:41:44,472 [main] DEBUG org.apache.commons.httpclient.HttpClient - SunJCE 1.42: SunJCE Provider (implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC-MD5, HMAC-SHA1) Does it means that httpclient detected JCE correctly?? Hmm, it would seem to have detected it correctly. It seems to me that we need some decent test cases for NTLM, simulating a full authentication handshake with the most important algo's. Unfortunately my NTLM skills are really bad...-- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][RESULT] Add commons-codec as an HttpClient dependency
Mike, Also, since this code is not in a released version yet maven builds will require manually adding a current Codec build. We should request that a Codec snapshot is added to the maven repository if possible. We'll need to check with the Codec team and then log an issue in JIRA for the maven team to actually upload it. I wouldn't anticipate any problems with the process though, and that will allow HttpClient to continue to build out of the box with maven. Regards, Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: InputStream part source
Hi David,
This sounds like normal behaviour though it seems wierd at first.
The reason you need to be able to recreate the input stream is because
HttpClient sometimes needs to recreate and resend the entire request.
The most common cause for this is when the server requires
authentication, but there are a number of reasons.
If you want to avoid creating the input stream twice your only option
is to buffer the content somewhere (memory or disk) and that may or may
not prove to be just as slow.
Regards,
Adrian Sutton.
On Friday, July 18, 2003, at 06:22 AM, David Sean Taylor wrote:
I created a little class called InputStreamPartSource to wrapper an
input stream as a part source.
MultipartPostMethod post = new
MultipartPostMethod(http://192.168.1.4:8080/someServlet;);
InputStreamPartSource source = new InputStreamPartSource(stream,
business.xml);
FilePart part = new FilePart(business.xml, source);
post.addPart(part);
int status = client.executeMethod(post);
It seems that the abstract class Part is calling createInputStream
twice on my source.
Why does it need to create the stream twice?
This causes a bad file descriptor since the stream was already closed
after the first call.
The stream is an expensive resource which comes from a CMS system and
I prefer not to create it twice.
Is this a bug are normal/required behavior?
InputStreamPartSource Class included below
public class InputStreamPartSource implements PartSource
{
InputStream stream = null;
String filename = null;
int length = 0;
public InputStreamPartSource(InputStream stream, String filename, int
length)
{
this.stream = stream;
this.filename = filename;
this.length = length;
}
/* (non-Javadoc)
* @see
org.apache.commons.httpclient.methods.multipart.PartSource#createInputS
tream()
*/
public InputStream createInputStream()
throws IOException
{
return this.stream;
}
/* (non-Javadoc)
* @see
org.apache.commons.httpclient.methods.multipart.PartSource#getFileName(
)
*/
public String getFileName()
{
return this.filename;
}
/* (non-Javadoc)
* @see
org.apache.commons.httpclient.methods.multipart.PartSource#getLength()
*/
public long getLength()
{
return this.length;
}
--
David Sean Taylor
Bluesunrise Software
[EMAIL PROTECTED]
+01 707 773-4646
--
Intencha tomorrow's technology today
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
+1. Also +1 for keeping a specific list of files that's required from codec so that applet developers like me can just pull them out instead of having the whole kit and kaboodle. I volunteer for such a role. Adrian Sutton. On Wednesday, July 16, 2003, at 05:05 PM, Ortwin Glück wrote: +1 Michael Becke wrote: I propose that we start using commons-codec (nightly builds) for our Base64 and URL encoding needs. This change would go into effect for the 2.1 release (HEAD). -- -- -- Vote: commons-codec dependency for 2.1 [ ] +1 I am in favor of this proposal. [ ] -1 I am against this proposal. -- -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
Packages always seem to get bigger - something about people wanting new functionality all the time... :) I'm actually keen to start a policy of very exact (but unofficial) dependency listings for those scungy folks like me. :) For instance if we add lang as a dependency I'd definitely be cutting it down as much as I could. Regards, Adrian Sutton. On Wednesday, July 16, 2003, at 06:45 PM, Ortwin Glück wrote: Adrian Sutton wrote: +1. Also +1 for keeping a specific list of files that's required from codec so that applet developers like me can just pull them out instead of having the whole kit and kaboodle. I volunteer for such a role. Adrian Sutton. Currently Codec consists of 2 (two) classes, Adrian :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
That's not a bad idea, but I would definitely like to avoid having any more than one officially sanctioned jar file. It's quite simple for people to build their own uber-jar if needed. Personally, I don't see any problem with adding a dependency for 2.1. If anyone does have an issue with this, it would be really good to hear from you now. Regards, Adrian Sutton. On Wednesday, July 16, 2003, at 11:32 PM, Eric Johnson wrote: Kalnichevski, Oleg wrote: Right, but the problem is those folks who use CVS snapshots while insisting on complete (maximum) API compatibility with 2.0 branch. They have not been quite receptive to 'but it was part of our plan for 2.1' kind of arguments up to now. Of course, I can put up the same 'Evil Comrade' act as always, but I have a feeling that some of them did not quite appreciate my sarcasm. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] One possible solution would be to build a version of HttpClient that unpacks the commons-codec and combines it with HttpClient. People who need the one jar does it all could use that one. We could even be clever and pull out only those class files we need, thus satisfying Adrian's desire as well. Granted, there would then be two JAR files, but we could clearly indicate that the combination one would go away by 3.0. Just an idea. -Eric. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URI class with userinfo ?
My understanding is that HTTP URLs do not include user info and thus that data should be stripped (or probably an exception should be thrown if we're being strict about it). FTP URLs on the other hand do. Having said that, there's no harm in preserving the user credentials so that they can be returned by the URI class, but it would be messy to try and actually use the credentials from the URL in HttpClient for authentication. From RFC 2616: http_URL = http: // host [ : port ] [ abs_path [ ? query ]] So should we definitely should never use the credentials from the URI but we could add a method that allows you to get them back out if required. Regards, Adrian Sutton. On Friday, July 11, 2003, at 02:58 AM, Oleg Kalnichevski wrote: Why is this the case? I have no idea. Anyone else has some thoughts on this one? Sung-Gu, maybe? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvscommit: jakarta-commons/httpclient/src/test/org/apache/com mons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.java Tes tMethodsExternalHost.javaTestWebappBasicAuth.java
On Monday, July 7, 2003, at 10:46 AM, Ralph Goers wrote: My 2 cents. It is ALWAYS possible to maintain binary compatibility. The downside is that it is ugly and gets unmaintainable over time and it occasionally forces you to create new classes or methods where you would have liked to have reuse the old name. Such is life. An acceptable compromise is to maintain deprecated methods and classes for a release or two and then remove them. Ralph We have spent a fair bit of time looking at ways to fix the problem without breaking API compatibility and I believe at one point someone even created a patch for one of the issues and it was voted down because it introduced far too much instability into HttpClient to make the preservation of the API worthwhile. This isn't a decision that we've taken lightly and if you're using HttpClient as we've always recommended (check the tutorial in particular) then I'd be very surprised if you noticed any change to the API. Really, we've spent a lot of time trying to come up with the best solution to these problems and I believe all the developers who've looked at the problem are in agreement that the only realistic way to fix them is to break API compatibility. If you want to spend the time to come up with a maintainable way to solve the problems and maintain API compatibility then by all means feel free. To summarize the biggest problem with the architecture at the moment: HttpClient (the class) creates a connection to the host and passes just the connection into the method being executed. The method then handles all the retry/authentication/etc logic and has absolutely no way to create a new connection since that's handled in HttpClient. Now, if we move the retry logic, we break API compatibility, if we move the creation of connections we break api compatibility. If we add a new method to HttpMethodBase which accepts a connection manager instead of just a connection and depreciate the old method everyone who would have run into the API change would still have to rewrite their code to use the new method, we still wouldn't have solved all the problems (recreating proxied SSL connections is still not possible), plus the depreciated methods would still have all the bugs that people have been complaining about and the architecture of HttpClient remains unworkable just waiting for the next problem to arise. At some point we need to move the retry logic out of the methods because it simply doesn't belong there, is very difficult to maintain there and has been causing a lot of problems. When we do that, we have two choices - maintain API compatibility but change the way the methods work (really bad since you won't get any warning that things have changed) or break API compatibility so you get a compile time error. We've chosen the latter. Note that through all of this, if you're using HttpClient like you should be (ie: actually going through the HttpClient class instead of calling execute on methods directly) you shouldn't see any change. Hopefully that helps people understand the reasoning behind the proposed changes even if it is a high-level handwaving kind of explanation. Regards, Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] branch 2.0 code and begin 2.1 development
A belated +1. Sorry, been sick this week, I'll probably be fairly quiet for another week or two but will definitely be paying attention. :) Regards, Adrian Sutton. On Saturday, July 5, 2003, at 01:10 AM, Michael Becke wrote: I propose that we create a 2.0 branch from the latest code in CVS HEAD and begin 2.1 development on HEAD. --- --- Vote: branch HttpClient 2.0 code and begin 2.1 development [ ] +1 I am in favor of this proposal. [ ] -1 I am against this proposal (must include a reason). --- --- - 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: GZip capabilities
I assume that the gzip only applies to the body of the response/request and not the headers. If so, this is probably outside of HttpClient's scope (not that I wouldn't encourage such input/output streams from being added to the contrib package). We do support ChunkedEncoding so it might be considered acceptable. The way this functionality would be achieved would be something similar to: GetMethod get = new GetMethod(http://blah.com;); client.execute(get); InputStream in = new GZipInputStream(get.getInputStream()); // do stuff with in. get.releaseConnection(); The input stream retrieved from the method would return the gzip encoded data and the GZipInputStream would read that, decompress it and return the actual data. A similar process would be applied to the output stream. Hope that makes sense Adrian Sutton. On Wednesday, July 2, 2003, at 02:48 AM, Mark R. Diggory wrote: We just started trying to work with gzipped content and HttpClient. Currently this means sending gzip format files using multipart post and ungziping the content coming from GetMethod requests (Since its all often alot of redundant XML this really speeds things up). Are there any thoughts on the idea of providing GZipInputStream/GZipOutputstream capabilities within HttpClient? I wasn't recognizing any capability for this in the codebase, maybe I'm missing something if its there. Cheers, -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - 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: [VOTE] 2.0 beta2 release
+1 On Monday, June 30, 2003, at 08:54 AM, Michael Becke wrote: I propose that we mark the latest code in CVS as beta2 and proceed with a release. Please vote as follows: --- --- Vote: HttpClient 2.0 beta 2 release [] +1 I am in favor of the release, and will help support it. [ ] +0 I am in favor of the release, but am unable to help support it. [ ] -0 I am not in favor of the release. [ ] -1 I am against this proposal (must include a reason). --- --- 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]
[VOTE] Re: 2.0 release
All, Personally, I believe that this issue has gone on far too long and so I would like to propose a vote: I move the motion that the following methods from org.apache.commons.httpclient.util.URIUtil be depreciated for the 2.0 release and removed in a future release: toDocumentCharset(String) toDocumentCharset(String, String) toProtocolCharset(String) toProtocolCharset(String, String) toUsingCharset(String, String, String) Please cast your votes: +1 - The methods should be depreciated 0 - Active Abstain (no response being a passive abstain) -1 - The methods should not be depreciated (veto) Veto's must contain an explanation of why the veto is appropriate. Under Jakarta's voting guidelines (http://jakarta.apache.org/site/decisions.html) product changes (such as this) are subject to lazy consensus, however in this case I would like to achieve consensus on the issue and as such the vote will be considered passed if there are 3 binding +1 votes and no binding vetos or the proposal will be turned down if there are any -1 votes. I would encourage non-committers to submit non-binding votes as well, particularly if you can see a use for the methods in question. Here's my +1. Regards, Adrian Sutton. On Thursday, June 26, 2003, at 06:25 PM, Kalnichevski, Oleg wrote: Odi, Laura eventually conceded that these methods did not seem to make a lot of sense or were too specialized to be of any use for the majority of the HttpClient users. http://marc.theaimsgroup.com/?l=httpclient-commons- devm=104577672115772w=2 I do think that releasing HttpClient with stuff that makes no sense DOES harm. Again, after all, what is the bloody deal with writing a test case? Does it really have to take 5 months if these methods indeed make sense? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP client caching
well, a vacuum cleaner is indeed a bit far off ;-). However, I think that implementing an Http Client (i.e. a browser emulator without rendering engine) should be much closer to HttpClients purpose. I would actually think that a nice generic caching library would be very beneficial, but it should definitely be outside of HttpClient as HttpClient is very regularly used without any desire for caching at all. That said, a caching library could either be provided in HttpClient's contrib directory if it was small and not too actively developed, or if it gets really active or get a lot of use it can be moved over to the commons-sandbox to start life as an independant component. Alternatively, if there is an interest straight away it could start in the commons-sandbox, it does seem to have a wide enough scope to warrant it's own component. We actually need something like this for a future version of our product (1-2 months time maybe) so I'd be interested in helping out and can definitely act as the committer gateway to review submissions and get them into CVS etc. What I find a little disappointing is the fact that I am faced with almost unsurmountable obstacles in doing this (i.e., if I want to avoid hacking the code). Maybe someone with a better understanding of the architecture has a suggestion.. There shouldn't be any obstacles in your way to implement caching. You will have to manually add the headers for last-modified etc, but that's all quite simple with the current HttpClient APIs. If you can give a little more detail about what obstacles you're hitting I can probably point out how to get around them. Regards, Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Poof!
Excellent! Welcome back Jandalf and congrats on the sale and the new job! You must now be Jandalf the White and have some thrilling stories about killing that balrog. :) Regards, Adrian Sutton. On Thursday, June 26, 2003, at 02:39 PM, Jandalf wrote: Hello all! My house has sold, I've moved to Calgary and I have a new job. All is well. I've been monitoring the list and have been taking care of the moderate messages, but I'm back to start participating again. Jandalf. - 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]
Test Coverage
Howdy all, We now have a license for clover to analyze our test cases and am now just starting to work through adding test cases to improve our code coverage. I've very quickly come to the realization that 100% code coverage may actually be a bad thing. I've gotten AuthChallengeParser to 100% coverage now so let me use it as an example: There are four test cases that I consider pedantic and 1 of those that I really don't like. The pedantic ones are: * test that AuthChallengeParser.extractScheme(null) throws an illegal argument exception instead of a null pointer exception. What difference does this really make? The only reason I can think of to keep the test is so that the implied interface for the method is kept the same (it never throws a NPE but throws an illegal argument exception instead). * Test that AuthChallengeParser.extractParams(null) throws an illegal argument exception not a NPE. Same as above really. * testParamsWithNoName(). Check that AuthChallengeParser.extractParams(Basic realm=\test\,=\invalid\); throws a MalformedChallengeException because there is no name part to the name/value pair. This is good if we're in strict mode but if not wouldn't it be better to be lenient and just ignore that param (with a logged warning)? The one I really don't like is: * Test that AuthChallengeParser.extractScheme( Basic realm=\realm\); throws a MalformedChallengeException because there's a leading space. Now in strict mode that's fine and within HttpClient the leading space is stripped before being passed in but it seems overly strict to me. Now, I don't mind what happens with any of these decisions to be honest as none affect the actual behaviour of HttpClient - they are very much edge cases. I would however like to set up a policy on the types of test cases I should create (do we want to avoid testing things like the pedantic things above) as well as the best way to keep track of questionable or overly pedantic test cases. Currently I'm just adding a // pedantic above any test case that seems pedantic and a todo comment over anything that I think may require a change to the code but isn't clearly a bug. I figure from time to time I can provide a list of issues that need to be considered as I work my way through the codebase. Personally, I'm hoping to achieve 100% test coverage firstly because I've discovered how dependent I am on having good test cases while working on HttpClient (most people don't have the detailed level of knowledge that Mike and Oleg do and thus aren't aware that a change will break some other section of code - NTLM is a regular victim of this). Also, aiming for 100% coverage makes a very clear-cut decision on when the job is done which make life easier as well and makes it much more noticeable when new test cases need to be added. Any thoughts? Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Coverage
Again, if the contract of that method says that a leading white space -- or some other irregularity -- causes a specific exception to be thrown, it is good that there are test cases to verify the contract. Maybe it is not the test that you dislike, but rather the behaviour of the method? In that case the contract should be changed to say any leading or trailing white space will be trimmed or something like that. But that has nothing to do with the test being invalid IMHO. Agreed, I don't like the behaviour of the class, but I also don't like adding a test which aims to guarantee that that behavior will not change. The implicit assumptions people make are not part of the contract of the method. The contract of the method is defined in the JavaDocs for the method (hence keeping JavaDocs up to date is so important), and for HttpClient also in the relevant RFCs and standards. It goes without saying that the behavior of HttpClient will change so we need tests that reliably show errors rather than tests which are constantly being changed because they're too strict - that just leads to tests failing tests being ignored. Achieving 100% (or any other hard number) of code coverage is a lot of work, and almost never guarantees that the code is free of errors. Making some percentage of code coverage a hard requirement is usually missing the point. Of course, more coverage is usually good, but there's a point of diminishing return Agreed, we need good test cases not just code coverage. The biggest advantage of having a set percentage coverage is that it (hopefully) sparks a test writing session when things fall below that level. Anyway, while tests like the pedantic ones you outlined are probably not critical, I see no reason to throw them away if they're already present. They serve the very good purpose of testing error conditions and asserting the contract of the class under test. Currently HttpClient has about 47% code coverage and there are almost none of these pedantic tests in our test suite. Much of the new test cases I add to improve code coverage will likely be these pedantic cases since we are generally pretty good at adding tests for major features. The question is then, is it worth adding these tests or is it likely to just cause so too many test failures in the future and diminish the effectiveness of our tests. Just my two cents. Thanks it's appreciated. :) -chris Regards, Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PATCH org.apache.commons.httpclient.methods.multipart.FilePart
Hi Eric, Thanks for your effort, unfortunately attachments don't seem to come through on the list. Could you create a new bug in bugzilla for this and attach the file to that? Thanks, Adrian Sutton On Saturday, June 21, 2003, at 12:57 PM, Eric M Devlin wrote: Hey Mike, Adrian Oleg Got it. Thanks for the kick in the right direction. I wasn't seeing addPart. Please find attached the contrib file. Hope it helps someone else. I tried to make it as apacheish as possible if it needs any changes just let me know. Thanks to everyone working on httpclient. It's been a really nice find. I'm using to at work, but I've gotten more out of it at home. Eric -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 11:01 PM To: Commons HttpClient Project Subject: Re: PATCH org.apache.commons.httpclient.methods.multipart.FilePart Eric, You want to create the FilePart manually and then add it to the MultipartPostMethod. Something like: MultipartPostMethod mpm = new MultipartPostMethod( http://localhost:8080/something; ); FilePart part = new FilePart(name, file, contentType, charset); mpm.addPart(part); Mike On Thursday, June 19, 2003, at 10:23 PM, Eric M Devlin wrote: Hey Adrian, Ok, but what about what something below? MultipartPostMethod mpm = new MultipartPostMethod( http://localhost:8080; + /something ); mpm.addParameter( A,new File( /usr/dev/images/add.gif ) ); How do I set the content type for the file? It seems either the addParameter needs to return FilePart which would have to have setters provided or an overloaded version of addParameter which accepted the content type and charset. //MultipartPostMethod public void addParameter(String parameterName, File parameterFile, String contentType, String charset ) -- or -- //MultipartPostMethod public FilePart addParameter(String parameterName, File parameterFile ) //FilePart public void setContentType( String contentType ) public void setCharset( String charset ) I've got the code pulled into class but without a place to apply it's going to be pretty useless. ;- I think this is why I was putting the contentType determination in the FilePart class it self. Just let me know. Eric -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 11:10 PM To: Commons HttpClient Project Subject: Re: PATCH org.apache.commons.httpclient.methods.multipart.FilePart Hi Eric, This isn't really something that should be included directly into HttpClient as HttpClient isn't intended to care about the actual content it sends and receives but just takes care of the actual HTTP protocol side of things. Adding auto-mime type detection would mean we'd also have to provide a way to configure the default mime-types etc, in other words it opens a whole can of worms. However, this would be an excellent submission to the HttpClient contrib package, particularly if we refactor it so that instead of being a patch it's a complete class that extends FilePart to add the functionality, then it could easily be used without any changes to HttpClient. Would you be happy with that course of action? If so, would you like to adapt the patch into a standalone class yourself or would you like me to take a crack at it? I don't mind either way. Thanks a lot for the contribution, it will definitely be useful to a number of people. Regards, Adrian Sutton. On Thursday, June 19, 2003, at 12:46 PM, Eric M Devlin wrote: Hey, This is a patch which will determine the content type if null based on file extension. I used the file extension mapping from $TOMCAT_HOME/conf/web.xml. As a side note, I'm having trouble sending gif files. Any thoughts or a kick in the right direction would be helpful. Thanks and Hope It Helps Eric contentTypeByExtension.txt- - - -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deadlock problem with MultiThreadedHttpConnectionManager
Odi, HttpClient doesn't depend on the GC, it depends on the user telling us when the connection is no longer in use (which Eric discovered he hadn't done). There is however a fallback whereby when a HttpConnection is garbage collected (ie: when we discover that it is no longer in use), it tells the connection manager that it is no longer in use. You are right that this behavior should not be depended upon, but it is a nice fallback. Also, connections release themselves when there is no more data to be read from the stream. The solution in this case is to always call releaseConnection() when you're finished with the connection (as is mentioned lots and lots through our docs :) and I really can't see any better way to deal with it. If someone else comes up with a way to detect that a connection (which has an unknown amount of data) is no longer in use, it would definitely be good to implement it, but I'd be surprised if there was a good way. Regards, Adrian Sutton. On Thursday, June 19, 2003, at 05:35 PM, Ortwin Glück wrote: Eric Johnson wrote: Ortwin, It is an odd problem. Not quite a dead-lock in the traditional sense. One thread is waiting on the other, and the other is waiting for the garbage collector. It just so happens that the garbage collector will never kick in, because the first thread happens to be the AWT Event thread, so the user cannot interact with the application any further, thus no objects get allocated, and there is no reason to garbage collect. To oversimplify, Thread A depends on Thread B depends on Thread C depends (indirectly) on Thread A. Okay, I understand now. Ugly, ugly and a hard nut to crack, really. The problem seems to be that we rely on the GC. I think this is extremely bad. Nobody should ever rely on the GC, because it can litteraly take ages until it runs, when you have huge amounts of memory. So our queue could get *really* large and filled with stale objects. It would be nicer if we could ask the objects in the queue directly if they are still 'usable' or if they are 'done with' and should be removed (maybe that is impossible though). I mean this weak reference stuff looks nice and elegant but it's unfortunately not very good for the cruel real world... Any chance that we can remove this dependancy on the GC? Odi - 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: Deadlock problem with MultiThreadedHttpConnectionManager
Also, connections release themselves when there is no more data to be read from the stream. The solution in this case is to always call releaseConnection() when you're finished with the connection (as is mentioned lots and lots through our docs :) and I really can't see any better way to deal with it. This is definitely the right use of the API (the one who acquires a resource is the one to release it; not taking disasters like sudden death into account here). Forgetting releaseConnection is misuse and therefore I don't care if a deadlock occurs in that situation. Are we 100% sure that a deadlock can not occur when releaseConnection is used correctly? In proper use, we are as certain as is possible that HttpClient won't deadlock. There are of course a number of places where HttpClient can be configured to wait indefinitely such as if the server doesn't respond etc but all of that is configurable. Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient Testimonials
Thanks a lot for that Eric. I've got it in a virtual sticky for the moment and hopefully will do up a proper page for the site over the weekend. Rest assured though that it hasn't been ignored (those damn virtual stickys just never seem to go away...). Regards, Adrian Sutton. On Tuesday, June 17, 2003, at 11:18 PM, Eric Johnson wrote: OK, I'll bite. My temptation was to provide a bullet point list, but since you requested _paragraphs_, that means I have to have fully formed thoughts! We've used HttpClient in a variety of projects throughout my company. Someone I work with had an interest in the project, so we tried it out as a way to work around a specific bug in the Sun 1.3 JRE. Once we started using it, though, other features started to prove their worth, including the automatic support for cookies, the support for authentication mechanisms, and support for multipart/form-data posts. We also like the fact that HttpClient happens to be open source for all the usual reasons, including the many capable eyes that have been looking at and tinkering with the project to improve it, the explicit code-review of changes that keeps the quality high, and testing in a variety of environments that we simply cannot match, especially since this technology is not central to what my company does. Many kudos from me to all those who have put in the work to turn HttpClient into such a reliable solution, for keeping the project on the straight-and-narrow, and accepting and managing feedback and patches well. Of course, many thanks as well to Apache for hosting the project. -Eric. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SocketException with invalid server
Howdy all,
I'm having some trouble pinpointing the exact cause of an exception I'm
getting from HttpClient, it seems to be related to connection
management with MultiThreadedConnectionManager so I thought I'd draw on
the expertise here. :)
Essentially, we have an invalid HTTP server (Stellent CMS actually and
we will file a bug with them), which is returning headers like:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic Secure Realm
Connection: keep-alive
Which is clearly missing the Content-Length header. Now, previously
HttpClient handled this perfectly by reading until the end of the
connection (ie: treating it like it was a Connection: close), however
for some reason a socket exception is being thrown and the invalid
connection is added back into the connection pool and then every
connection to the server after that thows an exception.
I haven't been able to work out a good way to create a test case for
this yet, but I can provide a simple set of steps to reproduce:
1. Get something like netcat which will let you pretend to be a HTTP
server (ie: it will listen on a port and send back whatever you type)
2. Start it listening on port 8080 (for netcat use: nc -l -p 8080)
3. Compile the program below and run it.
4. Enter the following into you netcat window (followed by a blank line
to indicate the end of the headers):
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm
Connection: keep-alive
You'll see HttpClient throws an exception (listed below the code).
Note that netcat did not close the connection, HttpClient did. Also,
note that it doesn't make any difference if you set netcat up to
immediately start listening for another connection after the connection
is closed (ie: netcat -l -p 8080 netcat -l -p 8080).
It looks like HttpClient is closing the connection but not telling
itself that the connection is closed so it then tries to reuse the
connection and fails. The same thing happens if you perform two GET
requests and the server returns 200 OK with connection: keep-alive but
no content length to the first request.
Any help tracking down this would be greatly appreciated, even if it's
just a hint as to where to start making changes. :)
CODE: -
import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.*;
import org.apache.commons.httpclient.contrib.ssl.*;
import org.apache.commons.httpclient.protocol.*;
public class Test {
public static void main(String[] args) throws Exception {
//String url =
https://basil/stellent/groups/secure/documents/adsales/testimage.jpg;;
String url = http://localhost:8080/test.gif;;
HttpClient client = new HttpClient(new
MultiThreadedHttpConnectionManager());
client.getState().setCredentials(null, null, new
UsernamePasswordCredentials(sysadmin, idc));
GetMethod get = new GetMethod(url);
int result = client.executeMethod(get);
System.err.println(Result: + result);
System.err.println(get.getResponseBody());
}
}
--
Resulting exception:
Exception in thread main java.net.SocketException: Socket closed
at
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
at
java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at
org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(H
ttpConnection.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(Ht
tpConnection.java:782)
at
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpCon
nectionAdapter.flushRequestOutputStream(MultiThreadedHttpConnectionManag
er.java:1046)
at
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase
.java:2174)
at
org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBa
se.java:2529)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java
:1066)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6
38)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5
00)
at Test.main(Test.java:15)
The wire trace is:
[DEBUG] HttpClient - -Java version: 1.4.1_01
[DEBUG] HttpClient - -Java vendor: Apple Computer, Inc.
[DEBUG] HttpClient - -Java class path:
commons-httpclient-2.0-beta1.jar:commons-logging-1.0.2.jar:.
[DEBUG] HttpClient - -Operating system name: Mac OS X
[DEBUG] HttpClient - -Operating system architecture: ppc
[DEBUG] HttpClient - -Operating system version: 10.2.6
[DEBUG] HttpClient - -SUN 1.2: SUN (DSA key/parameter generation; DSA
signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS
keystore; PKIX
Re: NTLM Documentation
Eric, Thanks for pointing this out. I will add a link to it to the HttpClient NTLM authentication for those who are curious about the more technical details. Regards, Adrian Sutton. On Friday, June 20, 2003, at 11:12 AM, Eric wrote: Hello, I have been putting together a (relatively) comprehensive documentation of NTLM and its use in various protocols; this is now up and available at: http://davenport.sourceforge.net/ntlm.html I figured there might be interest on this list; it only touches briefly on NTLM HTTP authentication in particular, but is very detailed on the underlying NTLM messages. Thanks! Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SocketException with invalid server
On Friday, June 20, 2003, at 11:41 AM, Michael Becke wrote: Adrian, I'm looking into to this and I agree it is quite strange. The part I don't understand is why the second attempt to write to the socket fails. The socket is not being closed on the HttpClient side until after the failure occurs. Any thoughts on how the connection is being closed? Well I'm not really sure. It appears that the HttpConnection class thinks that it's still open but the underlying stream is actually closed. I'm just writing some tests to check this at the moment, but I believe it has to be the case because in HttpMethodBase.writeRequest at line 2179 we call conn.flushRequestStream which is what's causing the exception. However, immediately before that call if you add a debug statement to check if the connection is open, conn.isOpen() returns true. Have you been able to independently reproduce this problem? I can reproduce it on 1.4.1 on OS X and Windows 2000 but it's possible I'm still screwing something up. Mike Adrian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SocketException with invalid server
Yup, I'm trying it on OS X and linux. I think the problem is in
HttpMethodBase.execute() in particular the following line:
if (responseStream != null) {
responseStream.close();
}
Since there is no content length or chunking the response stream is
not being wrapped and is therefore actually closed by the above code.
Take a look at AutoCloseInputStream.close(). I vaguely remember
talking about this case when we added the connection release/reuse
code. I may be wrong but I think that the connection should be
getting closed in this case as there is no safe way to consume the
response.
Mike,
You are right it is definitely those three lines, though it took me a
while to find where the extra wrapped stream got added.
Now, when the input stream is closed
HttpMethodBase.responseBodyConsumed() is called, it checks
shouldCloseConnection() which erroneously returns false and so the
HttpConnection is never marked as closed, despite the underlying socket
having been closed.
So we need to make shouldCloseConnection more intelligent so that if we
have a Connection: keep-alive but not Content-Length it returns true,
which is insanely easy to add.
We do however have a test that depends on this bug.
TestResponseHeaders.testDuplicateConnection sends two Connection:
keep-alive headers, but no Content-Length header and then expects the
connection to remain open. I'm certain this test case should be
changed to send a Content-Length as well (largely because I'm going to
add a test case with a Connection: keep-alive and no Content-Length and
check that the connection was closed).
The other problem tests that I'm not so sure about are the proxy tests.
TestResponseHeaders.testDuplicateProxyConnection sends two
proxy-connection: keep-alive headers but no Content-Length. I believe
in this case we should also close the connection since we have the same
problem of not knowing where the last response ended as when there's no
proxy. Does this evaluation seem correct to others? If so, all that
needs to be done is to add Content-Length: 0 to the test and it passes
again.
I have another problem with proxies in that even if
shouldCloseConnection() returns true, the connection to the proxy isn't
actually closed and I'm not sure why. Any hints about where proxy
connections are closed?
Mike
Anyway, here is the patch so far, I've modified the two tests that
previously failed and added two new tests to ensure that the connection
is closed if there is no Content-Length - the proxy version of these
tests is currently failing and I'm not sure why.
Index: src/java/org/apache/commons/httpclient/HttpMethodBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/
httpclient/HttpMethodBase.java,v
retrieving revision 1.152
diff -u -r1.152 HttpMethodBase.java
--- src/java/org/apache/commons/httpclient/HttpMethodBase.java 13 Jun
2003 21:32:17 - 1.152
+++ src/java/org/apache/commons/httpclient/HttpMethodBase.java 20 Jun
2003 05:07:17 -
@@ -900,6 +900,10 @@
}
return true;
} else if
(connectionHeader.getValue().equalsIgnoreCase(keep-alive)) {
+if (getResponseContentLength() 0) {
+LOG.debug(Should close connection as
content-length is missing.);
+return true;
+}
if (LOG.isDebugEnabled()) {
LOG.debug(Should NOT close connection in response
to
+ connectionHeader.toExternalForm());
Index: src/test/org/apache/commons/httpclient/TestResponseHeaders.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/
httpclient/TestResponseHeaders.java,v
retrieving revision 1.7
diff -u -r1.7 TestResponseHeaders.java
--- src/test/org/apache/commons/httpclient/TestResponseHeaders.java
10 Jun 2003 22:42:52 - 1.7
+++ src/test/org/apache/commons/httpclient/TestResponseHeaders.java
20 Jun 2003 05:07:19 -
@@ -153,6 +153,7 @@
HTTP/1.1 200 OK\r\n
+ proxy-connection: close\r\n
+ proxy-connection: close\r\n
++ Content-Length: 0\r\n
+ \r\n;
conn.addResponse(headers, );
@@ -169,6 +170,7 @@
HTTP/1.0 200 OK\r\n
+ proxy-connection: keep-alive\r\n
+ proxy-connection: keep-alive\r\n
++ Content-Length: 0\r\n
+ \r\n;
conn.addResponse(headers, );
@@ -202,6 +204,7 @@
HTTP/1.0 200 OK\r\n
+Connection: keep-alive\r\n
+Connection: keep-alive\r\n
++Content-Length: 0\r\n
+\r\n;
conn.addResponse(headers, );
@@ -210,6 +213,38 @@
method.getResponseBodyAsString();
Re: SocketException with invalid server
I have another problem with proxies in that even if shouldCloseConnection() returns true, the connection to the proxy isn't actually closed and I'm not sure why. Any hints about where proxy connections are closed? Ah, ignore this bit. I'd screwed up the test case so it added a proxy-connection header but didn't set a proxy on the connection so HttpMethodBase never looked for the header, I'd further screwed up the positioning of my debug statements so I was looking at the output of the wrong test case making life rather difficult. :) I'll create a new bug with the final patch so it doesn't get lost. Adrian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: unable to find line starting with HTTP error
Hi Michael, Well I'll be darned. I'd actually half written an email telling you to try the latest HttpClient because the problem was fixed when I actually tried the latest HttpClient and watched it barf. So yeah, that one's a bug that will need to be fixed, the headers looked pretty standard when I connected via telnet. I'll look into it now but filing a bug would definitely be a good idea as I have a very short attention span. :) Regards, Adrian Sutton. On Thursday, June 12, 2003, at 06:21 PM, Michael Mattox wrote: I keep getting this error 'unable to find line starting with HTTP' when I try to get the following URL: http://www.msnbc.com/news/ default.asp?newguid=2594c0a6623f464fb0ff25446bfa6c f3 It doesn't happen every time, about 1 in 5 really. Here is the stack trace followed by the log. I tried to configure the wire log per the instructions on the website (setting the system properties) but I don't see any logging on my System.err. I'm using Eclipse and I have it set show System.err. I set up a log4j appender and the debug output from that is below: snip Is it something I'm doing? Let me know if it's worth setting up a bug report. Michael - 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: HttpState not serializable
Oleg et al, My take on this is that we should leave the choice of persistence up to the end user. The HttpState is not a JavaBean or adhere to any of the other bean contracts so I don't see any need to make it serializable. I think it would be great to see a class that extends HttpState to make it serializable, particularly if it did so in a way that it encrypted the passwords etc, however I believe that should wind up in the contrib directory. Serialization is way outside of HttpClient's usual use cases so if there are concerns about how it should be done, it should be left to the user, it's a fairly trivial change for users to make. The other problem is that if we mark HttpState as serializable we have to start worrying about making it backwards compatible and not breaking the ability to serialize, I'm not sure that's something we want to take on. The idea is nice on the surface though - shame about the detail. :) Adrian Sutton. On Thursday, June 12, 2003, at 09:34 PM, Kalnichevski, Oleg wrote: Ralph and the HttpClient folks out there Initially I thought that HttpState class should have been made serializeable per default. Later I realized that there was a catch, however. The HttpState class besides cookies also contains credentials for target servers and proxy servers. From the security standpoint, it would not be desirable to store such sensitive information in clear text or to give the user a wrong impression that the security aspects of password persistence have been taken care of. So, we basically end up with two options: 1) making HttpState serializeable but marking credentials sets as transient 2) leave the choice of the persistence mechanism up to the user (as it is today) If we reach a consensus that the first option makes more sense, I will file a bug report and target it for 2.1 release Cheers Oleg -Original Message- From: Ralph Goers [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 01:01 To: [EMAIL PROTECTED] Subject: HttpState not serializable I am trying to save the HttpState object in the session and am getting a message from Weblogic Server saying the attribute is not serializable and will be lost upon redeployment. How can I address this? Ralph - 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]
Adrian as Committer
How is your committer agreement shaping up? I would really LOVE to see that damn SSL guide massaged a bit and finally deployed on our web site. Well, two days ago I had approval from the chairman of the board and was waiting for the documentation to come through. Now I'm waiting on an evaluation from our US legal firm so I don't really know what's going on or how long it's going to take. I do apologize for the trouble involved, hopefully our legal firm will be in touch with software development practices and put an end to this farce. As for the SSL guide, I'd just commit it as is and deploy it. It's good enough that it will be useful to people and I can do the cleanup work on it when this all gets sorted out to make it a little easier to read and make it fit in with the same style as the rest of our documentation. Somewhere there's a chorus of angels singing the hallelujah chorus because I've got final approval and have faxed in my contributor agreement. I'll convert my copy of the HttpClient source to use the SSH committer login and update the project.xml tonight. Then it's on to the polishing of the ssl guide. :) That sure takes a load off my mind! Regards, Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLM
Your username, password and/or domain are incorrect. The wire log shows everything technically going smoothly but the server still rejects the credentials. If you are absolutely certain that your credentials are correct, please send through the exact details of the webserver your using along with every last little bit of it's configuration information so that I can try to reproduce the problem. If there's a problem with the implementation of the protocol it will be exceptionally hard to track down so I need as much info as possible. Regards, Adrian Sutton. On Wednesday, June 11, 2003, at 02:28 AM, Zulfi Umrani wrote: Tried to Authenticate using NTLM. Attached is JCTest.java sample code and debug trace in debug.txt. It comes back finally as Access Denied. Does anyone has a clue? Thanks. debug.txt - 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]
