Re: RFC: Fileupload 1.3 or 2.0?
On Wed, 2007-07-04 at 07:42 +0200, Jochen Wiedmann wrote: On 7/4/07, Martin Cooper [EMAIL PROTECTED] wrote: * We were already starting to clone classes from what was originally HttpClient and is now HttpComponents. One example is the ParameterParser class. When I saw HttpComponents being born, saw a lot of other stuff in there that FileUpload was doing, it looked like it would make a lot of sense to build FileUpload on top of HttpComponents, thus dramatically cutting down the amount of code necessary to build a FileUpload package. I agree with you on that it might make sense to reuse components from outside, if possible. Unfortunately HttpComponents (in the person of Oleg Kalnichevski) has repeatedly declared that he has no interest in adding a multipart parser to httpcomponents, which would be (IMO) the most important part. Instead he suggested to add such a parser to Commons Codec. I personally believe, that this extends the scope of Commons Codec. But yes, if possible, I'd still be interested to reuse another multipart parser. Do you know of any ASL licensed? Jochen You may want to take a look at Apache JAMES Mime4j [1] As to why we currently have no plans to provide support MIME coding in HttpComponents, there is more to it then just my trying to be difficult. We are simply precluded from developing content codecs by the project charter. It is one of several restrictions that were imposed on the project in order to secure an approval of the Jakarta PMC. However, given the fact that HttpComponents will most definitely have to leave Jakarta for another TLP or form a TLP of its own, the project charter may be revisited and revised. Having said that, I am still convinced HttpComponents ought not expand its scope beyond low level HTTP transport aspects and would prefer to work with other projects such as JAMES or Commons toward development of a set of transport independent content codecs. Oleg [1] http://james.apache.org/mime4j/index.html [2] http://svn.apache.org/repos/asf/jakarta/httpcomponents/project/project-charter.txt Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [http-client] Does HttpClient support the HttpOnly cookie attribute?
On Sun, 2007-04-15 at 09:48 -0400, Tom Muldoon wrote: It appears that the HttpOnly cookie attribute is not recognized by the CookieSpec class (in both HttpClient 3.0 and 3.1rc). i.e. the following message is logged ... CookieSpec - Unrecognized cookie attribute: name=HttpOnly, value=null This appears to be a bit of a show stopper, as the server redirects the subsequent request back to the Login page after a seemingly successful login. In looking at the cookie that is included in the subsequent request, the HttpOnly attribute is missing altogether. So, does HttpClient support HttpOnly cookie attribute??? Tom, I am not aware of HttpOnly attribute mentioned anywhere in RFC2109 or RFC2965. HttpClient does not support cookie attributes that are not defined in the HTTP state management specification. Hope this helps Oleg Thanks in advance, Tom PS. Pardon me if this is a double-posting. I did post this a few days ago on the commons-user list but later realized that it was probably something that should have been posted to commons-dev. Is commons-user a subset of commons-dev? - 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: [logging] JCL in SLF4J flavour - a demo for discussion
On Tue, 2007-04-03 at 22:51 +1200, Simon Kitching wrote: On Mon, 2007-03-26 at 15:51 +0200, Oleg Kalnichevski wrote: On Fri, 2007-03-23 at 19:56 +0100, Boris Unckel wrote: Hello, I have seen the recent discussions on JCL 2.0.0 and a version without autodiscovery. Someone stated to stop any further development (with good reasons behind) but I am thinking different. Please have a look at the (working) code: https://issues.apache.org/jira/browse/LOGGING-112 It has a static binding, some improvements in the logfactories (recognizes native implementations). API and implementations are cleanly separated, the 1.1.x diagnostic function is still used. What are your thoughts? Is this a possible direction? Hi Boris, I think this patch represents the way I personally would like to see JCL evolve in the future. If JCL 2.0 were being developed along these lines, I (personally) would be very inclined to continue using JCL for the next major version of HttpClient. Would you both mind explaining what benefits you see in a new JCL implementation that cannot be obtained via java.util.logging? I'm no fan of the j.u.l design, but it seems to me less effort to use it than to fight it. What have I not understood? And what would a new JCL do for anyone that they could not do by just using SLF4J via its JCL API? The SLF4J team have already done a lot of hard work; what benefit would there be to duplicating that? Regards, Simon Let me take my best shot at trying to explain it. (1) HttpClient is meant to be a low level transport library and as such it is supposed to be as non-intrusive toward its upstream dependencies as possible. To me _personally_ this also means not imposing a particular choice of a logging toolkit. The reliance on JUL for logging in HttpClient 4.0 would seem to prevent the use of some popular toolkits. I am _personally_ not aware of a good JUL to Log4J adapter (2) I _personally_ am fine with just dumping JCL in favor or SLF4J, but other HttpComponents committers are currently not. (3) The only serious gripe about JCL I am aware of is its auto-discovery mechanism. There _appears_ to be a consensus, please correct me if I am wrong, that auto-discovery was indeed a mistake. (4) I _personally_ still have a rather naive belief that Jakarta stands for something and we should eat our own dog food whenever possible. If JCL 2.0 were to address the auto-discovery issue, that would remove my only reservation about using JCL in HttpClient 4.0. That's just my take on the issue for what it is worth. 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]
[jira] Commented: (FILEUPLOAD-131) MultipartStream always assumes transfer encoding to be BINARY
[ https://issues.apache.org/jira/browse/FILEUPLOAD-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485970 ] Oleg Kalnichevski commented on FILEUPLOAD-131: -- Folks, I doubt HttpCore would be of any use here, as it does not (and is not supposed to) provide any content codecs. You probably may want to take a closer look at Commons Codec, which provides two content transfer codecs mentioned in RFC1521: quoted-printable and base64. Some efforts will have to spent on getting those codecs to work with I/O streams, though. Oleg MultipartStream always assumes transfer encoding to be BINARY - Key: FILEUPLOAD-131 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-131 Project: Commons FileUpload Issue Type: Bug Environment: N/A Reporter: Walco van Loon MultipartStream always assumes transfer encoding to be BINARY and does not handle 'Content-Transfer-Encoding' header at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] JCL in SLF4J flavour - a demo for discussion
On Fri, 2007-03-23 at 19:56 +0100, Boris Unckel wrote: Hello, I have seen the recent discussions on JCL 2.0.0 and a version without autodiscovery. Someone stated to stop any further development (with good reasons behind) but I am thinking different. Please have a look at the (working) code: https://issues.apache.org/jira/browse/LOGGING-112 It has a static binding, some improvements in the logfactories (recognizes native implementations). API and implementations are cleanly separated, the 1.1.x diagnostic function is still used. What are your thoughts? Is this a possible direction? Hi Boris, I think this patch represents the way I personally would like to see JCL evolve in the future. If JCL 2.0 were being developed along these lines, I (personally) would be very inclined to continue using JCL for the next major version of HttpClient. Is it worth to put more time and energy into this? I think it is. Cheers, Oleg Regards Boris - 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]
[logging] JCL sans auto-discovery?
Folks, Please correct me if I am wrong, but the auto-discovery mechanism in Commons Logging is believed to be the only major gripe about JCL. What happened to the idea of releasing a version of JCL that retains the full API compatibility with JCL 1.0.x and 1.1.x but with the auto-discovery mechanism removed / disabled per default? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Commons HttpClient 3.1 RC1
On Thu, 2007-03-15 at 20:37 -0400, Gary Gregory wrote: Hi All: Any guesses on the release schedule? Thank you. I'll tag the release in SVN tonight and tomorrow is going to be the official release date. Oleg Gary Gregory Senior Software Engineer Seagull Software [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] www.seagullsoftware.comhttp://www.seagullsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons Logging deprecated? was Re: [logging] 1.1.1 release?
On Sat, 2007-03-10 at 16:05 +1300, Simon Kitching wrote: On Sat, 2007-03-10 at 03:38 +0100, Torsten Curdt wrote: Definitely happy to give M2 a try; but I'd rather not change the groupId on a bugfix release. We already have an M2 release in FileUpload that didn't change the groupid so that's not a worry. Plus I want to get it done quickly :) Ah ...my +1 for changing the groupId was not meant for this bugfix release. It would be good to change it for new major releases though. I expect that this will be the last ever release of commons-logging. There are no features missing, no known bugs, and as support for java 1.4 is now generally universal there is no reason for applications not to use the java.util.logging API directly. Hi Simon, This is a little bit of a shocker to me. Does your opinion represent the collective opinion of the JCL developers? Do I interpret your message correctly that JCL has been effectively deprecated, there will be no work done toward JCL 2.0 and the upstream projects that currently depend on JCL are advised to migrate to JUL? Cheers, Oleg Note that java.util.logging is an *API*, and the implementation bundled in Sun's jdk is not the only choice (see JULI for example). Changing the group-id is something that can only be done on a release, so it seems sensible to do it for 1.1.1 even if this is just a bugfix release. Cheers, Simon - 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: svn commit: r505890 - in /jakarta/commons/proper/httpclient/trunk: release_notes.txt src/java/org/apache/commons/httpclient/AutoCloseInputStream.java src/test/org/apache/commons/httpclient/TestStr
On Wed, 2007-02-14 at 16:47 +1300, [EMAIL PROTECTED] wrote: Perhaps this should have an @since tag added, as it's a new method? Hi Simon, This change does not actually affect the public API. AutoCloseInputStream is a package private class and is not meant to be imported by the end users. Can we live without an @since for this method? Oleg [EMAIL PROTECTED] wrote: Modified: jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/AutoCloseInputStream.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/AutoCloseInputStream.java?view=diffrev=505890r1=505889r2=505890 == --- jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/AutoCloseInputStream.java (original) +++ jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/AutoCloseInputStream.java Sun Feb 11 03:25:25 2007 @@ -131,6 +131,23 @@ } /** + * Obtains the number of bytes that can be read without blocking. + * + * @return the number of bytes available without blocking + * @throws IOException in case of a problem + */ +public int available() throws IOException { +int a = 0; // not -1 + +if (isReadAllowed()) { +a = super.available(); +// no checkClose() here, available() can't trigger EOF +} + +return a; +} + - 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] Promote commons-site to proper and release it
+1 to both Oleg On Sat, 2007-01-13 at 02:16 +0100, Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [x] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [x] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: Is HttpClient-dev mailing list active?
On Mon, 2006-12-25 at 16:24 +, [EMAIL PROTECTED] wrote: Hi, My apologies in advance, but I've been trying to subscribe to the HttpClient dev mailing list, and failing. When I try to send an email to [EMAIL PROTECTED], I get an email saying that user is not found. Can anyone tell me if that list is still active, and if so, Very much so how I can subscribe to it? HttpClient 4.0 development moved to the Jakarta HttpComponents project. You can subscribe to the dev list by sending an email to [EMAIL PROTECTED] Cheers Oleg Thanks, Jim - 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]
'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
On Wed, 2006-11-01 at 11:59 -0500, Rahul Akolkar wrote: Speaking of cross-commons, the JCL deps are all over the place. Which is probably OK for now, since most variants are point releases (1.0, 1.0.2, 1.0.3, 1.0.4 being popular ATM). Since JCL is the bottom rung of the ladder, we should do our bit and move as one (i.e. if a component wants to up the JCL version, it should be an [all] discussion, and all components should update trunk such that their next RC matches up). We could restrict this to minor or major release updates, but I don't see any harm in keeping the JCL point release consistent as well. [ ] +1 Sounds reasonable [ ] 0 [ ] -1 Sounds unreasonable -Rahul Rahul, Allow me to look at the situation from a different angle. I think what is definitely missing is a more formal and a clearly articulated product 'end of life' policy across all Jakarta. HttpClient, for instance, still mandates JCL 1.0.3 only, even though we recommend JCL 1.1 be used in production. Same goes for Commons Codec: 1.3 is preferred but only 1.2 is required, since there is no reason why HttpClient would not work with Codec 1.2. This way the project.xml captures an important bit of information: the oldest / least supported version of each individual project dependency. I would not want JCL level requirement be bumped up to 1.1 for no reason, as HttpClient works perfectly well with 1.0.3 or above. Having said all that I personally will have no issue of what so ever to put JCL 1.1 as a requirement for HttpClient 3.x the very same moment JCL 1.0.3 and 1.0.4 are declared 'end of life / support' by JCL maintainers. Take it for what it is worth. 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: 'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
On Wed, 2006-11-01 at 15:26 -0500, Rahul Akolkar wrote: On 11/1/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: ... I wasn't implying we require JCL 1.1 now, but that when we do, we diligently upgrade with each new release (for those components that release). Otherwise we have Foo that needs 1.0.2 and Bar that needs 1.1 and it cannot be obvious to everyone what its implication on needing Foo and Bar together is. Rahul, I am fine with (and probably in favor of) all Commons simultaneously upgrading to a specific version of JCL (or any other common dependency). In practical terms, though, that would pretty much mean that I personally stop testing the component(s) I am maintaining against older versions of JCL, thus rendering them de-facto EOL. Wouldn't it be better to just come out and declare JCL x.y.z end-of-life / no longer supported? Oleg Take it for what it is worth. snip/ You're modest ;-) -Rahul 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: [httpclient] Please make compile.debug = true the default
On Fri, 2006-08-18 at 12:55 -0400, Gary Gregory wrote: Hello All: Unlike version 3.0.1, the 3.1-alpha1 version is not compiled with debug information. I think compile.debug = true is a better default. Done Oleg Thanks, Gary - 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: [jira] Reopened: (LANG-195) [lang] String indentation feature request
On Tue, 2006-05-16 at 22:27 -0700, Henri Yandell wrote: It was when I only saw them occasionally at work. Seeing a fair few here, so going to ask Jeff about them. Hen Henri, We have had a similar problem with a number of issues (around 30) in HttpClient that had their status set as 'fixed' but resolution as 'unresolved'. The simplest way to go about the problem is to temporarily set the project's notification scheme to 'none', bulk re-open and close all affected tickets and re-enable the notification scheme afterward. For what it is worth. Cheers, Oleg On 5/16/06, Sandy McArthur [EMAIL PROTECTED] wrote: Is reopening and reclosing the official way to deal with issues that are both closed and listed as open? For Pool it lists 5 as being open: http://issues.apache.org/jira/browse/POOL but POOL-7, 34, and 42 are old and were closed in bugzilla: http://issues.apache.org/jira/browse/POOL-7 http://issues.apache.org/jira/browse/POOL-34 http://issues.apache.org/jira/browse/POOL-42 On 5/17/06, Henri Yandell (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/LANG-195?page=all ] Henri Yandell reopened LANG-195: Reopening so I can reclose. Migration bug. [lang] String indentation feature request - Key: LANG-195 URL: http://issues.apache.org/jira/browse/LANG-195 Project: Commons Lang Type: Improvement Environment: Operating System: All Platform: All Reporter: Michael Dang Priority: Minor Attachments: StringUtils.java, StringUtilsTest.java It would be nice to have a StringUtils.indentBlock(int size) method which go through a multi-line string and indent each line by size spaces, and/or a more general form of this. This helps greatly on nested toString() formatting. Such as a high level component spit out its toString() while calling StringUtils.join() to include its subcomponents' toString(), but you want to indent the subcomponent's string in a nested way. Well, to push this idea further, we may want a self format a object's toString form as a nice indented XML string. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - 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: [VOTE][all] Switch to Jira
+1 On Tue, 2006-05-02 at 10:51 -0700, Henri Yandell wrote: I'd like to call a vote that we switch to Jira. Here's the loose migration plan: * Make Bugzilla read-only * Import Commons project in Bugzilla into Commons project in JIRA This will pull over users, components, versions etc. * Setup notification scheme * Setup permission scheme * Setup group * For each of the 37 components ** Create new project - name: Commons Xxxx, key . ** Assign notification, permission and group ** Create relevant versions ** View component, bulk move all issues to new project * Cleanup Commons project (we'll still use it as a catch-all). Delete components/versions. The 37 components don't all have to be set up at the same time, we can take our time to move things out of the Commons project and into the individual Commons Foo projects. [ ] +1 [ ] -1 Vote to last 72 hours, 3 +1s required, 3/4 of active vote being +1. Hen - 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: Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
On Fri, 2006-04-28 at 23:58 +0200, Dennis Lundberg wrote: Henri Yandell wrote: On 4/28/06, Dennis Lundberg [EMAIL PROTECTED] wrote: I think that having a naming scheme is a good idea. From a user standpoint I see no reason for keeping the project ids short (3-4 characters). If Jakarta will be sharing the Jira instance with other ASF projects then using a J prefix for Jakarta project should be used, like this: - JLANG - JDIGESTER - JCOLLECTIONS - JHTTPCORE It does seem to be that there's more interest in the full name than the shorter one. In terms of the J***, we should we be asking infra@ what they want to do. If infra don't require us to use a prefix then we shouldn't use one. Keep it as simple as possible, but still readable. Folks, Then I will go ahead and try to scrap the existing project and create a new one with JHTTPCORE as the project id. Please complain loudly if you have any objections to that. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jira id naming convention for Jakarta projects; WAS Re: [all] Jira?
Henri Yandell wrote: On 4/27/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: Given this positive feedback so far, I'm going to email the infra@ mailing list to see how they would go about doing it _if_ we decided we wanted to move. I think we should be moving from 1 project with 37 components to 37 projects - it'll allow us to manage the components individually of each other without the kind of version overlap and general noise issues that we currently have. Jakarta Http Components just created their first Jira, and they got the name JHCHTTPCORE. Thus this _could_ get caught up in a debate about Jakarta and groupings. That's the id-code rather than the name (afaik). I didn't know that that was being standardised - JHCHTTPCORE is terrible, sounds like a sneeze. Ideally we should use whatever we want, it's not a namespace to fight over, just need to be unique. Henri, I also find JHCHTTPCORE absolutely horrible. I chose this id as I thought it would be the most politically correct one. I would very much rather prefer HTTPCORE or JHTTPCORE. Do you envisage a particular Jira id naming convention for Jakarta projects? At this point it is still not too late for us to scrap the project and start over with a different (better) project id. Oleg Personally, I'd like to see each component able to move grouping within Jakarta, thus we should use naming like JAKLANG or JAKARTALANG, rather than JLCLANG (for Jakarta Language Components). We also need to be aware that about half the commons websites now have links tailored to bugzilla, and these links get placed into maven built distributed projects. Another bit of work to do. Not sure anything can be done about that one. Do you mean the sites that get stuck in the zips (by maven built distributed projects) or something else? I suspect that every project has had a period of cold turkey when it moved over. Any idea Martin? Is there a .htaccess in the Bugzilla somehow? Hen - 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]
[site] jakarta-maven.css trouble
Stephen (and all), We have been having some problems with the HttpComponents site [1], which is rendered incorrectly in IE (and apparently IE only) when the jakarta-maven.css style-sheet is being used. The left-hand menu does not display anything unless I run the mouse pointer over it. With the style-sheet removed the site gets rendered correctly and consistently in IE and Mozilla based browsers. I have to confess I have only a very basic knowledge of the cascading style sheets and simply have no idea what a cause of this problem may be. I _believe_ you have originally authored this style-sheet. Do you happen to have any idea? Oleg [1] http://jakarta.apache.org/httpcomponents/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] HTTP components
On Tue, 2006-04-11 at 11:41 -0400, Gary Gregory wrote: Hello: What are the plans for the breakout of HttpClient into HTTP components? Every time I look for the code, I realize that there are no nightly-builds. The wiki [1] does not point to any code but I recall finding a site describing examples and SVN pointers, but I am not sure how I got there now. I'd love to replace our custom HTTP code in our server with something more robust. Before I start to think about picking apart the Tomcat HTTP support, will Http Commons see the light of day in nightly builds soon? Is there interest from others for using this project? Thanks, Gary [1] http://wiki.apache.org/jakarta-httpclient/HttpComponentsActionPlan Gary, I am in the process of cutting the first ALPHA release of HttpComponents HttpCore, but got bogged down trying to get Maven2 work the way I want. There are plans to get nightly builds going as well. You can find more details about the project here: http://jakarta.apache.org/httpcomponents/ Latest code here: https://svn.apache.org/repos/asf/jakarta/httpcomponents/ For regular updates on the state of the HttpComponents project please subscribe to the httpclient-dev@jakarta.apache.org list. We'd be extremely happy if you could lend us a helping hand with the infrastructure related stuff (or hacking on HttpComponents if you feel like to) Cheers 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: [pool] Announcing Release Candidate 2 for Pool 1.3
robert burrell donkin wrote: On Thu, 2006-03-23 at 14:12 -0800, Martin Cooper wrote: On 3/23/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-03-23 at 15:45 -0500, Sandy McArthur wrote: On 3/23/06, Oliver Heger [EMAIL PROTECTED] wrote: snip - LICENSE.txt and NOTICE.txt have unix style line endings in the zips. (This is not a problem for me, but was cause for some discussions in the past.) I'm on a mac os x box and unix style would be the default. How do other projects solve this other than building on win32? not sure if it can be done in maven 1. anyone know? Well, Maven can invoke Ant, so you could use this: http://ant.apache.org/manual/CoreTasks/fixcrlf.html good point :) how easy would it be to persuade maven to use different fixes before rolling the zip and the tar? - robert Robert, We had to implement something similar for [HttpClient] a while ago. You might find maven.xml from [HttpClient] package a good starting point http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/trunk/maven.xml 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: [site] No commons build
On Wed, 2006-03-15 at 00:12 +, Stephen Colebourne wrote: Progress to remove commons-build seems to be moving along nicley. So far at least [lang], [io], [primitives], [collections], [codec], [logging] and [betwixt] are done, plus [pool] unpublished. Commons [HttpClient] converted as well. Oleg I believe that I may have an even sneakier way to handle the shared menu part however. This is a medium term idea... We could write a piece of javascript that adds the menu items to the page dynamically after the page is loaded. The script could be hosted online and referenced by http. Thus one change to the javascript would affect all websites without regenerating them (as the CSS will do now). Unfortunately, I don't have the time to investigate or play with this right now, but if anyone else wants to feel free! In the meantime, I suggest continuing with the current process to remove commons-build as that seems to be working fine so far. Stephen - 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: Potential Bug In Circular Redirect
Ryan Smith wrote: Oleg, Thanks for the reply. Ok, the behavior can be correct, i understand you have a flag to disable circular redirects, but this still seems inappropriate. Becasue i still want to guard against genuine circular redirects from these false circular redirects, and since all browsers support this functionality, i think it would be nice if HttpClient could offer support for Browser HTTP Protocol like you can set a Param to act.like.a.browser which will 302 redirect when the uri is same but query string is different and basically operate as a forgiving http protocol if you so choose. Just an idea since the http protocol and the way all popular browsers implement it are much different. The trouble is that so called popular browsers do it rather badly. They tend to accept any garbage some badly written CGI scripts spit out at them instead of rejecting malformed HTTP messages as invalid thus giving the developers of those sites some incentive to do their job properly. We usually provide a lenient mode in those cases where the wording of the HTTP spec is vague or ambiguous, but we have no intension to work around some pretty gross violations of the HTTP spec that common browsers tend to forgive. After all, HttpClient is not a browser, nor a vacuum cleaner, it is what it is, an HTTP library. Hope this explains our position Oleg Thanks Oleg Kalnichevski wrote: On Thu, 2006-02-16 at 17:24 -0500, Ryan Smith wrote: ... I am using 3.0 RELEASE But i checked out the latest snap shot code, and the logic in HttpMethodDirector.java only checks for the URI, not URI + Query string. Ryan, I think this behavior is correct. It was implemented per this bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=33021 Set 'http.protocol.allow-circular-redirects' parameter to true to disable the check Oleg Below, plerase see my MANIFEST.MF that came with my httpclient.jar : Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: Apache Maven Built-By: Michael Package: org.apache.commons.httpclient Build-Jdk: 1.3.1_17 Extension-Name: commons-httpclient Specification-Title: Jakarta Commons HttpClient Specification-Vendor: Apache Software Foundation Implementation-Title: org.apache.commons.httpclient Implementation-Vendor: Apache Software Foundation Implementation-Version: 3.0 - 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: Potential Bug In Circular Redirect
Ryan Smith wrote: Oleg, Understood, thanks. Well, in the future, if you would ever decide to offer that functionality to be lienient on http as an option, i have some code for ya. Reverse Engineering popular browsers is a pain! Thanks again! :) -Ryan Ryan, Commons HttpClient in its present form suffers from feature and options bloat more than anything else. We can no longer keep on piling stuff on top of it. We (The Jakarta HttpComponents project) are currently in the process of rewriting HttpClient from scratch, primarily to make it more modular and reusable http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign http://wiki.apache.org/jakarta-httpclient/ProjectGoalsPage Feel free to consider submitting your code to HttpComponents at some point of time Oleg Oleg Kalnichevski wrote: Ryan Smith wrote: Oleg, Thanks for the reply. Ok, the behavior can be correct, i understand you have a flag to disable circular redirects, but this still seems inappropriate. Becasue i still want to guard against genuine circular redirects from these false circular redirects, and since all browsers support this functionality, i think it would be nice if HttpClient could offer support for Browser HTTP Protocol like you can set a Param to act.like.a.browser which will 302 redirect when the uri is same but query string is different and basically operate as a forgiving http protocol if you so choose. Just an idea since the http protocol and the way all popular browsers implement it are much different. The trouble is that so called popular browsers do it rather badly. They tend to accept any garbage some badly written CGI scripts spit out at them instead of rejecting malformed HTTP messages as invalid thus giving the developers of those sites some incentive to do their job properly. We usually provide a lenient mode in those cases where the wording of the HTTP spec is vague or ambiguous, but we have no intension to work around some pretty gross violations of the HTTP spec that common browsers tend to forgive. After all, HttpClient is not a browser, nor a vacuum cleaner, it is what it is, an HTTP library. Hope this explains our position Oleg Thanks Oleg Kalnichevski wrote: On Thu, 2006-02-16 at 17:24 -0500, Ryan Smith wrote: ... I am using 3.0 RELEASE But i checked out the latest snap shot code, and the logic in HttpMethodDirector.java only checks for the URI, not URI + Query string. Ryan, I think this behavior is correct. It was implemented per this bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=33021 Set 'http.protocol.allow-circular-redirects' parameter to true to disable the check Oleg Below, plerase see my MANIFEST.MF that came with my httpclient.jar : Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: Apache Maven Built-By: Michael Package: org.apache.commons.httpclient Build-Jdk: 1.3.1_17 Extension-Name: commons-httpclient Specification-Title: Jakarta Commons HttpClient Specification-Vendor: Apache Software Foundation Implementation-Title: org.apache.commons.httpclient Implementation-Vendor: Apache Software Foundation Implementation-Version: 3.0 - 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: Potential Bug In Circular Redirect
On Fri, 2006-02-17 at 12:51 -0500, Ryan Smith wrote: Olag, Thanks, i am exactly looking for a project like this. Thanks so much. I was thinking, the component idea is great, i like the http-spider, since thats what i work on . I have an open source project that was started a year ago: http://aspider.sf.net/ This is a autonomous java spider 1.4 compatible. Do you know who i could contact at the new http components projects to offer suggestions/code? Thanks again. -Ryan Ryan, You can get in touch with the Jakarta HttpComponents developers by subscribing to the httpclient-dev@jakarta.apache.org list. Just post your suggestions / ideas / patches to the list and participate in the discussion that will follow. Cheers, Oleg Oleg Kalnichevski wrote: Ryan Smith wrote: Oleg, Understood, thanks. Well, in the future, if you would ever decide to offer that functionality to be lienient on http as an option, i have some code for ya. Reverse Engineering popular browsers is a pain! Thanks again! :) -Ryan Ryan, Commons HttpClient in its present form suffers from feature and options bloat more than anything else. We can no longer keep on piling stuff on top of it. We (The Jakarta HttpComponents project) are currently in the process of rewriting HttpClient from scratch, primarily to make it more modular and reusable http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign http://wiki.apache.org/jakarta-httpclient/ProjectGoalsPage Feel free to consider submitting your code to HttpComponents at some point of time Oleg Oleg Kalnichevski wrote: Ryan Smith wrote: Oleg, Thanks for the reply. Ok, the behavior can be correct, i understand you have a flag to disable circular redirects, but this still seems inappropriate. Becasue i still want to guard against genuine circular redirects from these false circular redirects, and since all browsers support this functionality, i think it would be nice if HttpClient could offer support for Browser HTTP Protocol like you can set a Param to act.like.a.browser which will 302 redirect when the uri is same but query string is different and basically operate as a forgiving http protocol if you so choose. Just an idea since the http protocol and the way all popular browsers implement it are much different. The trouble is that so called popular browsers do it rather badly. They tend to accept any garbage some badly written CGI scripts spit out at them instead of rejecting malformed HTTP messages as invalid thus giving the developers of those sites some incentive to do their job properly. We usually provide a lenient mode in those cases where the wording of the HTTP spec is vague or ambiguous, but we have no intension to work around some pretty gross violations of the HTTP spec that common browsers tend to forgive. After all, HttpClient is not a browser, nor a vacuum cleaner, it is what it is, an HTTP library. Hope this explains our position Oleg Thanks Oleg Kalnichevski wrote: On Thu, 2006-02-16 at 17:24 -0500, Ryan Smith wrote: ... I am using 3.0 RELEASE But i checked out the latest snap shot code, and the logic in HttpMethodDirector.java only checks for the URI, not URI + Query string. Ryan, I think this behavior is correct. It was implemented per this bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=33021 Set 'http.protocol.allow-circular-redirects' parameter to true to disable the check Oleg Below, plerase see my MANIFEST.MF that came with my httpclient.jar : Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: Apache Maven Built-By: Michael Package: org.apache.commons.httpclient Build-Jdk: 1.3.1_17 Extension-Name: commons-httpclient Specification-Title: Jakarta Commons HttpClient Specification-Vendor: Apache Software Foundation Implementation-Title: org.apache.commons.httpclient Implementation-Vendor: Apache Software Foundation Implementation-Version: 3.0 - 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: Potential Bug In Circular Redirect
On Thu, 2006-02-16 at 15:39 -0500, Ryan Smith wrote: If i try a GET request on http://domain.com/site.html?x=1 And the domain.com web server does a 302 redirect to : /site.html?y=2 HttpCleint thinks its a Circular redirect b/c its *JUST* looking at the uri, not the uri + query string. Not sure if this breaks the protocol or not, but thought i would bring it to your attention, All browser support this type of redirect and recognizes it as not being circular, maybe HttpClient should examine the URI + the query string? Just a thought, ANy reply back on this would help alot. Currently i have to have the application to allow circular redirects. Thanks -Ryan Ryan, What version of HttpClient are you using? 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: Potential Bug In Circular Redirect
On Thu, 2006-02-16 at 17:24 -0500, Ryan Smith wrote: ... I am using 3.0 RELEASE But i checked out the latest snap shot code, and the logic in HttpMethodDirector.java only checks for the URI, not URI + Query string. Ryan, I think this behavior is correct. It was implemented per this bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=33021 Set 'http.protocol.allow-circular-redirects' parameter to true to disable the check Oleg Below, plerase see my MANIFEST.MF that came with my httpclient.jar : Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: Apache Maven Built-By: Michael Package: org.apache.commons.httpclient Build-Jdk: 1.3.1_17 Extension-Name: commons-httpclient Specification-Title: Jakarta Commons HttpClient Specification-Vendor: Apache Software Foundation Implementation-Title: org.apache.commons.httpclient Implementation-Vendor: Apache Software Foundation Implementation-Version: 3.0 - 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: Encryption - Common HTTP client
On Mon, 2006-01-30 at 11:50 +0530, PARVEEN GARG (GR/EIL) wrote: Hello Oleg, This means Commons HTTPClient does not include any encryption algo of its own. Please confirm. I can confirm that. Oleg Regards, Parveen On Wed, 2006-01-25 at 10:50 +0530, PARVEEN GARG (GR/EIL) wrote: Hello all, I have a question regarding encryption and export control. Does Apache, Commons HTTPclient include any SW encryption that restricts export (i.e. special ECCN code)? Best Regards, Parveen Garg Parveen, Commons HttpClient relies on standard java extensions JCE and JSSE to perform all its encryption/decryption operations. Hope this answers your question. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ From: PARVEEN GARG (GR/EIL) Sent: Wednesday, January 25, 2006 10:50 AM To: 'commons-dev@jakarta.apache.org' Subject: Encryption - Common HTTP client Hello all, I have a question regarding encryption and export control. Does Apache, Commons HTTPclient include any SW encryption that restricts export (i.e. special ECCN code)? Best Regards, Parveen Garg - 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: Encryption - Common HTTP client
On Wed, 2006-01-25 at 10:50 +0530, PARVEEN GARG (GR/EIL) wrote: Hello all, I have a question regarding encryption and export control. Does Apache, Commons HTTPclient include any SW encryption that restricts export (i.e. special ECCN code)? Best Regards, Parveen Garg Parveen, Commons HttpClient relies on standard java extensions JCE and JSSE to perform all its encryption/decryption operations. Hope this answers your question. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Don't count out NIO just yet; check out Grizzly
On Tue, 2005-12-13 at 13:41 -0500, David Smiley wrote: Last I recall, the HTTPClient team abandoned the idea of an NIO based HTTPClient implementation since testing that Oleg did turned up poor results. David, This is not exactly what the outcome was. So far I have seen no evidence of NIO offering any advantages compared to classic IO for _blocking_ HTTP, that is when the request / response content is to be produced / consumed using OutputStream / InputStream interfaces. HttpComponents will support NIO as a separate module for event driven (non-blocking) HTTP API Hope this clarifies things Oleg I happened upon some information today which may cause the HTTPClient team to rethink this: http://weblogs.java.net/blog/jfarcand/archive/2005/06/ grizzly_an_http.html It's a blog about Grizzly, an HTTP Listener using NIO for GlassFish. It's worth reading all of it. ~ David Smiley - 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: [httpclient] why all this stream wrapping
Torsten, This is a conscious design decision. The reason for these wrappers' existence is to ensure the reliability of persistent connections. (1) AutoCloseInputStream ensures the entire content body is consumed upon connection release thus making it reusable for other requests. Consider the situation when the response body is consumed only partially by the caller of HttpClient. (2) ContentLenghtInputStream does not permit reading beyond the advertised content length. Consider the fact that it is a common practice to write code to consume the content until the end of the stream (-1). With the persistent connection (kept alive by the server) this approach would fall flat. We are perfectly aware of shortcomings of the existing HttpClient API. It is butt ugly, plain and simple. I guess I am entitled to such a strong opinion as I have been maintaining HttpClient for years on a day to day basis. HttpClient is currently being rewritten and its API redesigned from scratch to address those shortcomings and provide a flexible platform one could use to build client-, proxy- and server-side HTTP services. I hope we will have a much cleaner and powerful API as a result: http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign There's already enough code in the SVN to check out already and get a feel of how things are shaping up http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/http-common/ Oleg On Sat, 2005-06-25 at 20:22 +0200, Torsten Curdt wrote: Can someone explain why the SocketInputStream is wrapped in an AutoCloseInputStream as well as a ContentLenghtInputStream. This is currently byting me in the ass and I would at least like to understand why a read with the return code of -1 is so bad that everything has to be wrapped like this. Just curious ...I assume there must be a reason cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
On Tue, Apr 05, 2005 at 11:46:49AM -0400, James Mitchell wrote: James, could you point me to any ASF document that regulates storage of dependencies in the repository, please? There may or may not be such a document. I'm not really interested in trying to be the binary police. I just noticed it while adding that project into my latest Eclipse development environment. James, Please correct me if I am wrong there's nothing wrong about keeping a copy of ASLv2 licenced library in the source code repository. It's just sloppy. snip If you would like me to setup the same download-dependencies for httpclient, I'd be happy to help. The example above uses ibiblio, but you can use any url. We would very much appreciate it Cheers, Oleg If not, then sorry to bother you. Have a good one. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] James Mitchell wrote: Sorry if this has already been brought up, but I noticed this a while back. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/lib/ I was under the impression that we are not supposed to keep this kind of stuff in svnbut I could be wrong. - 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: [httpclient] Jars in the repository
Odi, I have not looked at the proposed solution, so I may be wrong here, but I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an external repository (such as ibiblio). If it is indeed the case I personally see no problem with removing dependencies from SVN. I will not insist, though Oleg On Tue, Apr 05, 2005 at 06:25:42PM +0200, Ortwin Gl?ck wrote: Oleg Kalnichevski wrote: If you would like me to setup the same download-dependencies for httpclient, I'd be happy to help. The example above uses ibiblio, but you can use any url. We would very much appreciate it Cheers, Oleg Is that *necessary* for GUMP or anything else, Oleg? If not then I prefer not to have that. - 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: [httpclient] Jars in the repository
On Tue, 2005-04-05 at 18:57 +0200, Ortwin Glück wrote: Oleg Kalnichevski wrote: Odi, I have not looked at the proposed solution, so I may be wrong here, but I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an external repository (such as ibiblio). If it is indeed the case I personally see no problem with removing dependencies from SVN. I will not insist, though Oleg Yes, that's what it does. Maybe that I am missing something, but I have no idea what should be the benefit of that. Explicit dependency management for one (for those who prefer Ant to Maven, like myself). 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. I see it differently, but as far as I am concerned this whole thing is a non-issue. Should James decide to submit a patch, I _personally_ will be quite happy to vote +1 for it. At the same time, I'll have no problems of what so ever to move on, should you veto it with -1. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. [quietly and humbly] I do. For such a simple-minded person like me, every Maven deployment should come with Dion included. [ducking and hiding] Anyways, I would rather see all this time and efforts spent on Jakarta Http(Client) API redesign Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient]contrib
On Mon, 2005-03-07 at 19:07 -0400, Derek Lohnes wrote: I was looking for a jar containing the contrib classes for SSL. Can some tell me what the intention is for this stuff will it be packaged as part of the distribution? Hi Derek, We may eventually consider moving the AuthSSLProtocolSocketFactory http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/AuthSSLProtocolSocketFactory.java?view=markup to HttpClient proper. As to the rest of SSL socket factories in the SSL contrib package, they usually implement a security short-cut or based upon an assumption which may be too application specific and therefore are considered unsafe for general use without a thorough review and modification. If you want to use it do you need to check it out of CVS and build it yourself? This is precisely what we encourage people to do: get the source code, review it carefully, make system specific adjustments. Oleg Thanks Derek - 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: [feedparser] Discuss: FeedParser move to Commons Proper...
On Sat, 2005-02-05 at 10:45 +, Stephen Colebourne wrote: From: Kevin A. Burton [EMAIL PROTECTED] snip Is there a pattern of projects moving from the commons to a top level jakarta project? HttpClient is the only one that has tried to go to be a subproject within Jakarta. However it still isn't there, despite it being approved long ago. The sole reason HttpClient is not currently seen as present at the Jakarta level is our intention to release HttpClient 3.0 out of Jakarta Commons in order to avoid confusion primarily associated with package (re)naming and so on. As soon as HttpClient 3.0 goes final we will move quickly to establish presence at the Jakarta level. You can count on our (at least my) assistance with promotion process should you decide to give it a go Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r149154 - jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLSocketFactory.java jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java
Brett, Unfortunately this doesn't help. The trouble is that junit resource files do not seem to be copied to HOME/target/test-classes/ If you declare the resources inside your unit test element they should be: unitTest includes ... /includes resources resource directorysrc/test/directory includes include**/*.properties/include /includes /resource /resources /unitTest Does that help? It truly does. Many thanks, Brett Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r149154 - jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLSocketFactory.java jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/ssl/SimpleSSLTestProtocolSocketFactory.java
On Mon, 2005-01-31 at 06:44 +0800, Brett Porter wrote: Yuck :) Can we help fix this? IIRC, other people having problems have corrected them by using /org/apache/commons/... (note leading /). Brett, Unfortunately this doesn't help. The trouble is that junit resource files do not seem to be copied to HOME/target/test-classes/ If I manually copy the required resources to HOME/target/test-classes/ test cases perform as expected Oleg It's been a while since I read the spec on this but it is because no / has a different classloader search criteria which doesn't work inside Maven. I think another alternative is to fork the unit tests. If these resolutions are correct, its probably time for a FAQ entry... - Brett Quoting [EMAIL PROTECTED] [EMAIL PROTECTED]: Author: olegk Date: Sun Jan 30 13:02:40 2005 New Revision: 149154 URL: http://svn.apache.org/viewcvs?view=revrev=149154 Log: Maven workaround - 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: [all][VOTE] svn migration
+1 On Sat, 2005-01-22 at 13:31 -0500, Tim O'Brien wrote: Alright a sufficient amount of time has passed for public comments and testing. This is a vote thread for migrating commons to SVN. If this vote passes, I'll contact Justin and schedule the least disruptive migration time possible. Tim O'Brien - 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]
[HttpClient] Re: SVN awareness
Folks, I took a quick look at the test SVN repository. All looks sane to me. I checked out HttpClient 3.0 (trunk) and HttpClient 2.0.x (HTTPCLIENT_2_0_BRANCH) snapshots. They seems identical to the CVS content of two days ago. As far as I am concerned we should be good to take the plunge Cheers, Oleg On Sun, Dec 19, 2004 at 07:33:42PM -0500, Henri Yandell wrote: You guys can tend to get a big ignored out here on your own list. Wanted to make sure that you're aware of the plans to move Commons from CVS over to SVN soon as it'll affect you too. Once in SVN, we can easily promote you out when the time comes to be a Jakarta sub-project. Tim O'Brien and Martin Cooper are handling the migration. Hen - 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: too many TCP connections using httpClient?
And what if we create an HttpClient instance with HttpClient agent = new HttpClient(); in a request, do we need any shutdown() like method call? Guillaume, Ideally you do. Per default HttpClient uses SimpleHttpConnectionManager as its connection manager. Even though SimpleHttpConnectionManager employs only one connection, it does keep it alive whenever possible. This renders SimpleHttpConnectionManager susceptible to the same dangling connection problem, albeit not at the same level as MultiThreadedHttpConnectionManager The trouble is that SimpleHttpConnectionManager does not provide shutdown method in the 2.0 branch. So, if you do have to instantiate tons of HttpClients in your application, you should seriously consider providing a custom connection manager that can be cleanly shut down Hope this helps Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Auto-detecting proxy settings in a standalone Java app
And how often does that happen in a course of one working day? I'd say not that often. I do agree with Roland that a startup script written in VBScript appears to be the best solution for the problem Oleg On Fri, 2004-10-22 at 10:54, Ortwin Glck wrote: Roland Weber wrote: Wait, here is another idea: you could write a startup script that does the proxy settings lookup, then passes the settings through -D definitions as system properties, which can be accessed by your Java application. That's a bit less ugly than calling native code from within the app. The proxy settings for the HttpURLConnection of the JDK are expected as system properties, too. Of course that implies you need to restart your app, everytime the proxy settings change... Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: too many TCP connections using httpClient?
Massimo, Calling HttpMethod#releaseConnection() does not guarantee that the active connection will be closed. HttpClient _always_ tries its best to reuse open connections. Whenever a connection can be kept alive, HttpClient will keep it alive. That effectively means that when an HttpClient instance goes out of scope, the underlying connection (or several connections) may be left open until GC-ed. Therefore, we recommend to have only one HttpClient instance per application/component. New HttpClient instance per request approach is HIGHLY discouraged: class MyCommunicationComponent { private HttpClient agent = new HttpClient(); private void doStuff() { HttpMethod method = new GetMethod(timerURL); this.agent.executeMethod(method); ... } } If you absolutely have to create new instances of HttpClient we recommend explicitly shutting down the connection manager, whenever you are done using an HttpClient instance: class MyCommunicationComponent { private void doStuff() { MultiThreadedHttpConnectionManager connman = new MultiThreadedHttpConnectionManager(); HttpClient agent = new HttpClient(connman); HttpMethod method = new GetMethod(timerURL); agent.executeMethod(method); ... connman.shutdown(); } } Hope this helps Oleg On Thu, 2004-10-21 at 15:34, Massimo Signori wrote: Hi everybody, this is my code: private void notifyTimeServer() { // logger.debug(notifyTimeServer, + timerURL); // HttpClient client = new HttpClient(); HttpMethod method = new GetMethod(timerURL); int statusCode = -1; for (int attempt = 0; statusCode == -1 attempt MAX_CALLING_ATTEMPTS; attempt++) { // logger.debug(Establishing connection); // try { statusCode = client.executeMethod(method); } catch (Exception e) { // logger.error(Error calling jsp); // } } if (statusCode != -1) { // logger.debug(Connection estabilished); // byte[] responseBody = method.getResponseBody(); method.releaseConnection(); } } I was looking with TCPView the number of TCP connections that this piece of code is opening when talking to the server and I saw that opens an incredible number of connections. All TCP connections are in TIME_WAIT state. Is there something wrong in this code? Or I'm forgetting something? Best regards, Massimo - 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: File Uploading using HttpClient
Sudhakar, Here's a few sample apps that you may find useful: http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/?only_with_tag=HTTPCLIENT_2_0_BRANCH I do not know of a good comparison of HttpClient vs. competition concentrating primarily on the file upload functionality. For a general feature matrix you may want to see this one http://www.nogoop.com/product_16.html#compare Oleg On Wed, 2004-10-20 at 08:19, IndianAtTech wrote: Hi ALL, I would like to have a working example that helps me to understand the upload concept using HttpClient. I also wanted to know Pros and Cons of HttpClient against other API that supports Uploading file. Regards Sudhakar Koundinya - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: File Uploading using HttpClient
On Wed, 2004-10-20 at 11:50, Michael McGrady wrote: Not sure what you are saying here, Gluck. Can you explain? I personally see these two implementations as competing applications. Michael, These are complementary technologies. FileUpload implements the receiving/decoding logic, whereas HttpClient implements the sending/encoding logic. Hope this clarifies things a little Oleg Michael McGrady Ortwin Glck wrote: IndianAtTech wrote: OK, Thanks for the Information. I have found FileUpload API from Jakarta commons project Why do we have 2 API for Uploading from Same project 1. MultipartFileUpload - (Jakarta-commons)HttpClient - Project This is a client side interface to upload to a server. 2. FileUpload - (Jakarta Commons) This is a server side interface to consume the uploaded file. Or, Is there any conceptual difference between two API?? Yes. See above. - 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] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bugzilla] vs [JIRA] revisited
Folks, As a result of the discussion my assumption is that we want to go ahead with migration from Bugzilla to JIRA. If you have any objections or concerns it is the right time to voice them. I am going to update the change request http://issues.apache.org/jira/browse/INFRA-74 shortly stating out intention to proceed with the migration if no one speaks out. Oleg On Mon, 2004-10-11 at 16:12, Oleg Kalnichevski wrote: Folks Due to the recent upgrade of HttpClient to a full project in Bugzilla JIRA no longer has a definitive edge over Bugzilla. Nonetheless, JIRA still a newer and more flexible system which can potentially make our life and that of our users simpler. http://nagoya.apache.org/jira/browse/INFRA-74 The only fundamental gripe with JIRA that some folks have is that it is not open-source. I do not think we should try to be holier than the Pope himself, since too many projects have already defected to JIRA Religious reasons aside, I also foresee technical difficulties too. Currently (at least with Bugzilla 2.14.2) there appears no way to make a project completely read-only. Submission of new reports can be disabled, but one can still modify the existing bug reports. There is a few options: (1) Ask folks to resubmit their comments in JIRA when important / ignore modifications made in Bugzilla when unimportant. (2) Tweak Bugzilla a little to prevent mutation of existing reports. Note, supposedly Apache Bugzilla is already a fork. So, the real trouble here is to convince the Infrastructure folks to apply a patch, and more importantly reapply it every time Bugzilla is upgraded. Now, the REAL REAL trouble is that it almost took a full scale nuclear conflict between the Evil Russian Empire (me) and the Freedom Alliance (the Infrastructure team) to implement what turned out to be a fairly minor change to get HttpClient promoted to a project status. From now on, I am deeply skeptical about everything that has to do with Bugzilla maintenance. Besides, I may not survive yet another squabble with Noel. (3) Wait until other Jakarta Commons project migrate first. Long may be the wait, though So, what's the popular opinion on that? Non-committers are highly encouraged to voice their opinion too Evil Comrade Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connection timing out
On Fri, 2004-10-15 at 06:24, Vinay Murthy wrote: Hi Oleg, I guess upgrading to HttpClient 2.0.2 seems to work as far as the connection timeout issue is concerned. Thanks for that.Was that an issue in 2.0-rc2 ? I am not aware of any connection timeout related issue with any of RC releases. We usually have a policy of supporting the latest stable release and CVS HEAD only. That's the reason I asked you to upgrade But I guess, I seem to be having problems with regard to cookie handling. I believe that the cookie that is sent by Yahoo! upon signing in, is not being handled properly by my code ; as a result of which it seems expired to the server. And hence I am led to the Verify Password page. The httpclient page does mention about Yahoo!'s cookies posing problems. Does the problem still persist? Yahoo does a lot of nasty tricks to make scripted (non-interactive) logins VERY difficult. I know of only one application, called MrPostman, that provides some degree of support for Yahoo services http://cvs.sourceforge.net/viewcvs.py/mrpostman/mrpostman/src/org/mrbook/mrpostman/yahoo/YahooMailSession.java?view=markup My advice is to take a very good look at the YahooMailSession source code and tweak it to your specific needs Secondly, I got the following log warning: Oct 15, 2004 9:42:28 AM org.apache.commons.httpclient.HttpMethodBase getResponseBody WARNING: Going to buffer response body of large or unknown size. Using getResponseAsStream instead is recommended. I believe the warning is self-explanatory HttpMethod#getResponseBody tries to buffer the entire response content in memory, which may be a pretty bad idea when dealing with large response entities. Therefore we recommend using non-buffering HttpMethod#getResponseAsStream method and implement a content retrieval/buffering logic that is best suited for your specific application. Hope this helps Oleg Regards Vinay On Thu, 14 Oct 2004 19:02:23 +0200, Oleg Kalnichevski [EMAIL PROTECTED] wrote: Please upgrade to HttpClient 2.0.2 and retest. In the future please do send your response to the list Oleg On Thu, 2004-10-14 at 18:58, Vinay Murthy wrote: Hi, JRE = 1.4.2 httpClient =2.0-rc2 (.jar) Hope that helps, Regards Vinay On Thu, 14 Oct 2004 18:51:17 +0200, Oleg Kalnichevski [EMAIL PROTECTED] wrote: Vinay, What HttpClient and JRE version are you using? Oleg On Thu, 2004-10-14 at 18:31, Vinay Murthy wrote: Hi, I am using httpClient as a part of htmlUnit. I tried logging into my mail account (Yahoo!), but unfortunately ended with an exception trace: java.net.ConnectException: Connection timed out: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.init(Unknown Source) at java.net.Socket.init(Unknown Source) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:105) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:663) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:661) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529) How can work around this problem ? Can someboby help ? Regards Vinay - 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] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail
Re: Connection timing out
On Fri, 2004-10-15 at 12:08, Vinay Murthy wrote: Hi, Does httpClient have features to provide any kind of client-side caching of web objects ? For eg, incase of frequently visited sites that tend to have a lot of images on them , does httpClient cache them on the client-side ? Does it retrieve these objects everytime ? Do you think this feature needs to be implemented in a layer above httpClient Yes, we do. We are convinced HttpClient should stay what it is, an HTTP transport library, and we have no plans to make a web browser or a vacuum cleaner out of it ? Regards Vinay On Fri, 15 Oct 2004 09:54:33 +0530, Vinay Murthy [EMAIL PROTECTED] wrote: Hi Oleg, I guess upgrading to HttpClient 2.0.2 seems to work as far as the connection timeout issue is concerned. Thanks for that.Was that an issue in 2.0-rc2 ? But I guess, I seem to be having problems with regard to cookie handling. I believe that the cookie that is sent by Yahoo! upon signing in, is not being handled properly by my code ; as a result of which it seems expired to the server. And hence I am led to the Verify Password page. The httpclient page does mention about Yahoo!'s cookies posing problems. Does the problem still persist? Secondly, I got the following log warning: Oct 15, 2004 9:42:28 AM org.apache.commons.httpclient.HttpMethodBase getResponseBody WARNING: Going to buffer response body of large or unknown size. Using getResponseAsStream instead is recommended. Regards Vinay On Thu, 14 Oct 2004 19:02:23 +0200, Oleg Kalnichevski [EMAIL PROTECTED] wrote: Please upgrade to HttpClient 2.0.2 and retest. In the future please do send your response to the list Oleg On Thu, 2004-10-14 at 18:58, Vinay Murthy wrote: Hi, JRE = 1.4.2 httpClient =2.0-rc2 (.jar) Hope that helps, Regards Vinay On Thu, 14 Oct 2004 18:51:17 +0200, Oleg Kalnichevski [EMAIL PROTECTED] wrote: Vinay, What HttpClient and JRE version are you using? Oleg On Thu, 2004-10-14 at 18:31, Vinay Murthy wrote: Hi, I am using httpClient as a part of htmlUnit. I tried logging into my mail account (Yahoo!), but unfortunately ended with an exception trace: java.net.ConnectException: Connection timed out: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.init(Unknown Source) at java.net.Socket.init(Unknown Source) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:105) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:663) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:661) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529) How can work around this problem ? Can someboby help ? Regards Vinay - 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] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connection timing out
Vinay, What HttpClient and JRE version are you using? Oleg On Thu, 2004-10-14 at 18:31, Vinay Murthy wrote: Hi, I am using httpClient as a part of htmlUnit. I tried logging into my mail account (Yahoo!), but unfortunately ended with an exception trace: java.net.ConnectException: Connection timed out: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.init(Unknown Source) at java.net.Socket.init(Unknown Source) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:105) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:663) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:661) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529) How can work around this problem ? Can someboby help ? Regards Vinay - 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: UTF-8 Encoding Enquiry
Ramiel, I think you came pretty close. Two things require minor corrections (1) Content-Type HTTP POST per default uses so called URL encoding when submitting HTML forms. Setting the content type to 'text/plain' may cause some web servers to misinterpret the request parameters Try this instead postmethod.setRequestHeader( Content-Type, application/x-www-form-urlencoded; charset=utf-8); (2) Request parameters This operation is completely redundant new String(((String) paramList.get(paramName)).getBytes(UTF-8),UTF-8) As far as I understand it produces exactly the same Unicode string // Assign parameters into post method Iterator it = paramList.keySet().iterator(); while (it.hasNext()) { String paramName = (String) it.next(); postmethod.addParameter(paramName, paramList.get(paramName)); } HttpClient will do all the charset conversion for you. Just make sure the charser attribute of the Content-Type is set For details please refer to the HttpClient encoding guide http://jakarta.apache.org/commons/httpclient/charencodings.html Hope this helps Oleg On Wed, 2004-10-13 at 13:22, Ramiel Fong wrote: Hi~! Thanks in advance for those who will be looking into my problem. I am having difficulty in sending chinese characters via postmethod. // Create an instance of HttpClient HttpClient httpclient = new HttpClient(); // Create a method instance PostMethod postmethod = new PostMethod(url); // Assign parameters into post method Iterator it = paramList.keySet().iterator(); while (it.hasNext()) { String paramName = (String) it.next(); postmethod.addParameter(paramName, new String(((String) paramList.get(paramName)).getBytes(UTF-8),UTF-8)); } With the above codes I succeeded in sending out the postmethod with the list of parameters. But all chinese characters become ? upon received by back-end. Therefor I add this: // Set request header - character set postmethod.setRequestHeader(Content-Type, text/plain; charset=utf-8); With the above lines added, the back-end server could receive the postmethod request but can only find an empty parameter list. The back-end server is indeed a servlet resided on websphere 5 server. The codes to get the one of the parameter is: request.setCharacterEncoding(UTF-8); String inXMLMessage = (String) request.getParameter(xmlmessage); Since the parameter list become empty the above method failed. Therefore I switched to another method - to get the entire request body with input stream and added the following codes: if (inXMLMessage == null) inXMLMessage = getXMLMessageFromInputStream (request.getInputStream()); .. public String getXMLMessageFromInputStream (InputStream requestIS) { String XMLMessage = ; try { InputStreamReader isr = new InputStreamReader(requestIS, UTF-8); BufferedReader r = new BufferedReader(isr); XMLMessage = r.readLine(); XMLMessage = URLDecoder.decode(XMLMessage); XMLMessage = XMLMessage.substring(11); } catch (Exception ex) {...} return XMLMessage; } With the above I succeeded to get the parameter I want, i.e. an xml message, from the input stream, but the entire message are escaped, that is space and tab become +, become %3C, etc. Thaz why I need to use URLDecoder . But the worst part is that all chinese charaters become weird codes like aelig;cedil;not;egrave;copy;brvbar;, which should be in traditional chinese. I am really at my wits end as to what is happening here. Would somebody throw a light upon my proble? A thousand thanks in advance! Regards Ramiel Fong - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] HttpClient is now a separate project in [Bugzilla] issue tracking system
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]
Re: Invalid response tests
On Tue, 2004-10-12 at 04:04, Michael Becke wrote: Hello All, I've been starting to refactor some of the webapp test and have come upon a bit of a problem. I'm not terribly familiar with the SimpleHttpServer setup so perhaps there is simple solution that is eluding me. The problem is that sending invalid responses can be quite difficult. Specifically I'm trying to send a response with content but no content length. Is there an easy way to do this? Mike Mike, HttpRequestHandler provides direct access to SimpleHttpServerConnection, which should be sufficient to simulate pretty much any type of malformed responses: http://jakarta.apache.org/commons/httpclient/3.0/xref-test/org/apache/commons/httpclient/server/HttpRequestHandler.html You may want to take a look at TestBadContentLength as an example of using HttpRequestHandler http://jakarta.apache.org/commons/httpclient/3.0/xref-test/org/apache/commons/httpclient/TestBadContentLength.html Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] HttpClient is now a separate project in [Bugzilla] issue tracking system
Adrian, That would be quite handy. We have over a dozen milestones (pre 2.0.3 and 3.0b1) that are no longer relevant and should clean up at some point. Do you know how we are supposed to go about asking for Bugzilla privileges? We do not need a full blown admin privileges. In Bugzilla terms we need 'edit components' permission Oleg On Tue, 2004-10-12 at 12:02, Adrian Sutton wrote: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugzilla
Oh, man. No thunder, just emotional devastation. It has been quite an ugly squabble and have made a few non-friends among the Infrastructure folks. Anyways, we need to make an announcement on the site in order to preempt (some of) the confusion among the users. Finally this issue is done with and we can move on with the migration process Evil Comrade Oleg On Mon, 2004-10-11 at 04:46, Adrian Sutton wrote: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Release of Commons HttpClient 2.0.2
Javen HttpClient 2.0.x represents the stable branch whereas HttpClient 3.0 is still in ALPHA development stage and may be subject to API change. We are planning to freeze the 3.0 API quite soon and start working toward the code freeze and a first stable release For detailed information on new features in HttpClient 3.0 please refer to: http://jakarta.apache.org/commons/httpclient/3.0/news.html Oleg On Mon, 2004-10-11 at 08:18, Javen Fang wrote: http://jakarta.apache.org/commons/httpclient/3.0/index.html But what I see the new is 3.0. what is different is 2.0 and 3.0 On Sun, 10 Oct 2004 23:12:15 -0700 (PDT), Srinivas Velidanda [EMAIL PROTECTED] wrote: Hi, I have been using HttpClient version 2.0.1. But have some problems while uploading multiple files. Please let me know 1. Can I upload multiple files using httpclient api from client to server (client and server running on different systems). 2. I worked with sample code at http://www.theserverside.com/articles/article.tss?l=HttpClient_FileUpload. Everything works fine if I run the sample on the same systems but I cannot do the same by making the client and server on different systems. I used the following sample at the above url Listing 9-6. HttpMultiPartFileUpload.java package com.commonsbook.chap9; import java.io.File; import java.io.IOException; import org.apache.commons.httpclient.HttpClient; import org.apache.commons.httpclient.methods.MultipartPostMethod; public class HttpMultiPartFileUpload { private static String url = http://localhost:8080/HttpServerSideApp/ProcessFileUpload.jsp;; public static void main(String[] args) throws IOException { HttpClient client = new HttpClient(); MultipartPostMethod mPost = new MultipartPostMethod(url); client.setConnectionTimeout(8000); // Send any XML file as the body of the POST request File f1 = new File(students.xml); File f2 = new File(academy.xml); File f3 = new File(academyRules.xml); System.out.println(File1 Length = + f1.length()); System.out.println(File2 Length = + f2.length()); System.out.println(File3 Length = + f3.length()); mPost.addParameter(f1.getName(), f1); mPost.addParameter(f2.getName(), f2); mPost.addParameter(f3.getName(), f3); int statusCode1 = client.executeMethod(mPost); System.out.println(statusLine + mPost.getStatusLine()); mPost.releaseConnection(); } } and for processing file upload i used the following JSP %@ page contentType=text/html;charset=windows-1252% %@ page import=org.apache.commons.fileupload.DiskFileUpload% %@ page import=org.apache.commons.fileupload.FileItem% %@ page import=java.util.List% %@ page import=java.util.Iterator% %@ page import=java.io.File% html head meta http-equiv=Content-Type content=text/html; charset=windows-1252 titleProcess File Upload/title /head % System.out.println(Content Type =+request.getContentType()); DiskFileUpload fu = new DiskFileUpload(); // If file size exceeds, a FileUploadException will be thrown fu.setSizeMax(100); List fileItems = fu.parseRequest(request); Iterator itr = fileItems.iterator(); while(itr.hasNext()) { FileItem fi = (FileItem)itr.next(); //Check if not form field so as to only handle the file inputs //else condition handles the submit button input if(!fi.isFormField()) { System.out.println(\nNAME: +fi.getName()); System.out.println(SIZE: +fi.getSize()); //System.out.println(fi.getOutputStream().toString()); File fNew= new File(application.getRealPath(/), fi.getName()); System.out.println(fNew.getAbsolutePath()); fi.write(fNew); } else { System.out.println(Field =+fi.getFieldName()); } } % body Upload Successful!! /body /html 3. But I could not do the same by making the server and client on different systems. 4. Pl. let me know for the same purpose is there any patch available with current version released. i.e.2.0.2 5. Is there a way to build Multipart request without putting the Http File Item in the form. i.e. dynamically getting the file Items created programmatically at client side and passing the Multipart request to the server thanks, Srinivas. Michael Becke [EMAIL PROTECTED] wrote: The Jakarta Commons team is pleased to announce the release of HttpClient 2.0.2. This release greatly improves the performance of executing methods where the response contains little or no content. Please visit the HttpClient 2.0 web site for more information on HttpClient and this release. Thank you,
Re: [ANNOUNCE] Release of Commons HttpClient 2.0.2
Hi Sudhakar, Why should a personal opinion of one guy hurt? We are all entitled to have our own opinion. As imperfect as HttpClient may be, it is still being used by numerous state of the art projects such as Spring framework, and to me that counts more than an opinion of one guy. 1. API is not stable This is basically correct. See point 2. 2. API is flaky This is basically correct. The API is far from being perfect. This said, in my opinion is still wy better than Java Net API. The reason why we can't keep the API stable is because early on (before any of the current committers joined the project) a few unfortunate design have been made. Now we are facing an unpleasant task of fixing them while supporting the existing user base. This is not an easy task 3. No proper documentation and easy to understand explanation Allow me to disagree. Some folks expressed opinion that HttpClient had better documentation than other projects. http://www.onjava.com/pub/a/onjava/2003/06/25/commons.html?page=last This is not to say that documentation could not be better, but we rarely have people complaining about the quality of support for HttpClient 4. No proper examples provided by team to understand API. Allow me to disagree. See for yourself http://jakarta.apache.org/commons/httpclient/tutorial.html http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/?only_with_tag=HTTPCLIENT_2_0_BRANCH 4. Security problems may araise Whenever you venture out of your home you are at risk of being hit by a bus. Whenever you have your computer connected to a public network, security problems may arise. What specific security problems that expert was referring to? 5. Takes much memory when compared with Java Net API Try posting 200MB file with Java Net API and tell me about memory consumption. 6. My code becomes complicated, if I use HttpCLient Whenever you write code, it can get complicated unless you keep it simple 7. As name it says limited to Http Protocol. - Which is not suitable for multi protocol implementations. This is correct. We have no plans changing that. So I need some clarifications from Development team of HttpClient API. I hope I get the Positive response from the team regarding all matters what I have mentioned above. I hope that clarifies things a little Cheers Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] HttpClient is now a separate project in [Bugzilla] issue tracking system
HttpClient project has taken a very important step toward becoming a full-fledged Jakarta level project. From today, HttpClient is a separate project in Apache Bugzilla issue tracking system. It is no longer a component of the Commons project. Please use the following details when filing bug reports for 2.0 and 3.0 branches of HttpClient: Product: HttpClient Component: Commons HttpClient Use the following URL for convenience: http://issues.apache.org/bugzilla/enter_bug.cgi?product=HttpClient All the existing issues, closed and open, are still available under their usual URLs. With HttpClient being a separate project in Bugzilla we will be able to define release versions and target milestones independently from Jakarta Commons Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Bugzilla] vs [JIRA] revisited
Folks Due to the recent upgrade of HttpClient to a full project in Bugzilla JIRA no longer has a definitive edge over Bugzilla. Nonetheless, JIRA still a newer and more flexible system which can potentially make our life and that of our users simpler. http://nagoya.apache.org/jira/browse/INFRA-74 The only fundamental gripe with JIRA that some folks have is that it is not open-source. I do not think we should try to be holier than the Pope himself, since too many projects have already defected to JIRA Religious reasons aside, I also foresee technical difficulties too. Currently (at least with Bugzilla 2.14.2) there appears no way to make a project completely read-only. Submission of new reports can be disabled, but one can still modify the existing bug reports. There is a few options: (1) Ask folks to resubmit their comments in JIRA when important / ignore modifications made in Bugzilla when unimportant. (2) Tweak Bugzilla a little to prevent mutation of existing reports. Note, supposedly Apache Bugzilla is already a fork. So, the real trouble here is to convince the Infrastructure folks to apply a patch, and more importantly reapply it every time Bugzilla is upgraded. Now, the REAL REAL trouble is that it almost took a full scale nuclear conflict between the Evil Russian Empire (me) and the Freedom Alliance (the Infrastructure team) to implement what turned out to be a fairly minor change to get HttpClient promoted to a project status. From now on, I am deeply skeptical about everything that has to do with Bugzilla maintenance. Besides, I may not survive yet another squabble with Noel. (3) Wait until other Jakarta Commons project migrate first. Long may be the wait, though So, what's the popular opinion on that? Non-committers are highly encouraged to voice their opinion too Evil Comrade Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bugzilla] vs [JIRA] revisited
Hi Roland I agree this makes sense. I am not sure, though, whether we can reasonably expect things to happen in one 'Big Bang': mailing lists, new CVS repository, web site, JIRA migration and so on. Most likely not. Besides, unless we start getting MASSIVELY more feedback on 3.0, I am not sure what else we can do but start hacking on 4.0 branch while 3.0 still goes through its natural development cycle: alpha - beta - rc - release. I sense the work on 4.0 may well commence as early as next month. Basically that will buy us some time, but not much. I certainly want to start the discussion on the 4.0 architecture (at least in broad strokes) very, very soon. This, again, makes the issue of issue tracking system highly important, as we better have a sane road map and reasonably well articulated strategy as soon as people start asking what the heck Jakarta HttpClient 4.0 is all about and how on earth we ended up with 3 API incompatible branches. Oleg On Mon, 2004-10-11 at 16:43, Roland Weber wrote: Hi Oleg, could we synchronize the switch with the 4.0 implementation? In other words, continue with Bugzilla for 2.0 and 3.0, but once work gets started on 4.0, where the API changes and the package names probably change, then the bug tracking system changes as well? cheers, Roland *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: redirect problem in HttpClient
Zulfi, According to the log the request body does get written to the socket output stream: [DEBUG] wire - - SOAP-ENV:Envelope ... ello/SOAP-ENV:Body/SOAP-ENV:Envelope So, really I do not think this has anything to do with HttpClient given the data. Do try out different settings: CONTENT_LENGTH_AUTO and CONTENT_LENGTH_CHUNKED and see if that makes any difference. I suggest you try to reproduce the problem using a simple (or as simple as possible) test case, something which I could also run locally on my machine. I am afraid we will be unable to help you unless you manage to narrow the problem down, at least somewhat Cheers, Oleg On Sat, 2004-10-09 at 00:10, Zulfi Umrani wrote: Hi Oleg, I am setting the request body as InputStream, but I do set the Content-Length header as well. I do print out the bytes for body as string before I call executeMethod and I do see the body being printed even for the transaction in question. The InputStream for body is created out of those bytes. I have enabled full wire(header and content) + context logging by setting the following properties. Log is once again attahced for the transaction in question. Let me know if I have to set some other property as well. System.setProperty(org.apache.commons.logging.Log, org.apache.commons.logging.impl.SimpleLog); System.setProperty(org.apache.commons.logging.simplelog.showdatetime, true); System.setProperty(org.apache.commons.logging.simplelog.log.httpclient.wire, debug); System.setProperty(org.apache.commons.logging.simplelog.log.org.apache.commons.httpclient, debug); Thanks, Zulfi [EMAIL PROTECTED] 10/8/2004 1:25:07 PM Zulfi, My only guess is that this is a thread synchronization related problem, as the problem appears to be irregular. How do you set the request body? As an InputStream? How do you set the content length? Explicitly or as CONTENT_LENGTH_AUTO? Can it be that the input stream is exhausted before HttpClient has a chance to send its content across the wire? Can you send me the context/wire log for the HTTP transaction in question? Oleg On Fri, 2004-10-08 at 22:10, Zulfi Umrani wrote: Hi Oleg, Yes, the connection is closed by the server. But it is closed because the HttpClient did not send it the request BODY. The problem is that occasionally HttpClient does not send the request as I described. For a few times, it does send the request and then it just doesnt send it, but only once. And then it is back to sending request body. The server tries to read the body but can not, hence it closes the connection for the reuqest which had no body and had Content-Length header value 1. I have sent you the reuqest in error from the tunnel. Looks like it sent the Content-Length header, but not the body of the request. Hope this helps, Zulfi [EMAIL PROTECTED] 10/8/2004 12:46:04 PM Zulfi HttpRecoverableException: Software caused connection abort: recv failed usually means that the connection was closed on the server side while HttpClient was still reading the response. The is more likely to be the server side problem. What exactly do you mean by occasionally HttpClient does not send the request body. Does it throw an exception, or blocks, or something else? Oleg On Fri, 2004-10-08 at 19:53, Zulfi Umrani wrote: I am getting the following exception for redirect responses from HttpClient. Attached is the log from HttpClient. I know that HttpClient does not support redirect directly, hence we have written some code to handle that. The problem seems to be that, occasionally HttpClient does not send the request body though it writes out the Content-Length header. If you send the same request one after another by starting a new JVM for each request, such as running a client from commandline, you will see that, it sends the request body for a few times and then it does not send it once and then it starts to send it again. This behavior keeps repeating. Below is the request sent out by HttpClient and response received by it, captured through a tunnel. I will appreciate if someone can explain the behavior. Exception in thread main java.rmi.RemoteException: java.net.SocketException: S oftware caused connection abort: recv failed; nested exception is: org.apache.commons.httpclient.HttpRecoverableException: java.net.SocketE xception: Software caused connection abort: recv failed at com.sssw.jbroker.web.ServiceException.mapToRemote(ServiceException.ja va:92) at hello.HelloBinding_Stub.sayHello(HelloBinding_Stub.java:85) at hello.Client.main(Client.java:25) Caused by: org.apache.commons.httpclient.HttpRecoverableException: java.net.Sock etException: Software caused connection abort: recv failed at
[PATCH] ChunkedInputStream no longer requires an HttpMethod parameter
Folks, I would like to make ChunkedInputStream a little more reusable by making HttpMethod parameter optional. Please let me know if you agree/disagree Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. ***Index: ChunkedInputStream.java === RCS file: /home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/ChunkedInputStream.java,v retrieving revision 1.22 diff -u -r1.22 ChunkedInputStream.java --- ChunkedInputStream.java 18 Apr 2004 23:51:34 - 1.22 +++ ChunkedInputStream.java 8 Oct 2004 14:15:54 - @@ -49,7 +49,7 @@ * not requiring the client to remember to read the entire contents of the * response./p * - * @author Ortwin Gl + * @author Ortwin Glueck * @author Sean C. Sullivan * @author Martin Elwin * @author Eric Johnson @@ -80,33 +80,41 @@ private boolean closed = false; /** The method that this stream came from */ -private HttpMethod method; +private HttpMethod method = null; /** Log object for this class. */ private static final Log LOG = LogFactory.getLog(ChunkedInputStream.class); + /** + * ChunkedInputStream constructor * - * - * @param in must be non-null - * @param method must be non-null + * @param in the raw input stream + * @param method the originating HTTP method. Can be ttnull/tt. * * @throws IOException If an IO error occurs */ public ChunkedInputStream( final InputStream in, final HttpMethod method) throws IOException { - if (in == null) { -throw new IllegalArgumentException(InputStream parameter may not be null); - } - if (method == null) { -throw new IllegalArgumentException(HttpMethod parameter may not be null); - } + if (in == null) { + throw new IllegalArgumentException(InputStream parameter may not be null); + } this.in = in; this.method = method; this.pos = 0; } /** + * ChunkedInputStream constructor + * + * @param in the raw input stream + * + * @throws IOException If an IO error occurs + */ +public ChunkedInputStream(final InputStream in) throws IOException { + this(in, null); +} +/** * p Returns all the data in a chunked stream in coalesced form. A chunk * is followed by a CRLF. The method returns -1 as soon as a chunksize of 0 * is detected./p @@ -301,17 +309,21 @@ private void parseTrailerHeaders() throws IOException { Header[] footers = null; try { -footers = HttpParser.parseHeaders(in, -method.getParams().getHttpElementCharset()); +String charset = US-ASCII; +if (this.method != null) { +charset = this.method.getParams().getHttpElementCharset(); +} +footers = HttpParser.parseHeaders(in, charset); } catch(HttpException e) { LOG.error(Error parsing trailer headers, e); IOException ioe = new IOException(e.getMessage()); ExceptionUtil.initCause(ioe, e); throw ioe; } - -for (int i = 0; i footers.length; i++) { -method.addResponseFooter(footers[i]); +if (this.method != null) { +for (int i = 0; i footers.length; i++) { +this.method.addResponseFooter(footers[i]); +} } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getting through a proxy server
Madeleine, If you activate wire/context logging in your application you'll get more details on what exactly goes wrong http://jakarta.apache.org/commons/httpclient/logging.html If you need help reading the log, feel free to post it to this list. Do obfuscate security sensitive bits such as logon credentials prior to posting. Oleg On Fri, 2004-10-08 at 16:45, Madeleine Wright wrote: Please can someone suggest the simplest way to access a URL programatically through a proxy server? I'm using HttpClient and the proxy bits of my code look like this (everything else works fine - I can access all sites inside the firewall): HttpClient client = new HttpClient(); . client.getHostConfiguration().setProxy(proxyHost, proxyPort); Credentials creds = new UsernamePasswordCredentials(userName, password); client.getState().setProxyCredentials(realm, proxyHost, defaultcreds); ... GetMethod method = new GetMethod(url); I realize I seem to be supplying proxy host details twice! But I can't otherwise see how to set the proxy port? I keep getting an access denied message from the proxy server, indicating that I have not authenticated myself. Does anyone know how I do that other than the method above (I am sure the actual proxy details given are correct). Thanks. Mad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getting through a proxy server
Bob, You are absolutely right about method.getHostConfiguration() taking precedence over client.getHostConfiguration(). However, HttpClient does copy the proxy information from the agent host config to the method host config. So, that should not be the reason for proxy problems Madeleine has been having. We realize this can be horribly confusing. As of release 3.0 the use of HttpMethod#getHostConfiguration() will be deprecated and discouraged Oleg On Fri, 2004-10-08 at 17:01, St Jacques, Robert wrote: I believe that your problem is the fact that by calling the GetMethod(url) constructor, you are creating a method with its own host configuration; in this case, the method's host configuration is used when the method is executed (as opposed to the default host configuration that you have created on the connection). In other words, the host, port, and path information for the specific method invocation are extracted from the URL that you used to construct the GetMethod. If you replace this code: client.getHostConfiguration()... with this code: method.getHostConfiguration()... You should be all set. Either that or call the parameter-less GetMethod constructor, which will cause it to default to the host configuration for your client. OR you could call: client.executeMethod( client.getHostConfiguration(), method, client.getState()) That should work, too. Hope that helps, Bob -Original Message- From: Yuzwa, Erik [mailto:[EMAIL PROTECTED] Sent: Friday, October 08, 2004 10:53 AM To: 'Commons HttpClient Project' Subject: RE: getting through a proxy server Madeleine, Stupid question but is your proxy server using NTLM authentication? I had to do some hoop jumping to get NTLM to work properly, but it's working now if you need some code. Erik -Original Message- From: Madeleine Wright [mailto:[EMAIL PROTECTED] Sent: Friday, October 08, 2004 8:46 AM To: Commons HttpClient Project Subject: getting through a proxy server Please can someone suggest the simplest way to access a URL programatically through a proxy server? I'm using HttpClient and the proxy bits of my code look like this (everything else works fine - I can access all sites inside the firewall): HttpClient client = new HttpClient(); . client.getHostConfiguration().setProxy(proxyHost, proxyPort); Credentials creds = new UsernamePasswordCredentials(userName, password); client.getState().setProxyCredentials(realm, proxyHost, defaultcreds); ... GetMethod method = new GetMethod(url); I realize I seem to be supplying proxy host details twice! But I can't otherwise see how to set the proxy port? I keep getting an access denied message from the proxy server, indicating that I have not authenticated myself. Does anyone know how I do that other than the method above (I am sure the actual proxy details given are correct). Thanks. Mad - 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] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: redirect problem in HttpClient
Zulfi HttpRecoverableException: Software caused connection abort: recv failed usually means that the connection was closed on the server side while HttpClient was still reading the response. The is more likely to be the server side problem. What exactly do you mean by occasionally HttpClient does not send the request body. Does it throw an exception, or blocks, or something else? Oleg On Fri, 2004-10-08 at 19:53, Zulfi Umrani wrote: I am getting the following exception for redirect responses from HttpClient. Attached is the log from HttpClient. I know that HttpClient does not support redirect directly, hence we have written some code to handle that. The problem seems to be that, occasionally HttpClient does not send the request body though it writes out the Content-Length header. If you send the same request one after another by starting a new JVM for each request, such as running a client from commandline, you will see that, it sends the request body for a few times and then it does not send it once and then it starts to send it again. This behavior keeps repeating. Below is the request sent out by HttpClient and response received by it, captured through a tunnel. I will appreciate if someone can explain the behavior. Exception in thread main java.rmi.RemoteException: java.net.SocketException: S oftware caused connection abort: recv failed; nested exception is: org.apache.commons.httpclient.HttpRecoverableException: java.net.SocketE xception: Software caused connection abort: recv failed at com.sssw.jbroker.web.ServiceException.mapToRemote(ServiceException.ja va:92) at hello.HelloBinding_Stub.sayHello(HelloBinding_Stub.java:85) at hello.Client.main(Client.java:25) Caused by: org.apache.commons.httpclient.HttpRecoverableException: java.net.Sock etException: Software caused connection abort: recv failed at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodB ase.java:1965) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMetho dBase.java:2659) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.j ava:1093) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.jav a:675) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.jav a:558) Request going out from HttpClient: POST /services/hello HTTP/1.1 SOAPAction: http://www.hello/sayHello; Content-Type: text/xml; charset=utf-8 Connection: keep-alive User-Agent: Jakarta Commons-HttpClient/2.0final Host: 840serv7:54892 Content-Length: 421 Response received by HttpClient: HTTP/1.1 307 redirected Set-Cookie: dispatch-http-rt=840serv7:80; path=/; Content-Length: 0 Location: http://840serv7:80/services/hello Thanks, Zulfi __ - 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: redirect problem in HttpClient
Zulfi, My only guess is that this is a thread synchronization related problem, as the problem appears to be irregular. How do you set the request body? As an InputStream? How do you set the content length? Explicitly or as CONTENT_LENGTH_AUTO? Can it be that the input stream is exhausted before HttpClient has a chance to send its content across the wire? Can you send me the context/wire log for the HTTP transaction in question? Oleg On Fri, 2004-10-08 at 22:10, Zulfi Umrani wrote: Hi Oleg, Yes, the connection is closed by the server. But it is closed because the HttpClient did not send it the request BODY. The problem is that occasionally HttpClient does not send the request as I described. For a few times, it does send the request and then it just doesnt send it, but only once. And then it is back to sending request body. The server tries to read the body but can not, hence it closes the connection for the reuqest which had no body and had Content-Length header value 1. I have sent you the reuqest in error from the tunnel. Looks like it sent the Content-Length header, but not the body of the request. Hope this helps, Zulfi [EMAIL PROTECTED] 10/8/2004 12:46:04 PM Zulfi HttpRecoverableException: Software caused connection abort: recv failed usually means that the connection was closed on the server side while HttpClient was still reading the response. The is more likely to be the server side problem. What exactly do you mean by occasionally HttpClient does not send the request body. Does it throw an exception, or blocks, or something else? Oleg On Fri, 2004-10-08 at 19:53, Zulfi Umrani wrote: I am getting the following exception for redirect responses from HttpClient. Attached is the log from HttpClient. I know that HttpClient does not support redirect directly, hence we have written some code to handle that. The problem seems to be that, occasionally HttpClient does not send the request body though it writes out the Content-Length header. If you send the same request one after another by starting a new JVM for each request, such as running a client from commandline, you will see that, it sends the request body for a few times and then it does not send it once and then it starts to send it again. This behavior keeps repeating. Below is the request sent out by HttpClient and response received by it, captured through a tunnel. I will appreciate if someone can explain the behavior. Exception in thread main java.rmi.RemoteException: java.net.SocketException: S oftware caused connection abort: recv failed; nested exception is: org.apache.commons.httpclient.HttpRecoverableException: java.net.SocketE xception: Software caused connection abort: recv failed at com.sssw.jbroker.web.ServiceException.mapToRemote(ServiceException.ja va:92) at hello.HelloBinding_Stub.sayHello(HelloBinding_Stub.java:85) at hello.Client.main(Client.java:25) Caused by: org.apache.commons.httpclient.HttpRecoverableException: java.net.Sock etException: Software caused connection abort: recv failed at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodB ase.java:1965) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMetho dBase.java:2659) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.j ava:1093) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.jav a:675) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.jav a:558) Request going out from HttpClient: POST /services/hello HTTP/1.1 SOAPAction: http://www.hello/sayHello; Content-Type: text/xml; charset=utf-8 Connection: keep-alive User-Agent: Jakarta Commons-HttpClient/2.0final Host: 840serv7:54892 Content-Length: 421 Response received by HttpClient: HTTP/1.1 307 redirected Set-Cookie: dispatch-http-rt=840serv7:80; path=/; Content-Length: 0 Location: http://840serv7:80/services/hello Thanks, Zulfi __ - 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: [VOTE] 2.0.2 release
+1 On Wed, 2004-10-06 at 03:48, Michael Becke wrote: After a little delay... I propose that we mark the latest code in CVS HTTPCLIENT_2_0 as 2.0.2 and proceed with a release. Please vote as follows: -- Vote: HttpClient 2.0.2 release [x] +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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Preferences Architecture
Actually the new Preferences Architecture is quite neat and great if it all works. It is only the HostConfiguration that does not work and I would love to figure out why. Vikram, I believe the problem with HostConfiguration has been fixed in CVS HEAD. We'd love to hear from you if now you find the new preferences architecture working as expected. Cheers, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unlocatable exception withinhttpclient.HttpRecoverableException
Jeff, Sometimes, usually when under heavy load, the web server may be able to receive requests but unable to process them due to low resources (most commonly worker threads). In such a case the web server may simply have no other choice but to drop the connection without sending back any status code. This in turn causes HttpClient to throw a HttpRecoverableException unable to find line starting with HTTP Can it be that you have been stressing the server a bit too much? Anyways, usually unable to find line starting with HTTP exception is not a HttpClient fault, but that of the target server. The regrettable thing about it it is a poor choice of exception class name and a misleading error message. (This problem has already been fixed in HttpClient 3.0) Hope this helps a little Oleg On Tue, 2004-10-05 at 08:27, Jeff Fern wrote: Hello all, I am running Tomcat 5.0.27 with Java 1.4.2 on my local machine (Debian sarge). I have a Java webapp running on Tomcat, which outputs XML and I am using Cocoon 2.1 to style the XML with a static XSLT stylesheet to generate HTML. I have managed to generate an bug which occurs about 80% of the time. When I submit a form, cocoon generates one of a couple of errors: org.apache.cocoon.ProcessingException: There is a problem with the URI: http://127.0.0.1:8080/Conference/GetConference?conferenceName=UbiComp%20200 5 http://127.0.0.1:8080/Conference/GetConference?conferenceName=UbiComp%202005 : org.apache.commons.httpclient.HttpRecoverableException: org.apache.commons.httpclient.HttpRecoverableException: Error in parsing the status line from the response: unable to find line starting with HTTP or org.apache.cocoon.ProcessingException: There is a problem with the URI: http://127.0.0.1:8080/Conference/AddDetails http://127.0.0.1:8080/Conference/AddDetails: org.apache.commons.httpclient.HttpRecoverableException: java.net.SocketException: Socket closed Trying to re-submit the same information sometimes displays the correct results, sometimes generates an error. I have enabled logging with log4j using the examples at http://jakarta.apache.org/commons/httpclient/logging.html http://jakarta.apache.org/commons/httpclient/logging.html The only ouput generated in the log file is: - Recoverable exception caught when processing request - Recoverable exception caught but MethodRetryHandler.retryMethod() returned false, rethrowing exception I have also tried my code on Tomcat 5.5 with Java 1.5 and get the exact same results. I am unable to locate any piece of my code that causes this error. Any help or suggestions would be much appreciated, Regards, -Jeff Fern *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.net.SocketException: Connection reset
Pavel, It does seem a little unusual and does appear likely to be a problem on the server side. 'Connection reset' error usually occurs in the following two cases: (1) the server drops the connection on the unsuspecting HttpClient while it is still busy transmitting the request. The most common cause of this problem is an authorization error. Can it be that your application uses invalid credentials? (2) the server fails to send any response due to an internal error and simply drops the connection without sending any status code back to the client I believe that the latter case is more likely than the former, but let's not rule out any possibility. Things to try: (1) Activate so called 'expect-continue' handshake and see if that makes any difference. http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/ExpectContinueMethod.html#setUseExpectHeader(boolean) (2) Consider executing a GET against the url containing the form , get the client authenticated, and only then execute the POST (very much like the browser does) Hope this helps Vsego, Oleg On Sat, 2004-10-02 at 22:30, Skandiska OY wrote: Greeting from Estonia I'm trying to pull data from an online price quotation system using HTTPClient's POST method. SOMETIMES (rather rarely) the thing works, mostly not. Is something really wrong with the server or undesigned goofed in the RTFM stage ? The URL is accessible and the form works fine under my Mozilla browser. Many thanks for your effort Pavel +++ Java prog +++ /* * Created on 26.09.2004 * */ package ee.skandiska.webBotTest; import java.io.*; import org.apache.commons.httpclient.*; import org.apache.commons.httpclient.methods.*; import com.quiotix.html.parser.*; /** * @author Pavel * */ public class rapBot { public void run() { System.setProperty(org.apache.commons.logging.Log, org.apache.commons.logging.impl.SimpleLog); System.setProperty(org.apache.commons.logging.simplelog.showdatetime, true); System.setProperty(org.apache.commons.logging.simplelog.log.httpclient .wire, debug); System.setProperty(org.apache.commons.logging.simplelog.log.org.apache .commons.httpclient, debug); Credentials creds = null; creds = new UsernamePasswordCredentials(sorry, cant_disclose_this); //create a singular HttpClient object HttpClient client = new HttpClient(); //set all timeouts to 20 seconds client.setConnectionTimeout(2); client.setTimeout(2); client.setHttpConnectionFactoryTimeout(2); //set the default credentials if (creds != null) { client.getState(). setCredentials(INDEX Member Area, www.diamonds.net, creds); } String url = http://www.diamonds.net/rapnet/prices/prcwks.asp;; //create a method object PostMethod postMethod = new PostMethod(url); NameValuePair[] data = { new NameValuePair(submit2, Calculate), new NameValuePair(shape, Round), new NameValuePair(size, 1.0), new NameValuePair(color, F), new NameValuePair(clar, VVS1) }; postMethod.setRequestBody(data); postMethod.setFollowRedirects(true); DefaultMethodRetryHandler retryHandler = new DefaultMethodRetryHandler(); retryHandler.setRetryCount(5); retryHandler.setRequestSentRetryEnabled(true); postMethod.setMethodRetryHandler(retryHandler); //execute the method String responseBody = null; try{ int statusCode = client.executeMethod(postMethod); Reader reader = new InputStreamReader(postMethod.getResponseBodyAsStream()); HtmlDocument document = new HtmlParser(reader).HtmlDocument(); document.accept(new HtmlScrubber(HtmlScrubber.DEFAULT_OPTIONS | HtmlScrubber.TRIM_SPACES)); System.out.println(+++ parsed HTML body +++); document.accept(new HtmlDumper(System.out)); reader.close(); // responseBody = postMethod.getResponseBodyAsString(); } catch (HttpException he) { System.err.println(Http error connecting to ' + url + '); System.err.println(he.getMessage()); System.exit(-4); } catch (IOException ioe){ System.err.println(Unable to connect to ' + url + '); System.exit(-3); } catch (ParseException e) { e.printStackTrace(); System.exit(-5); } //write out the request headers System.out.println(*** Request ***); System.out.println(Request Path: + postMethod.getPath()); System.out.println(Request Query: + postMethod.getQueryString()); Header[] requestHeaders = postMethod.getRequestHeaders(); for (int i=0; irequestHeaders.length;
Re: convert usage if URLConnection to HttpClient
Jason, Take a look at the HttpClient tutorial and the authentication guide. That should get you started: http://jakarta.apache.org/commons/httpclient/tutorial.html http://jakarta.apache.org/commons/httpclient/authentication.html Same code can be found here: http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/BasicAuthenticationExample.java?rev=1.1.2.3only_with_tag=HTTPCLIENT_2_0_BRANCHview=markup If all this will not help, let me know Oleg On Sat, 2004-10-02 at 20:16, Jason Novotny wrote: Hi, I had been using some crufty code using URLConnection to perform basic auth to retrieve the list of applications using the Tomcat manager webapp. I'd like to convert this to use commons-httpclient-2.0.1. It should be pretty simple I think-- what is required is to invoke http://127.0.0.1/manager?list performing basic authentication using name and password and then I get back a response which has a specific format. My current code is shown below and I'd like to know what the 3 or 5 magic lines are to do the same thing using HttpClient. Thanks very much, Jason try { String serverName = req.getServerName(); int serverPort = req.getServerPort(); URL u = new URL(http://; + serverName + : + serverPort + /manager + command); URLConnection con = u.openConnection(); String up = USERNAME + : + PASSWORD; String encoding = null; // check to see if sun's Base64 encoder is available. try { sun.misc.BASE64Encoder encoder = (sun.misc.BASE64Encoder) Class.forName(sun.misc.BASE64Encoder).newInstance(); encoding = encoder.encode(up.getBytes()); } catch (Exception ex) { // sun's base64 encoder isn't available throw new TomcatManagerException(No sun.misc.BASE64Encoder availoable in JDK!); } con.setRequestProperty(Authorization, Basic + encoding); con.setDoInput(true); con.setUseCaches(false); con.connect(); if (con instanceof HttpURLConnection) { HttpURLConnection httpConnection = (HttpURLConnection) con; // test for 401 result (HTTP only) if (httpConnection.getResponseCode() == HttpURLConnection.HTTP_UNAUTHORIZED) { throw new TomcatManagerException(HTTP Authorization failure!); } } BufferedReader reader = new BufferedReader(new InputStreamReader(con.getInputStream())); // get first line // should be something like: // OK - some information text String line = null; line = reader.readLine(); StringTokenizer tokenizer = new StringTokenizer(line, -); if (tokenizer.countTokens() == 2) { String rc = tokenizer.nextToken(); String description = tokenizer.nextToken(); result = new TomcatWebAppResult(rc, description); } while ((line = reader.readLine()) != null) { result.addWebAppDescriptor(line); } reader.close(); } catch (IOException e) { throw new TomcatManagerException(Unable to perform command: , e); } - 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: threads problem with many connections
On Fri, 2004-10-01 at 12:57, Guillaume Cottenceau wrote: Hello, We use HttpClient for performing several HTTP post in parallel in our applications. We have a problem when the server(s) receiving our HTTP post either answers very slowly, or goes mad and sends garbage data over and over: the connection stays open forever, but more important, the Java threads as well. We have situations where we reach the maximum of Java threads our (tomcat) application is configured to handle, and our whole application is then unusable. It seems that java.nio is capable of using only one thread for several lowlevel (OS) socket connections, and is actually also quite efficient. Guillaume, Please correct me if my understanding of the problem is incorrect, it is Tomcat that runs out of connections, not HttpClient. In fact, there's only one case when HttpClient spawns a new thread, and if so is desired, this can be disabled. The thread management is entirely responsibility of your application. One does not have to use one thread per socket model even without NIO I have seen that Oleg Kalnichevski has already expressed his views several times on the subject, and I have seen that you want to keep 1.2 compatibility, so java.nio out. http://www.mail-archive.com/[EMAIL PROTECTED]/msg05551.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg06998.html (btw, I don't agree with in my opinion there's absolutely nothing that NIO can bring in in terms of performance to client-side applications - well I agree that pure performance is not the problem but threads and memory consumption surely is - so in my opinion there is a lot to win with java.nio in httpclient) I have done quite a bit of NIO programming lately and respectfully stick to my original opinion. My question is, since you don't want to lose 1.2 compatibility before 4.0, is there then a way to solve a typical too many threads problem such as the one we have? Do you people never had the same problem? Or have found a way to solve it? Feasible approach is to have one monitor thread checking on the status of active connections or/and processing incoming connections, and a number of worker threads in a shared pool to do the actual work. It seems the HTTP protocol doesn't have anything resembling a global timeout for a given connection (e.g. after x seconds, close the receiving channel even if server hasn't finished sending), and thus normally httpclient doesn't provide such a thing. Do you think this should be investigated/implemented in some way? I do not recall HTTP protocol as such dealing with timeouts in any way. I may be wrong, though. This is certainly not a protocol concern. HttpClient does provide so called socket timeout. When set to a positive number, the connection will terminate with an IOException after the specified period of inactivity: http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/HttpClient.html#setTimeout(int) Hope this helps Oleg Thanks, and best regards. *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threads problem with many connections
Feasible approach is to have one monitor thread checking on the status of active connections or/and processing incoming connections, and a number of worker threads in a shared pool to do the actual work. Actually since probably most people using httpclient with many connections would need that, would it make sense to have it shared somewhere, for example in httpclient? I assume you are developing some kind of HTTP proxy, since you have HttpClient running inside a servlet container. While not being entirely impossible (I have one serving a population of a large Swiss canton), HttpClient 2.x and 3.x have not been specifically designed to be used in such a manner. My guts tell me that it might involve quite a few nasty hacks if to be made truly generic and reusable. In my option it is just not worth the trouble and will not bear results generic enough to be useful in most of scenarios. We are planning to embark on a fundamental redesign of HttpClient in a not so distant future (past 3.0b1 I'd say). Our intent is to turn HttpClient into a generic HTTP toolkit which can be used to rapidly assemble HTTP agents, proxies or embedded lightweight servers. At that point we will probably seriously consider using NIO and provide some sort of thread management/connection management classes or use an external library for that end. But first things first, and one thing at a time commons/httpclient/apidocs/org/apache/commons/httpclient/HttpClient.html#setTimeout(int) Yes, we're already using that (and connection timeouts as well). We're just in trouble when the post never finishes, but actually the server is very slow (if it sends one byte per second for example, but on a regular basis) or goes mad. Basically what you are talking about is ability to abort execution of HTTP methods. Consider using HttpClient 3.0a2 which provides such capability. You'll have to add a little code to handle timing of method execution, which should not be that difficult Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threads problem with many connections
Is it considered safe to interrupt the execute task that way? Is method.releaseConnection() the way to go for full cleanup of underlying resources, or the interruption might leave things in a bad state? There's no definitive answer to this question. TimeoutController does not actually interrupt the method execution. All is does is leaving the client object at the mercy of garbage collector. The client may linger in the memory until the second coming or get GCed in a reasonable amount of time. The exact behaviour is unfortunately JRE specific. Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ATTN Open-source projects using HttpClient
Hi St.Ack, Your feedback is really appreciated. I am quite happy that we now have one less development list to spam ;) See my comments inline The upgrade took way longer than I anticipated, a couple of days rather than a couple of hours. While some of the time was spent on refactoring only slightly related to the httpcilent upgrade and testing to see all httpclient used features still work post upgrade, the bulk of the time was spent on redoing our auth system to fit the redesigned httpclient auth system. I had trouble figuring out how things work now in the absence of example. Our usage is a little out-of-the-ordinary in that we manage own store of credentials and manage when to load them onto a httpmethod. Previous, HttpAuthenticator would select the scheme for me. Now it seems like I have to do it myself using AuthChallengeParser and then iterate over the returns. In general the new auth system changes look to be for the best. I am not sure if that's going to be of help in your particular case, I just want to note that one may replace the standard authentication schemes with custom ones and provide additional custom schemes, if so is desired: http://jakarta.apache.org/commons/httpclient/3.0/authentication.html#Custom%20authentication%20scheme The IBM SSL socket timeout issues I'm seeing when I get an SSLSocket with a timeout (I set the timeout by getting a socket with the null arg constructor then doing an SSLSocket$connect with a timeout). The exceptions do not happen when I use SUN JVM 1.4.2. These are probably IBM JVM issues but I'll list them here anyways: 1. The IBM JVM 141 (cxia321411-20030930) NPEs setting the NoTcpDelay. Is anyone else seeing this? java.lang.NullPointerException at com.ibm.jsse.bf.setTcpNoDelay(Unknown Source) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:683) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1328) 2. Using the IBM JVM 142, its saying SSL connection not open when we go to use inputstreams. java.net.SocketException: Socket is not connected at java.net.Socket.getInputStream(Socket.java:726) at com.ibm.jsse.bs.getInputStream(Unknown Source) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:715) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1328) We have already had a few reports regarding IBM JSSE semantical incompatibilities with Sun JSSE. It appears IBM JSSE implementation unlike Sun's does not like attempts to set socket parameters when the socket is closed. I believe it is clearly a bug in IBM JSSE but we can think of working it around in HttpClient. By way of feedback on the 3.0 API, I'll describe the two places where the API is lacking regards our requirements forcing us to do yucky overlays. First some context. The crawler must record the response headers and response content exactly as it comes back over the wire and its supposed to be tenacious. Regards recording exactly what the server sent us, we overlay HttpConnection with a version that wraps the socket input and output streams. Here's the diff: +// HERITRIX import. +import org.archive.util.HttpRecorder; + /** * An abstraction of an HTTP [EMAIL PROTECTED] InputStream} and [EMAIL PROTECTED] OutputStream} * pair, together with the relevant attributes. @@ -676,7 +679,6 @@ highly interactive environments, such as some client/server situations. In such cases, nagling may be turned off through use of the TCP_NODELAY sockets option. */ - socket.setTcpNoDelay(this.params.getTcpNoDelay()); socket.setSoTimeout(this.params.getSoTimeout()); @@ -701,8 +703,23 @@ if (inbuffersize 2048) { inbuffersize = 2048; } -inputStream = new BufferedInputStream(socket.getInputStream(), inbuffersize); -outputStream = new BufferedOutputStream(socket.getOutputStream(), outbuffersize); +// START HERITRIX Change +HttpRecorder httpRecorder = HttpRecorder.getHttpRecorder(); +if (httpRecorder == null) { +inputStream = new BufferedInputStream( +socket.getInputStream(), inbuffersize); +outputStream = new BufferedOutputStream( +socket.getOutputStream(), outbuffersize); +} else { +inputStream = httpRecorder.inputWrap((InputStream) +(new BufferedInputStream(socket.getInputStream(), +inbuffersize))); +outputStream = httpRecorder.outputWrap((OutputStream) +(new BufferedOutputStream(socket.getOutputStream(), +
RE: HttpClient + HTTPS + NTLM Authentication = HTTP/1.1 401AccessDenied
: keystone.ibanksystems.com [\r][\n] 2004/09/30 10:05:34:042 CDT [DEBUG] header - Expect: 100-continue[\r][\n] 2004/09/30 10:05:34:042 CDT [DEBUG] header - Content-Type: multipart/form-da ta; boundary=314159265358979323846[\r][\n] 2004/09/30 10:05:34:042 CDT [DEBUG] header - [\r][\n] 2004/09/30 10:05:34:072 CDT [DEBUG] header - HTTP/1.1 100 Continue[\r][\n] 2004/09/30 10:05:34:072 CDT [DEBUG] header - Server: Microsoft-IIS/5.0[\r][\ n] 2004/09/30 10:05:34:072 CDT [DEBUG] header - Date: Thu, 30 Sep 2004 15:05:30 GMT[\r][\n] 2004/09/30 10:05:34:072 CDT [DEBUG] header - IISExport: This web site was ex ported using IIS Export v3.0[\r][\n] 2004/09/30 10:05:34:072 CDT [DEBUG] HttpMethodBase - OK to continue received 2004/09/30 10:05:34:122 CDT [DEBUG] header - HTTP/1.1 200 OK[\r][\n] 2004/09/30 10:05:34:122 CDT [DEBUG] header - Server: Microsoft-IIS/5.0[\r][\ n] 2004/09/30 10:05:34:122 CDT [DEBUG] header - Date: Thu, 30 Sep 2004 15:05:30 GMT[\r][\n] 2004/09/30 10:05:34:122 CDT [DEBUG] header - IISExport: This web site was ex ported using IIS Export v3.0[\r][\n] 2004/09/30 10:05:34:122 CDT [DEBUG] header - Content-Length: 2878[\r][\n] 2004/09/30 10:05:34:122 CDT [DEBUG] header - Content-Type: text/html[\r][\n] 2004/09/30 10:05:34:122 CDT [DEBUG] header - Set-Cookie: ASPSESSIONIDACQABDQ S=OPDPAAPBNOGEOCJAHGNLNBKC; path=/[\r][\n] 2004/09/30 10:05:34:122 CDT [DEBUG] header - Cache-control: private[\r][\n] 2004/09/30 10:05:34:142 CDT [DEBUG] HttpMethodBase - Cookie accepted: $Version= 0; ASPSESSIONIDACQABDQS=OPDPAAPBNOGEOCJAHGNLNBKC; $Path=/ Status Line: HTTP/1.1 200 OK Status Code: 200 2004/09/30 10:05:34:142 CDT [DEBUG] HttpMethodBase - Resorting to protocol versi on default close connection policy 2004/09/30 10:05:34:142 CDT [DEBUG] HttpMethodBase - Should NOT close connection , using HTTP/1.1 2004/09/30 10:05:34:142 CDT [DEBUG] HttpConnection - Releasing connection back t o connection manager. Press any key to continue . . . Please reply at your earliest convenience. Chris -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 29, 2004 5:10 PM To: Commons HttpClient Project Subject: RE: HttpClient + HTTPS + NTLM Authentication = HTTP/1.1 401AccessDenied Christopher, Ok, I see. This is weird. I can't explain it. Maybe I am just too tired right now and should go to bed. Actually it is preferred to not do a POST against a protected URL. One should do a GET or a HEAD first, get authenticated, get a session cookie, and than do a POST. Another thing to try is turning on 'expect: continue' handshake http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/ httpclient/methods/ExpectContinueMethod.html#setUseExpectHeader(boolean) Oleg On Wed, 2004-09-29 at 23:59, Burke, Christopher wrote: Oleg, Thanks for your prompt response. The main problem is that the file has not been uploaded, but the return code is 200. I am trying to post the File object 'f' to the 'F1' textbox in the following form (File f = new File(C:/secureHttp/anotherLog.log);). I believe my code is correct. I am at a loss. What could be the problem? FORM ENCTYPE=multipart/form-data METHOD=POST ACTION=siteman.asp?u=Dd=c:\im\ FONT SIZE=1 FACE=Arial, Helvetica, sans-serifNAME OF DESTINATION FOLDER ON WEB SITE/FONTBR FONT SIZE=4 FACE=Arial, Helvetica, sans-serifBc:\im\/B/FONTP FONT SIZE=1 FACE=Arial, Helvetica, sans-serifPATHNAME OF LOCAL DOCUMENTBR(SEND THIS FILE TO THE WEB SERVER)/FONTBRINPUT SIZE=30 TYPE=FILE NAME=F1P INPUT TYPE=SUBMIT VALUE=UPLOAD nbsp; INPUT TYPE=SUBMIT NAME=POSTACTION VALUE=CANCEL PFONT SIZE=2 FACE=Arial, Helvetica, sans-serifIf the B[BROWSE...]/B button is not displayed, BRyou must upgrade your A HREF=http://www.netscape.com;Netscape/A or A HREF=http://www.microsoft.com;Microsoft/A browser. /FORM/ Thanks again for your help, Oleg. Christopher -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 29, 2004 4:29 PM To: Commons HttpClient Project Subject: Re: HttpClient + HTTPS + NTLM Authentication = HTTP/1.1 401Access Denied Christopher, What is exactly the problem? The authentication succeeded: HTTP/1.1 200 OK Session cookie has been sent: ASPSESSIONIDAQQBDABR=LMNNMHNALPPKIBENMNNANHGP NTLM authentication scheme is a stateful one and requires multiple challenges/responses. The first 401 Access Denied response is perfectly OK. For details see: http://davenport.sourceforge.net/ntlm.html WARNING: contains utter insanity ;-) Oleg On Wed, 2004-09-29 at 23:10, Burke, Christopher wrote: All, I need help implementing a Commons HttpClient solution to post files to a web server via an ASP page. This seems somewhat straightforward, but I am having trouble with the NTLM
Re: ATTN Open-source projects using HttpClient
That'd be grand if its possible (We like the IBM JVMs' speed and more detailed thread dumps). We used to subclass httpclient so we could do the below, moving the setting of the timeout till after the open. HttpClient 3.0 now sets timeout, etc., after the open seemingly so our subclass is no longer necessary (Hurray!). St.Ack, Could you retest HttpClient 3.0a3 with IBM JRE and let us know if the problem still persists? HttpRecorder duplicates all sent and received to files on disk. It wraps the (buffered) socket streams with input/output streams that do the duplication. Subsequently, the file is fed to a set of processors to with as they wilt. Link extraction is main task performed by processors. We need to record what was sent over the wire preserving order and all bytes sent back and forth (We're trying to archive the web). If there's a less intrusive way of getting what we need, we'd love to hear of it. One possibility would be some thing like that: public class HeritixMethod extends GetMethod { class HeritixConnectionWrapper extends HttpConnection { ... } public int execute(HttpState state, HttpConnection conn) throws HttpException, IOException { return super.execute(state, new HeritixConnectionWrapper(conn)); } } It's ugly but should prevent you from having to patch HttpClient. A better solution would be a pluggable HttpConnection implementation. This will have to wait until 4.0, though Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Preferences Architecture
Probably that's not the way it is supposed to be. I'll see what can be done about it. Oleg On Wed, 2004-09-29 at 11:53, Ortwin Glck wrote: Vikram Goyal wrote: Hello, I am not sure if this is a bug or I am not running this right. I am trying to get the preferences architecture to modify the http.useragent property at the client level, and then retrieve the value at the method and host level. The value gets percolated down to the Method level but the Host level value does not change and gives the global value. See code below. As per the 3.0 B2 documentation, the Method and Host params should try and retrieve the value of the http.useragent from their local cache, and if it they do not find it, should go up the heirarchy, till they reach the global params. Since in the code below, the value is set at the Client level, one lower than the Global level, it should be retrieved from the Client level for both Method and Host params. Vikram, please ignore my first post. The problem is, that HttpClient creates a new HostConfiguration object internally and sets default on that. So your original object is not modified. So within HttpClient the host configuration will use the right user agent string. But you can not see this from the outside. This is line 389 in HttpClient.java (HEAD): HostConfiguration methodConfiguration = new HostConfiguration(hostConfiguration); Ortwin Glck *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Preferences Architecture
Vikram, I hope what is to follow will clarify things a little (1) === HostConfiguration host = new HostConfiguration(); host.setHost(www.google.com); === These are the defaults that apply only when some host parameters have not been explicitly defined by the method itself. Thus, they are not supposed to mutate as a result of method execution Consider the following: === HttpClient client = new HttpClient(); HostConfiguration hostconfig = new HostConfiguration(); hostconfig.setHost(www.mycompnany.com); HttpMethod httpget = new GetMethod(http://www.anothercompnany.com/;); client.executeMethod(hostconfig, httpget); === I assume you'd still want this method to be executed against http://www.anothercompnany.com/ not http://www.mycompnany.com/, right? So, if you want to know the exact host parameters applied during the method execution, you should call === method.getHostConfguration().getParams().getParameter(http.useragent)); === Please let me know if that sounds reasonable/unreasonable (2) All this said, I have to admit that current host configuration related code is a horrible mess. I will provide a refactoring patch shortly Hope this helps Oleg On Wed, 2004-09-29 at 11:14, Vikram Goyal wrote: Hello, I am not sure if this is a bug or I am not running this right. I am trying to get the preferences architecture to modify the http.useragent property at the client level, and then retrieve the value at the method and host level. The value gets percolated down to the Method level but the Host level value does not change and gives the global value. See code below. As per the 3.0 B2 documentation, the Method and Host params should try and retrieve the value of the http.useragent from their local cache, and if it they do not find it, should go up the heirarchy, till they reach the global params. Since in the code below, the value is set at the Client level, one lower than the Global level, it should be retrieved from the Client level for both Method and Host params. Regards, Vikram import org.apache.commons.httpclient.HttpClient; import org.apache.commons.httpclient.methods.GetMethod; import org.apache.commons.httpclient.HostConfiguration; public class HttpClientTest { public static void main(String args[]) throws Exception { HttpClient client = new HttpClient(); client.getParams().setParameter(http.useragent, My Browser); // set the value here HostConfiguration host = new HostConfiguration(); host.setHost(www.google.com); GetMethod method = new GetMethod(/); int returnCode = client.executeMethod(host, method); System.err.println(User-Agent: + host.getParams().getParameter(http.useragent)); // does not print My Browser System.err.println(User-Agent: + method.getParams().getParameter(http.useragent)); // prints My Browser method.releaseConnection(); } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Preferences Architecture
I am testing the new Preferences Architecture before writing about it in a Book that I am working on. I have spent the whole of today looking at the source code but could not locate the problem, so it is bugging me now. It makes sense, the architecture I mean, but it is just not working right for the HostConfiguration. Vikram, That is why HttpClient 3.0 is still ALPHA. We are grateful to you for experimenting with the preferences architecture and giving us the feedback. I agree HostConfiguration stuff is ugly and am working on fixing it right now Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2.0.2 release
+1 On Wed, 2004-09-29 at 14:19, Michael Becke wrote: I propose that we mark the latest code in CVS HTTPCLIENT_2_0 as 2.0.2 and proceed with a release. Please vote as follows: -- Vote: HttpClient 2.0.2 release [x] +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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Preferences Architecture
Actually the new Preferences Architecture is quite neat and great if it all works. It is only the HostConfiguration that does not work and I would love to figure out why. Vikram, Basically it appears that (1) we assume it should work one way, (2) whereas you assume it should work quite the other way around, (3) and on top of that the Hostconfiguration code appears broken. ;-) As soon as we all agree to how exactly things are supposed to work, I'll fix the code and everything should go back to normal. So, please bear with us for a while, and keep on giving us feedback. I'll do my best to have the first take on the fix done by the end of the day. Cheers, 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: streaming responses
Bob, There's no special magic involved. Make sure you use HttpMethod#getResponseBodyAsStream, which will return the raw input stream, and not its buffering counterparts HttpMethod#getResponseBodyAsString and HttpMethod#getResponseBody. You should not worry about chunking. HttpClient will decode chunked input on fly, if necessary. Just grab the raw input stream and do whatever response retrieval suits your application best. Hope this helps Oleg On Wed, 2004-09-29 at 20:43, St Jacques, Robert wrote: Howdy, I've just started using HttpClient for testing. The product that I am developing includes a software download feature that downloads (sometimes very large) files over the internet using HTTP. The reason we use HTTP is that many of our customers are unwilling to open their proxies or firewalls to other protocols. In order to accommodate these downloads, we must either be able to stream the response to a GET, or we need to be able to insure that the response we get from the server will be chunked in such a way that the chunks are small enough to buffer. I know that HttpClient supports chunking, but I am unable to 'force' our web server to chunk up the data. Furthermore, the HTTP 1.1 RFC indicates that the server does not need to guarantee that a response, even if chunked, will be small enough to conveniently buffer on the client. What is the best way to use HttpClient to retrieve large amounts of data (as large as 200 MB or more)? Thanks, Bob St. Jacques Member Research Technical Staff Xerox Corp. (585)231-8306 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: streaming responses
Bob, Buffering response body message is written ONLY inside getResponseBody, which in its turn uses getResponseBodyAsStream. See for yourself: http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/HttpMethodBase.html#681 It means what there's a bit of code in your application that calls getResponseBody or getResponseBodyAsString methods, which causes the buffering of the response body. getResponseBodyAsStream does reconstruct the input stream in case the response has been already buffered, but per default it returns the raw input stream, when available. Feel free to examine the source: http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/HttpMethodBase.html#709 What would HttpClient be worth if it always buffered the response body? I have no idea what led you to believe that processResponseHeaders method buffers the response. The method is even called processResponseHeaders not processResponseBody or something Here's what processResponseBody method does: (1) Gets the raw input stream from the connection http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/HttpMethodBase.html#2014 (2) If the chunk-encoding is used, wraps it with ChunkedInputStream. No buffering http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/HttpMethodBase.html#2038 (3) If Content-Length header is used, wraps it with ContentLengthInputStream, which basically ensures that content will not be read past its length. No buffering http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/HttpMethodBase.html#2072 (4) If there's anything wrong with either Transfer-Encoding or Content-Length header, it just leaves the raw input stream alone. No buffering (5) Finally it attaches a AutoCloseInputStream to the resultant input stream, which is intended to close the underlying connection once the entire response is consumed. No buffering. (6) Keeps the resultant input stream. http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/HttpMethodBase.html#1979 (7) Now, if getResponseBodyAsStream is called, it will simply return the input stream without any further manipulations: http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/HttpMethodBase.html#710 (8) End of story Hope this clarifies things a bit Oleg On Wed, 2004-09-29 at 21:17, St Jacques, Robert wrote: Oleg, This is exactly what I tried to do, but the HttpClient seems to buffer the response anyway. I poked through the code a bit, and did some searching on the mailing list, and this seems to be the case. Also, when I run tests, the log output from the HttpClient seems to indicate that the request is being buffered before I even get an opportunity to call getResponseBodyAsStream. I tried this on a request that is about 17 MB and just sat back and watched as the response was buffered; I ended up terminating the program after a minute or two without ever actually getting past the execute method call. Here is the output from the logs: enter HttpMethodBase.processResponseHeaders(HttpState, HttpConnection) enter GetMethod.readResponseBody(HttpState, HttpConnection) enter HttpMethodBase.readResponseBody(HttpState, HttpConnection) enter HttpMethodBase.readResponseBody(HttpState, HttpConnection) enter HttpConnection.getResponseInputStream() Buffering response body lots of logs detailing the bytes read From here it looks like the processResponseHeaders method (which is called by the HttpMethodBase during an execute) automatically buffers the response. Is this true, or am I totally misreading the signs? Thanks, Bob -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 29, 2004 3:04 PM To: Commons HttpClient Project Subject: Re: streaming responses Bob, There's no special magic involved. Make sure you use HttpMethod#getResponseBodyAsStream, which will return the raw input stream, and not its buffering counterparts HttpMethod#getResponseBodyAsString and HttpMethod#getResponseBody. You should not worry about chunking. HttpClient will decode chunked input on fly, if necessary. Just grab the raw input stream and do whatever response retrieval suits your application best. Hope this helps Oleg On Wed, 2004-09-29 at 20:43, St Jacques, Robert wrote: Howdy, I've just started using HttpClient for testing. The product that I am developing includes a software download feature that downloads (sometimes very large) files over the internet using HTTP. The reason we use HTTP is that many of our customers are unwilling to open their proxies or firewalls to other protocols. In order to accommodate these downloads, we must either be able to stream the response to a GET, or we need to be able to insure that the response we get from the server will be chunked
RE: streaming responses
Damn, I have almost beaten Leo Tolstoy's War and Peace and it turned out just that ;-) On Wed, 2004-09-29 at 22:01, St Jacques, Robert wrote: Sure enough, this is the case; I was calling getResponseBody deep in my code. Thanks for helping me find it ;) -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 29, 2004 3:56 PM To: Commons HttpClient Project Subject: RE: streaming responses Bob, Buffering response body message is written ONLY inside getResponseBody, which in its turn uses getResponseBodyAsStream. See for yourself: http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpcli ent/HttpMethodBase.html#681 It means what there's a bit of code in your application that calls getResponseBody or getResponseBodyAsString methods, which causes the buffering of the response body. getResponseBodyAsStream does reconstruct the input stream in case the response has been already buffered, but per default it returns the raw input stream, when available. Feel free to examine the source: http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpcli ent/HttpMethodBase.html#709 What would HttpClient be worth if it always buffered the response body? I have no idea what led you to believe that processResponseHeaders method buffers the response. The method is even called processResponseHeaders not processResponseBody or something Here's what processResponseBody method does: (1) Gets the raw input stream from the connection http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpcli ent/HttpMethodBase.html#2014 (2) If the chunk-encoding is used, wraps it with ChunkedInputStream. No buffering http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpcli ent/HttpMethodBase.html#2038 (3) If Content-Length header is used, wraps it with ContentLengthInputStream, which basically ensures that content will not be read past its length. No buffering http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpcli ent/HttpMethodBase.html#2072 (4) If there's anything wrong with either Transfer-Encoding or Content-Length header, it just leaves the raw input stream alone. No buffering (5) Finally it attaches a AutoCloseInputStream to the resultant input stream, which is intended to close the underlying connection once the entire response is consumed. No buffering. (6) Keeps the resultant input stream. http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpcli ent/HttpMethodBase.html#1979 (7) Now, if getResponseBodyAsStream is called, it will simply return the input stream without any further manipulations: http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpcli ent/HttpMethodBase.html#710 (8) End of story Hope this clarifies things a bit Oleg On Wed, 2004-09-29 at 21:17, St Jacques, Robert wrote: Oleg, This is exactly what I tried to do, but the HttpClient seems to buffer the response anyway. I poked through the code a bit, and did some searching on the mailing list, and this seems to be the case. Also, when I run tests, the log output from the HttpClient seems to indicate that the request is being buffered before I even get an opportunity to call getResponseBodyAsStream. I tried this on a request that is about 17 MB and just sat back and watched as the response was buffered; I ended up terminating the program after a minute or two without ever actually getting past the execute method call. Here is the output from the logs: enter HttpMethodBase.processResponseHeaders(HttpState, HttpConnection) enter GetMethod.readResponseBody(HttpState, HttpConnection) enter HttpMethodBase.readResponseBody(HttpState, HttpConnection) enter HttpMethodBase.readResponseBody(HttpState, HttpConnection) enter HttpConnection.getResponseInputStream() Buffering response body lots of logs detailing the bytes read From here it looks like the processResponseHeaders method (which is called by the HttpMethodBase during an execute) automatically buffers the response. Is this true, or am I totally misreading the signs? Thanks, Bob -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 29, 2004 3:04 PM To: Commons HttpClient Project Subject: Re: streaming responses Bob, There's no special magic involved. Make sure you use HttpMethod#getResponseBodyAsStream, which will return the raw input stream, and not its buffering counterparts HttpMethod#getResponseBodyAsString and HttpMethod#getResponseBody. You should not worry about chunking. HttpClient will decode chunked input on fly, if necessary. Just grab the raw input stream and do whatever response retrieval suits your application best. Hope this helps Oleg On Wed
Re: ATTN Open-source projects using HttpClient
Eric, The intention is to keep HttpClient 3.0 compile-compatible with HttpClient 2.x (except for all that ugly stuff that has been deprecated in 2.0). Feel free to submit a patch for the HttpException class. Keep us posted on the progress Cheers, Oleg On Wed, 2004-09-29 at 21:10, Eric Johnson wrote: Some feedback, finally. I attempted to compile the client tools of the slide project with the HttpClient 3.0 alpha release. You'll probably not be surprised to hear that it didn't compile. It turns out that a few missing functions in the HttpException class cause the compile failures. I added those few functions in to my local copy, and everything compiled. The code that I have that runs on top of those libraries also compiled without any further changes. I didn't actually run any of the code, though. I suspect that the changes in exception handling would make any such endeavors more work than I want to tackle right now. I think my next step is to ask that the client libraries of the Slide project start using different version numbers from the server side tools, and then suggest a 3.0 release of the slide client libraries that will use the 3.0 HttpClient. Since getting it to compile was easy, I suspect that the rest of it will be fairly straightforward too. -Eric. Oleg Kalnichevski wrote: As far as I know the following projects rely on HttpClient 2.0 as a required or optional dependency * Apache Jakarta Slide (http://jakarta.apache.org/slide/) * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/) * Apache Axis (http://ws.apache.org/axis/) * Apache XML-RPC (http://ws.apache.org/xmlrpc/) * Spring Framework (http://www.springframework.org/) * HtmlUntit (http://htmlunit.sourceforge.net/) * XINS (http://xins.sourceforge.net/) I just wonder if any of the projects' committers are currently subscribed to or monitor this mail list? We would love to know if there are any plans to evaluate HttpClient 3.0, or any migration plans already. What can we do to make the transition, if planned, easier? 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Concurrent requests to same host
Please clarify the following. 1) Do I need to instantiate HttpClient only once? (using Singleton). You should. There's nothing wrong with having multiple HttpClient instances, but we generally recommend having only a single one 2) Can I use MultiThreadedHttpConnectionManager in this scenario? Since I'm hitting only same host all the time, I do not know how to use this. Could you please give an example. (I want concurrent user requests executed in multi threading manner. ) You must. SimpleHttpConnectionManager used per default is NOT thread-safe. Regardless how many hosts you intent to hit, you have to use MultiThreadedHttpConnectionManager when accessing HttpClient from multiple threads. For details refer to the HttpClient multithreading guide: http://jakarta.apache.org/commons/httpclient/threading.html Hope this helps Oleg Thank you, Vijay - 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: HttpClient + HTTPS + NTLM Authentication = HTTP/1.1 401 Access Denied
Christopher, What is exactly the problem? The authentication succeeded: HTTP/1.1 200 OK Session cookie has been sent: ASPSESSIONIDAQQBDABR=LMNNMHNALPPKIBENMNNANHGP NTLM authentication scheme is a stateful one and requires multiple challenges/responses. The first 401 Access Denied response is perfectly OK. For details see: http://davenport.sourceforge.net/ntlm.html WARNING: contains utter insanity ;-) Oleg On Wed, 2004-09-29 at 23:10, Burke, Christopher wrote: All, I need help implementing a Commons HttpClient solution to post files to a web server via an ASP page. This seems somewhat straightforward, but I am having trouble with the NTLM authentication. Code Snippet: String url = https://keystone.ibanksystems.com/carlsontest/siteman.asp?u=Yd=c:\\im\ \; NTCredentials creds = new NTCredentials(user,password,keystone.ibanksystems.com,domain); HttpClient client = new HttpClient(); MultipartPostMethod mpPostMethod = new MultipartPostMethod(url); client.getState().setCredentials(null, null, creds); File f = new File(C:/secureHttp/anotherLog.log); //mpPostMethod.addParameter(F1,f.getName(),f); mpPostMethod.addParameter(F1,f); int statusCode = client.executeMethod(mpPostMethod); System.out.println(Status Line: + mpPostMethod.getStatusLine()); System.out.println(Status Code: + statusCode); mpPostMethod.releaseConnection(); Debug Output: 2004/09/29 15:53:44:425 CDT [DEBUG] HttpClient - Java version: 1.4.2_05 2004/09/29 15:53:44:425 CDT [DEBUG] HttpClient - Java vendor: Sun Microsystems I nc. 2004/09/29 15:53:44:425 CDT [DEBUG] HttpClient - Java class path: .;..;C:\j2sdk1 .4.2_05\bin;C:\apacheCommons\commons-httpclient.jar;C:\apacheCommons\com mons-log ging-api.jar;C:\apacheCommons\commons-logging.jar;C:\apacheCommons\commo ns-codec -1.3.jar 2004/09/29 15:53:44:425 CDT [DEBUG] HttpClient - Operating system name: Windows XP 2004/09/29 15:53:44:425 CDT [DEBUG] HttpClient - Operating system architecture: x86 2004/09/29 15:53:44:425 CDT [DEBUG] HttpClient - Operating system version: 5.1 2004/09/29 15:53:44:565 CDT [DEBUG] HttpClient - SUN 1.42: SUN (DSA key/paramete r generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection Ce rtStores) 2004/09/29 15:53:44:565 CDT [DEBUG] HttpClient - SunJSSE 1.42: Sun JSSE provider (implements RSA Signatures, PKCS12, SunX509 key/trust factories, SSLv3, TLSv1) 2004/09/29 15:53:44:565 CDT [DEBUG] HttpClient - SunRsaSign 1.42: SUN's provider for RSA signatures 2004/09/29 15:53:44:565 CDT [DEBUG] HttpClient - SunJCE 1.42: SunJCE Provider (i mplements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC-MD5, HMAC-SH A1) 2004/09/29 15:53:44:565 CDT [DEBUG] HttpClient - SunJGSS 1.0: Sun (Kerberos v5) 2004/09/29 15:53:45:857 CDT [DEBUG] HttpConnection - HttpConnection.setSoTimeout (0) 2004/09/29 15:53:45:857 CDT [DEBUG] HttpMethodBase - Execute loop try 1 2004/09/29 15:53:45:857 CDT [DEBUG] header - POST /carlsontest/siteman.asp?u =Yd=c:\im\ HTTP/1.1[\r][\n] 2004/09/29 15:53:45:857 CDT [DEBUG] HttpMethodBase - Adding Host request header 2004/09/29 15:53:45:867 CDT [DEBUG] header - User-Agent: Jakarta Commons-Htt pClient/2.0.1[\r][\n] 2004/09/29 15:53:45:867 CDT [DEBUG] header - Host: keystone.ibanksystems.com [\r][\n] 2004/09/29 15:53:45:867 CDT [DEBUG] header - Content-Length: 965[\r][\n] 2004/09/29 15:53:45:867 CDT [DEBUG] header - Content-Type: multipart/form-da ta; boundary=314159265358979323846[\r][\n] 2004/09/29 15:53:46:037 CDT [DEBUG] header - [\r][\n] 2004/09/29 15:53:46:107 CDT [DEBUG] header - HTTP/1.1 401 Access Denied[\r][ \n] 2004/09/29 15:53:46:107 CDT [DEBUG] header - Server: Microsoft-IIS/5.0[\r][\ n] 2004/09/29 15:53:46:107 CDT [DEBUG] header - Date: Wed, 29 Sep 2004 20:53:50 GMT[\r][\n] 2004/09/29 15:53:46:107 CDT [DEBUG] header - WWW-Authenticate: Negotiate[\r] [\n] 2004/09/29 15:53:46:107 CDT [DEBUG] header - WWW-Authenticate: NTLM[\r][\n] 2004/09/29 15:53:46:107 CDT [DEBUG] header - Connection: close[\r][\n] 2004/09/29 15:53:46:107 CDT [DEBUG] header - Content-Length: 4431[\r][\n] 2004/09/29 15:53:46:107 CDT [DEBUG] header - Content-Type: text/html[\r][\n] 2004/09/29 15:53:46:107 CDT [DEBUG] HttpMethodBase - Authorization required 2004/09/29 15:53:46:117 CDT [DEBUG] HttpAuthenticator - Authenticating with the default authentication realm at keystone.ibanksystems.com 2004/09/29 15:53:46:117 CDT [DEBUG] HttpMethodBase - HttpMethodBase.execute(): S erver demanded authentication credentials, will try again. 2004/09/29 15:53:46:127 CDT [DEBUG] HttpMethodBase - Should close connection in response to Connection: close 2004/09/29 15:53:46:127 CDT [DEBUG] HttpMethodBase - Execute loop try 2 2004/09/29 15:53:46:127 CDT [DEBUG] HttpMethodBase - Opening the connection. 2004/09/29 15:53:46:167 CDT
RE: HttpClient + HTTPS + NTLM Authentication = HTTP/1.1 401Access Denied
Christopher, Ok, I see. This is weird. I can't explain it. Maybe I am just too tired right now and should go to bed. Actually it is preferred to not do a POST against a protected URL. One should do a GET or a HEAD first, get authenticated, get a session cookie, and than do a POST. Another thing to try is turning on 'expect: continue' handshake http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/ExpectContinueMethod.html#setUseExpectHeader(boolean) Oleg On Wed, 2004-09-29 at 23:59, Burke, Christopher wrote: Oleg, Thanks for your prompt response. The main problem is that the file has not been uploaded, but the return code is 200. I am trying to post the File object 'f' to the 'F1' textbox in the following form (File f = new File(C:/secureHttp/anotherLog.log);). I believe my code is correct. I am at a loss. What could be the problem? FORM ENCTYPE=multipart/form-data METHOD=POST ACTION=siteman.asp?u=Dd=c:\im\ FONT SIZE=1 FACE=Arial, Helvetica, sans-serifNAME OF DESTINATION FOLDER ON WEB SITE/FONTBR FONT SIZE=4 FACE=Arial, Helvetica, sans-serifBc:\im\/B/FONTP FONT SIZE=1 FACE=Arial, Helvetica, sans-serifPATHNAME OF LOCAL DOCUMENTBR(SEND THIS FILE TO THE WEB SERVER)/FONTBRINPUT SIZE=30 TYPE=FILE NAME=F1P INPUT TYPE=SUBMIT VALUE=UPLOAD nbsp; INPUT TYPE=SUBMIT NAME=POSTACTION VALUE=CANCEL PFONT SIZE=2 FACE=Arial, Helvetica, sans-serifIf the B[BROWSE...]/B button is not displayed, BRyou must upgrade your A HREF=http://www.netscape.com;Netscape/A or A HREF=http://www.microsoft.com;Microsoft/A browser. /FORM/ Thanks again for your help, Oleg. Christopher -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 29, 2004 4:29 PM To: Commons HttpClient Project Subject: Re: HttpClient + HTTPS + NTLM Authentication = HTTP/1.1 401Access Denied Christopher, What is exactly the problem? The authentication succeeded: HTTP/1.1 200 OK Session cookie has been sent: ASPSESSIONIDAQQBDABR=LMNNMHNALPPKIBENMNNANHGP NTLM authentication scheme is a stateful one and requires multiple challenges/responses. The first 401 Access Denied response is perfectly OK. For details see: http://davenport.sourceforge.net/ntlm.html WARNING: contains utter insanity ;-) Oleg On Wed, 2004-09-29 at 23:10, Burke, Christopher wrote: All, I need help implementing a Commons HttpClient solution to post files to a web server via an ASP page. This seems somewhat straightforward, but I am having trouble with the NTLM authentication. Code Snippet: String url = https://keystone.ibanksystems.com/carlsontest/siteman.asp?u=Yd=c:\\im\ \; NTCredentials creds = new NTCredentials(user,password,keystone.ibanksystems.com,domain); HttpClient client = new HttpClient(); MultipartPostMethod mpPostMethod = new MultipartPostMethod(url); client.getState().setCredentials(null, null, creds); File f = new File(C:/secureHttp/anotherLog.log); //mpPostMethod.addParameter(F1,f.getName(),f); mpPostMethod.addParameter(F1,f); int statusCode = client.executeMethod(mpPostMethod); System.out.println(Status Line: + mpPostMethod.getStatusLine()); System.out.println(Status Code: + statusCode); mpPostMethod.releaseConnection(); Debug Output: 2004/09/29 15:53:44:425 CDT [DEBUG] HttpClient - Java version: 1.4.2_05 2004/09/29 15:53:44:425 CDT [DEBUG] HttpClient - Java vendor: Sun Microsystems I nc. 2004/09/29 15:53:44:425 CDT [DEBUG] HttpClient - Java class path: .;..;C:\j2sdk1 .4.2_05\bin;C:\apacheCommons\commons-httpclient.jar;C:\apacheCommons\com mons-log ging-api.jar;C:\apacheCommons\commons-logging.jar;C:\apacheCommons\commo ns-codec -1.3.jar 2004/09/29 15:53:44:425 CDT [DEBUG] HttpClient - Operating system name: Windows XP 2004/09/29 15:53:44:425 CDT [DEBUG] HttpClient - Operating system architecture: x86 2004/09/29 15:53:44:425 CDT [DEBUG] HttpClient - Operating system version: 5.1 2004/09/29 15:53:44:565 CDT [DEBUG] HttpClient - SUN 1.42: SUN (DSA key/paramete r generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection Ce rtStores) 2004/09/29 15:53:44:565 CDT [DEBUG] HttpClient - SunJSSE 1.42: Sun JSSE provider (implements RSA Signatures, PKCS12, SunX509 key/trust factories, SSLv3, TLSv1) 2004/09/29 15:53:44:565 CDT [DEBUG] HttpClient - SunRsaSign 1.42: SUN's provider for RSA signatures 2004/09/29 15:53:44:565 CDT [DEBUG] HttpClient - SunJCE 1.42: SunJCE Provider (i mplements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman, HMAC-MD5, HMAC-SH A1) 2004/09/29 15:53:44:565 CDT [DEBUG] HttpClient - SunJGSS 1.0: Sun (Kerberos v5) 2004/09/29 15:53:45:857 CDT [DEBUG] HttpConnection - HttpConnection.setSoTimeout (0) 2004/09/29 15:53:45:857 CDT [DEBUG
Re: Performance
Great news indeed. The reported performance boost does justify cutting a new release. Folks, how do you all feel about releasing HttpClient 2.0.2? Oleg On Tue, 2004-09-28 at 00:38, Eric Johnson wrote: And I've finally gotten test results back from the appropriate people here. In our test lab, between HttpClient 2.0.1 and the nightly, we found a difference of about 4ms per request. As this was a live-test environment, with all of our application environment around HttpClient, the total numbers are probably mostly irrelevant to HttpClient, but the measurable improvement was entirely due to HttpClient changes. We have some other statistics, but I worry that those are misleading for now, so I'm not mentioning those. Hopefully, I'll be able to pass along some concrete data at some point. For our purposes, the build otherwise looks stable. -Eric. Oleg Kalnichevski wrote: Folks, Could you please grab the latest 2.0 nightly build and see if it runs stable enough for production purposes? When we have a couple of reports confirming adequate stability, we'll call for the 2.0.2 release Oleg On Fri, 2004-09-03 at 00:00, Eric Johnson wrote: My read on Odi's statistics is that the patch has a pretty consistent 1ms impact on every request. This corresponds pretty well with my understanding of the theoretical improvements behind the patch. To the effect that HttpClient's performance is affected, header parsing will be faster, and reading the body of the connection will be roughly the same, presumably because the client of HttpClient buffers large reads. On a 1Ghz machine, this patch means one million processor cycles that can be put to a better use for *each* request. That's more than benchmark optimization, I think. -Eric. Oleg Kalnichevski wrote: Eric, This patch makes a difference for only relatively small payloads when the response content is about the size of the status line + headers. In most (real life) cases the performance gain is virtually negligible. This is more about benchmark optimization than anything else. Yet, it see no problem with another point release Oleg On Thu, 2004-09-02 at 19:06, Eric Johnson wrote: I don't know whether this would be a premature time to call for a new release, but the prospect of significantly better performance out of HttpClient has some people in my company very interested. What are the chances of a 2.0.2 release with this fix in it? (I'm willing to build from the source, but others in my company like the idea of an official build perhaps more than they need to.) -Eric. - 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: ATTN Open-source projects using HttpClient
Thanks, Adam Should we decide to go on a spamming spree, these may also become potential victims ;-) Oleg On Tue, 2004-09-28 at 20:37, Adam R. B. Jack wrote: On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote: As far as I know the following projects rely on HttpClient 2.0 as a required or optional dependency * Apache Jakarta Slide (http://jakarta.apache.org/slide/) * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/) * Apache Axis (http://ws.apache.org/axis/) * Apache XML-RPC (http://ws.apache.org/xmlrpc/) * Spring Framework (http://www.springframework.org/) * HtmlUntit (http://htmlunit.sourceforge.net/) * XINS (http://xins.sourceforge.net/) Just stumbled over this mail. Does the Dependees list here help give you other possibles? http://brutus.apache.org/gump/public/jakarta-commons/commons-httpclient/details.html regards, Adam - 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: client-certificate authentication
Mark, We do not have a full-blown tutorial on this subject as SSL authentication is basically is out of HttpClient scope. This sample code does, however, have extensive javadocs on the matter. http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/AuthSSLProtocolSocketFactory.java?only_with_tag=HTTPCLIENT_2_0_BRANCHview=markup The two other files required to compile AuthSSLProtocolSocketFactory can found here http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/?only_with_tag=HTTPCLIENT_2_0_BRANCH Hope this helps Oleg On Tue, 2004-09-28 at 23:00, Mark Wilcox wrote: Hi, Is there any documentation on how to do client-certificate authentication with HTTPClient? I didn't see anything in the SSL docs on the web site or via Google. Thanks, Mark - 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: Problems using AuthSSLProtocolSocketFactory to send ClientCertificate in HTTPS session handshake
My belief at this point is that Oracle is only sending the client certificate to browser (IE) based clients. That would explain the problem. I have created an Oracle TAR, to see if this is an Oracle problem. Dale, This assumption can be easily tested. The only way the target web server can tell IE from other agents is by the User-Agent request header. Try setting the user agent header to something like that and see if that makes any difference. GetMethod httpget = new GetMethod(/); httpget.setRequestHeader(User-Agent, Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)); This can also be a problem with the Sum implementation of JSSE, which for whatever reason ignores the client certificate request issued by the Oracle single signon server. Consider trying alternative JSSE implementations such as IBM JSSE or IAIK iSaSiLk. Likewise, it may also be a bug in the Oracle SSL library. Do you know exactly what SSL implementation Oracle single signon server employs? It is based on OpenSSL or some proprietary stuff? Hope this helps Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems using AuthSSLProtocolSocketFactory to send Client Certificate in HTTPS session handshake
Dale, Do you know if the client authentication has been configured as required or optional? Does the server reject the connection when attempt is made to authenticate with an invalid certificate? The fact that IE pops up the certificate dialog does not not actually mean that the server validates the certificate or requests a client certificate at all. I tend to trust more the SSL log showing that the server did not request a client certificate. I retested the AuthSSLProtocolSocketFactory against Apache 2.0.51 with mod_ssl one more time and everything appeared to be OK. Oleg On Sat, 2004-09-25 at 22:26, Dale McIntosh wrote: I have been trying for quite a wile to get the AuthSSLProtocolSocketFactory to send a client certificate and it doesn't seem to be working. I am wondering if the server (Oracle single sign-on server) is requesting the client cert. When the request is made from a browser, the browser does send the client cert. I have attached, my application, it is relatively simple and a debug log. The debug options I used were - javax.net.debug=ssl,handshake,keymanager. I have looked at the debug log and I do not see a certificate request. However, when IE is used, IE sends a client certificate. Any help would be appreciated. Thanks, Dale McIntosh __ - 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: Updated description Re: detailed descrption for cookies problem in HttpClient.Thanks.
Tom, Having the IE wire dump it should not be that difficult. Just carefully analyze the wire dump and try to emulate the request structure (protocol version, request headers) as close as possible. For instance, the referer header in the second POST may well be the missing bit: Referer: http://resources.hewitt.com/jpmc/; Besides, note the use of HTTP/1.0 on the part of IE. Configure HttpClient to use HTTP/1.0 as well. I doubt it should matter, but just in case. Hope this helps Oleg On Wed, 2004-09-22 at 21:17, tom yin wrote: Hey, guys, I have updated the problem description on my website [ http://www.cs.ucf.edu/~cyin/httpClient/letter.html ], and now you can access the debugging info [case II-- 2) --debugging info], testing results from proxomitron on both IE and HttpClient [case II -- 3)]. If you check the debugging info carefully, you will find the link2 can be accessed successfully. Also when the link3 is accessed, it will be redirected to an error page, https://lb32.resources.hewitt.com/sg1dgp9/tbiappt300/TbiaStatelessErrorPage , which is not the login page I need. Thanks for your time. Tom tom yin [EMAIL PROTECTED] wrote: Hi, guys, I am doing a intelligent spider projects, and trying to grab data from sites automatically. I don't know HttpClient a lot, but now I have collected data successfully from various websites with the help of you guys. (Oleg has helped me to solved a difficult problem yesterday. Thank Oleg.) I have sent a couple of messages to ask a problem I found when I try to access the login page of http://resources.hewitt.com/jpmc/ . This website is different from otheres, because it is very sensitive, so I think it may have some mechanism I don't know. I hope everybody also can learn something from this. Please allow me to describe the problem in details. I've posted it on my website for better look [ http://www.cs.ucf.edu/~cyin/httpClient/letter.html ]. Thanks a lot. Tom - Do you Yahoo!? vote.yahoo.com - Register online to vote today! - Do you Yahoo!? vote.yahoo.com - Register online to vote today! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient Powered
Dmitriy, 'enKoo WebApps' has been added to the list of HttpClient powered apps. Check it out at: http://jakarta.apache.org/commons/httpclient/applications.html , Oleg On Tue, 2004-09-21 at 20:42, Dmitriy wrote: Hi I'd like to announce that enKoo's application WebApps is HttpClient powered. WebApps is enKoo's solution to provide secure remote access to web based (i.e. Intranet) application on a remote network. Details can be found at http://www.enkoo.com/webappssolution.htm. Thank You Dmitriy Ayrapetov enKoo Inc. www.enkoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ATTN Open-source projects using HttpClient
I apologize for forgetting about Maven and Jelly. Are there any plans to evaluate HttpClient 3.0? We are trying to get some feedback about the new 3.0 API before the call the API freeze. Oleg On Tue, 2004-09-21 at 03:07, Dion Gillard wrote: Jelly and Maven both use httpclient. On Mon, 20 Sep 2004 22:50:20 +0200, Oleg Kalnichevski [EMAIL PROTECTED] wrote: As far as I know the following projects rely on HttpClient 2.0 as a required or optional dependency * Apache Jakarta Slide (http://jakarta.apache.org/slide/) * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/) * Apache Axis (http://ws.apache.org/axis/) * Apache XML-RPC (http://ws.apache.org/xmlrpc/) * Spring Framework (http://www.springframework.org/) * HtmlUntit (http://htmlunit.sourceforge.net/) * XINS (http://xins.sourceforge.net/) I just wonder if any of the projects' committers are currently subscribed to or monitor this mail list? We would love to know if there are any plans to evaluate HttpClient 3.0, or any migration plans already. What can we do to make the transition, if planned, easier? 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: Cookie problems / strict mode
Robert, It is a known problem with HttpClient 2.0. There are three possibilities: (1) Use HttpClient 3.0, which provides fine-grained control over protocol compliance leniency. (2) Disable auto redirect and handle redirects manually http://jakarta.apache.org/commons/httpclient/redirects.html (3) Override HttpMethodBase#addCookieRequestHeader() method protected void addCookieRequestHeader( HttpState state, HttpConnection conn) throws IOException, HttpException { // Clean up the cookie headers removeRequestHeader(cookie); CookieSpec matcher = CookiePolicy.getSpecByPolicy(state.getCookiePolicy()); Cookie[] cookies = matcher.match(conn.getHost(), conn.getPort(), getPath(), conn.isSecure(), state.getCookies()); if ((cookies != null) (cookies.length 0)) { getRequestHeaderGroup().addHeader( matcher.formatCookieHeader(cookies)); } } Hope this helps Oleg On Tue, 2004-09-21 at 12:10, Robert Gold wrote: Hi, I am using http-client 2.0.1 (1 August 2004). I noticed that lots of websites just accept the cookies to be sent in one single line (like sent by IE). This is with http-client just possible in strict mode. But now I have a webserver which redirects me to an URL which is not allowed/valid in strict mode, but at the same time it accepts just the cookies send in a single line. I saw a patch from 2003 which allowed the user to add a cookie request-header manually. This patch has been removed again from the new version? Is there now another technique for that? I don't understand why this 'sending of cookies in a single line' must be bound to the strict mode, which has apparently also other impacts. It would be very nice if you could give me some help how to solve this problem. For me it's either way if I create the cookie-header myself or it's done by the http-client or in whatever way. It just must access this site and I don't know how. Thanks for help, Robert. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ATTN Open-source projects using HttpClient
As far as I know the following projects rely on HttpClient 2.0 as a required or optional dependency * Apache Jakarta Slide (http://jakarta.apache.org/slide/) * Apache Jakarta Cactus (http://jakarta.apache.org/cactus/) * Apache Axis (http://ws.apache.org/axis/) * Apache XML-RPC (http://ws.apache.org/xmlrpc/) * Spring Framework (http://www.springframework.org/) * HtmlUntit (http://htmlunit.sourceforge.net/) * XINS (http://xins.sourceforge.net/) I just wonder if any of the projects' committers are currently subscribed to or monitor this mail list? We would love to know if there are any plans to evaluate HttpClient 3.0, or any migration plans already. What can we do to make the transition, if planned, easier? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 3.0 alpha 2 release
+1 On Fri, 2004-09-17 at 04:12, Michael Becke wrote: It looks like we're ready for a 3.0 alpha 2 release. Please vote as follows: -- Vote: HttpClient 3.0 alpha 2 release [x] +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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0 Webapp tests failing
On Fri, 2004-09-17 at 09:49, Ortwin Glck wrote: Some of the Cookie tests are currently failing. Can some Cookie expert have a look into this? Odi, Which branch: HEAD or 2.0? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]