Odd problem

[Brett Knights]

Hi,

I am using RC3 with jdk 1.4.2_03

When I use http client to get to the site I get a 404  (http client
wire log follows then grinder generated IE trace). I just can't see
what is going wrong. Any suggestions are appreciated. This is part of
a larger scripted operation so I am wondering if if is possible that I
am stepping on something by not releasing connections correctly. The
"11b" at 26 Jan 2004 20:54:20,38726 Jan 2004 20:54:20,387 seems rather
odd.

DEBUG [main] httpclient.wire - >> "GET /app/center/myroles.nl
HTTP/1.1[\r][\n]": 26 Jan 2004 20:54:20,247
DEBUG [main] httpclient.wire - >> "User-Agent: Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; Q312461)[\r][\n]": 26 Jan 2004
20:54:20,247
DEBUG [main] httpclient.wire - >> "Referer:
https://target.com/app/login/nllogin.nl[\r][\n]": 26 Jan 2004
20:54:20,247
DEBUG [main] httpclient.wire - >> "Host: target.com[\r][\n]": 26 Jan
2004 20:54:20,247
DEBUG [main] httpclient.wire - >> "Cookie: NS_VER=9.1[\r][\n]": 26 Jan
2004 20:54:20,247
DEBUG [main] httpclient.wire - >> "Cookie:
JSESSIONID=536c011ea00848b78315913117b9c243.mkbxr2PEmlnva30N-BbQmkLz-A
Tzr6Lzn6rzqwTxpQOUc30KaNDvmQbJrkTOokTBrxyL8Q5xmReHoA5Qmh0KaMTvmQbO-kDv
rA4Ka3aIqRnvp6iIpAjOp6jynQjM-AbJpgaTax4SbwbCpQPz8QvJpkixn6jAmljGr5XDqQ
LvpAe_[\r][\n]": 26 Jan 2004 20:54:20,247
DEBUG [main] httpclient.wire - >> "Cookie:
lastUser=ACCT102534_3_3[\r][\n]": 26 Jan 2004 20:54:20,257
DEBUG [main] httpclient.wire - >> "Cookie: T16:byMeU53W=[\r][\n]": 26
Jan 2004 20:54:20,257
DEBUG [main] httpclient.wire - >> "[\r][\n]": 26 Jan 2004 20:54:20,257
DEBUG [main] httpclient.wire - << "HTTP/1.1 404 Not Found[\r][\n]": 26
Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "Date: Tue, 27 Jan 2004 04:54:26
GMT[\r][\n]": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "Server: Oracle9iAS/9.0.2 Oracle
HTTP Server[\r][\n]": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "Transfer-Encoding:
chunked[\r][\n]": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "Content-Type: text/html;
charset=iso-8859-1[\r][\n]": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "1": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "1": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "b": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "[\r]": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "[\n]": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "[\n]": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "[\n]": 26 Jan 2004
20:54:20,387
DEBUG [main] httpclient.wire - << "404 Not Found[\n]":
26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "[\n]": 26 Jan 2004
20:54:20,387
DEBUG [main] httpclient.wire - << "Not Found[\n]": 26 Jan
2004 20:54:20,387
DEBUG [main] httpclient.wire - << "The requested URL / was not found
on this server.[\n]": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "[\n]": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "Oracle HTTP Server/1.3.22
Server at target.com Port 444[\n]": 26 Jan 2004 20:54:20,387
DEBUG [main] httpclient.wire - << "[\n]": 26 Jan 2004
20:54:20,397
DEBUG [main] httpclient.wire - << "[\r]": 26 Jan 2004 20:54:20,397
DEBUG [main] httpclient.wire - << "[\n]": 26 Jan 2004 20:54:20,397
DEBUG [main] httpclient.wire - << "0": 26 Jan 2004 20:54:20,397
DEBUG [main] httpclient.wire - << "[\r]": 26 Jan 2004 20:54:20,397
DEBUG [main] httpclient.wire - << "[\n]": 26 Jan 2004 20:54:20,397
DEBUG [main] httpclient.wire - << "[\r]": 26 Jan 2004 20:54:20,397
DEBUG [main] httpclient.wire - << "[\n]": 26 Jan 2004 20:54:20,397

When I use IE I get the page expected:
-- localhost:2290->target.com:443 --
GET /app/center/myroles.nl HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/msword, application/x-shockwave-flash,
application/vnd.ms-excel, */*
Referer:
https://target.com/pages/login.jsp?rdt=%2Fapp%2Fcenter%2Fmyroles.nl
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
Q312461)
Host: target.com
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: lastUser=ACCT102534_3_3; NLVisitorId=GEVsNmOJAOKYoS-W;
JSESSIONID=91ac67ead38b4e579f08f7f791d86f8f.mkbxr2PEmlnva30S-BbQmkLz-A
Tzr6Lzn6rzqwTxpQOUc30KaNDvmQbJrkTOokTBrxyL8Q5xmReHoA5Qmh0Kc2TvmQbO-kDv
rA4Ka3uIqRnvp6iIpAjOp6jynQjM-AbJpgaLbheLaNqxo6XHngbCpQPz8QfznA5Pp7ftol
bGmkTy; NS_VER=9.1;
stickytags=T1:byMeU53W,T2:byMeU53W,T3:byMeU53W,T4:byMeU53W,T5:byMeU53W
,T6:byMeU53W,T7:byMeU53W,T8:byMeU53W,T9:byMeU53W,T10:byMeU53W,T11:byMe
U53W,T12:byMeU53W,T13:byMeU53W,T14:byMeU53W,T15:byMeU53W,T16:byMeU53W;
loginredirect=T;
PREF=ID=10fcf1af58cafe4f:TM=1072562878:LM=1072562878:S=80KxPEiJisEzgB4
2


-- target.com:443->localhost:2290 --
HTTP/1.1 200 OK
Date: Tue, 27 Jan 2004 03:45:19 GMT
Server: Oracle9iAS/9.0.2 Oracle HTTP Server
Content-Length: 4942
Set-Cookie:
JSESSIONID=91ac67ead38b4e579f08f7f791d86f8f.mkbxr2PEmlnva30S-BbQmkLz-A
Tzr6Lzn6rz

[PATCH] FilePart class

[BLasch]

Hi All,

I'm currently working on a subclass of
org.apache.commons.httpclient.methods.multipart.FilePart that allows the
multipart post to be stopped prematurely.  It would be really nice to have
protected access on the member variable source in FilePart, so I only have
to override the sendData function as opposed to most of the class.  Any
chance of getting this changed?

--- FilePart.java.orig  Mon Jan 26 16:40:39 2004
+++ FilePart.java Mon Jan 26 16:41:38 2004
@@ -109,7 +109,7 @@
 EncodingUtil.getAsciiBytes(FILE_NAME);

 /** Source of the file part. */
-private PartSource source;
+protected PartSource source;

 /**
  * FilePart Constructor.


Thanks.
- Robert Lasch
Follett Library and School Group


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10794] - User interaction for authentication

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794

User interaction for authentication





--- Additional Comments From [EMAIL PROTECTED]  2004-01-26 21:09 ---
A subtle distinction, argh!  I think it breaks down like this:
* HttpState - properties of the HTTP communication (cookies, authentication info)
* HttpClientParams - behavioral characteristics desired by the client -
timeouts, spec conformance, resource usage)

Based on those criteria, I think I would choose HttpClientParams.  How
authentication is handled would seem to be a behavioral characteristic desired
by the client.  But perhaps my categorizations are not correct?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10794] - User interaction for authentication

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794

User interaction for authentication





--- Additional Comments From [EMAIL PROTECTED]  2004-01-26 18:08 ---
Roland,
I agree with you that the current design may be too contraining. I just thought
credential callbacks had in fact nothing to do with HTTP state. I also did not
feel like making HttpState class coupled with AuthScheme interface. 

Folks, please speak out: what should it be the home for the credential
callbacks: HttpState or HttpClientParams?

Cheers,
Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Re: I'm a big loser

[Kalnichevski, Oleg]

David,
That has nothing to do with Unix (OS) security. Your JVM is configured to run with 
Java security activated. Make sure that the security managers allows for setting 
system properties on run-time or set these settings upon JVM startup using -D parameter

Hope this helps

Oleg  

-Original Message-
From: D Alvarado [mailto:[EMAIL PROTECTED]
Sent: Monday, January 26, 2004 17:17
To: [EMAIL PROTECTED]
Subject: Re: Re: I'm a big loser


Ok, looked at the web page about turning on wire
logs and it asked me to add these lines to my
java program:

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"); 

But I guess since I'm not root I got the
following exception:

java.security.AccessControlException: access
denied (java.util.PropertyPermission
org.apache.commons.logging.Log write)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)

Can I add these properties somewhere else?  Or
where does the sysadmin have to add them?

Thanks - 

 Begin Original Message 

From: Eric Johnson <[EMAIL PROTECTED]>
Sent: Mon, 26 Jan 2004 09:57:59 -0500
To: Commons HttpClient Project
<[EMAIL PROTECTED]>
Subject: Re: I'm a big loser


Dave,

*You* have to generate the wire log.

See this link
http://jakarta.apache.org/commons/httpclient/logging.html

that Oleg pointed you to.

-Eric.


D Alvarado wrote:

>Again, here is my noviceness coming out, but
>where would I find this wirelog of the HTTP
>session?  I am running Apache Web Server 1.27
>with WebLogic 5.1, sp 12, if that's useful.
>
> Begin Original Message 
>
>From: Oleg Kalnichevski <[EMAIL PROTECTED]>
>Sent: Sat, 24 Jan 2004 11:42:12 +0100
>To: Commons HttpClient Project
><[EMAIL PROTECTED]>
>Subject: Re: RE: I'm a big loser
>
>
>Dave,
>
>Realm is a set of documents/URLs protected by the
>same authentication
>scheme and backed by the same user registry. You
>may leave the realm
>parameter null if you do not know what your
>authentication realm name
>is. Null realm basically means any realm. In very
>security caution
>applications you should probably avoid sending
>your credentials to any
>realm, but if you trust the target host, realm
>does not really matter
>too much, if you do not have to authenticate
>against multiple realms
>
>I am afraid I can't be of any further help,
>unless I get to see the
>wirelog on the HTTP session in question. Feel
>free to strip or obfuscate
>all the information you deem sensitive: host
>names, username, passwords,
>upload file content, etc. I am only interested in
>request/response
>headers
>
>Oleg
>  
>

-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



 End Original Message 




Care2 make the world greener!
Eighty-six nations have signed the international Framework Convention on Tobacco 
Control. Help get the U.S. on the list! http://www.care2.com/go/z/10840/1060

-
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: Connection Reset Error

[Kalnichevski, Oleg]

David,
Read timeout is in milliseconds, not in seconds. Try setting the timeout value to 
something more reasonable.

Oleg

-Original Message-
From: David Webb [mailto:[EMAIL PROTECTED]
Sent: Monday, January 26, 2004 17:10
To: Commons HttpClient Project
Subject: Re: Connection Reset Error


When I set the line that you specified, the following error occurs...

I added.
client.getHttpConnectionManager().getParams().setSoTimeout(3600);

Now I get.  Any suggestions?

Jan 26, 2004 11:22:27 AM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
INFO: Recoverable exception caught when processing request
Jan 26, 2004 11:22:31 AM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
INFO: Recoverable exception caught when processing request
Jan 26, 2004 11:22:34 AM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
INFO: Recoverable exception caught when processing request
Jan 26, 2004 11:22:38 AM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
INFO: Recoverable exception caught when processing request
Jan 26, 2004 11:22:38 AM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
WARNING: Recoverable exception caught but MethodRetryHandler.retryMethod() 
returned false, rethrowing exception
Exception thrown:
org.apache.commons.httpclient.IOTimeoutException: Read timed out
at 
org.apache.commons.httpclient.HttpConnection$WrappedInputStream.handleException
(HttpConnection.java:1369)
at org.apache.commons.httpclient.HttpConnection$WrappedInputStream.read
(HttpConnection.java:1379)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at java.io.PushbackInputStream.read(PushbackInputStream.java:120)
at org.apache.commons.httpclient.HttpParser.readRawLine
(HttpParser.java:109)
at org.apache.commons.httpclient.HttpParser.readLine
(HttpParser.java:135)
at org.apache.commons.httpclient.HttpConnection.readLine
(HttpConnection.java:1037)
at org.apache.commons.httpclient.HttpMethodBase.readStatusLine
(HttpMethodBase.java:1842)
at org.apache.commons.httpclient.HttpMethodBase.readResponse
(HttpMethodBase.java:1611)
at org.apache.commons.httpclient.HttpMethodBase.execute
(HttpMethodBase.java:997)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry
(HttpMethodDirector.java:316)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod
(HttpMethodDirector.java:172)
at org.apache.commons.httpclient.HttpClient.executeMethod
(HttpClient.java:468)
at org.apache.commons.httpclient.HttpClient.executeMethod
(HttpClient.java:355)
at com.bac.amg.acs.HTTPBatch.execute(HTTPBatch.java:158)
at com.bac.amg.acs.HTTPBatch.main(HTTPBatch.java:76)

Thanks.

--
Sincerely,
David Webb
Vice-President
Hurff-Webb, Inc.
http://www.hurff-webb.com
(904) 861-2366
(904) 534-8294 Mobile


Quoting Michael Becke <[EMAIL PROTECTED]>:

> Hi David,
> 
> I would suggest trying the SO_TIMEOUT, though I am not sure this is the  
> cause.  It seems that you are using HttpClient from HEAD.  In this  
> version you can set the default timeout using:
> 
> HttpClient client = 
> client.getHttpConnectionManager().getParams().setSoTimeout(SOME_TIMEOUT) 
> ;
> 
> Mike
> 
> On Jan 23, 2004, at 3:11 PM, David Webb wrote:
> 
> > I have written a program that uses HttpClient to call servlets that do  
> > batch
> > jobs and wait for their return...usually no more that 15 minutes.  I  
> > have the
> > Server timeout on the Web/App Server that the servlets reside on set  
> > to 1 hour
> > or 3600 seconds.  I have tested this in 2 environments using  
> > HttpClient to call
> > the Servlets that are in the same environment.
> >
> > 1) Windows 2K / JDK1.4.X - Works Fine, calls servlet, receives return  
> > code 8-9
> > minutes later and exits without error
> >
> > 2) HP-UX / JDK1.4.X - Runs for about 15 minutes then throws the  
> > following
> > exception:
> >
> > Exception thrown:
> > java.net.SocketException: Connection reset
> > at java.net.SocketInputStream.read(SocketInputStream.java:168)
> > at java.net.SocketInputStream.read(SocketInputStream.java:182)
> > at  
> > org.apache.commons.httpclient.HttpConnection$WrappedInputStream.read
> > (HttpConnection.java:1377)
> > at java.io.FilterInputStream.read(FilterInputStream.java:66)
> > at  
> > java.io.PushbackInputStream.read(PushbackInputStream.java:120)
> > at org.apache.commons.httpclient.HttpParser.readRawLine
> > (HttpParser.java:109)
> > at org.apache.commons.httpclient.HttpParser.readLine
> > (HttpParser.java:135)
> > at org.apache.commons.httpclient.HttpConnection.readLine
> > (HttpConnection.java:1037)
> > at org.apache.commons.httpclient.HttpMethodBase.readStatusLine
> > (HttpMethodBase.java:1842)
> > at org.apache.commons.httpclient.HttpMethodBase.readResponse
> > (HttpMethodBase.java:1611)
> 

Re: Connection Reset Error

[David Webb]

When I set the line that you specified, the following error occurs...

I added.
client.getHttpConnectionManager().getParams().setSoTimeout(3600);

Now I get.  Any suggestions?

Jan 26, 2004 11:22:27 AM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
INFO: Recoverable exception caught when processing request
Jan 26, 2004 11:22:31 AM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
INFO: Recoverable exception caught when processing request
Jan 26, 2004 11:22:34 AM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
INFO: Recoverable exception caught when processing request
Jan 26, 2004 11:22:38 AM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
INFO: Recoverable exception caught when processing request
Jan 26, 2004 11:22:38 AM org.apache.commons.httpclient.HttpMethodDirector 
executeWithRetry
WARNING: Recoverable exception caught but MethodRetryHandler.retryMethod() 
returned false, rethrowing exception
Exception thrown:
org.apache.commons.httpclient.IOTimeoutException: Read timed out
at 
org.apache.commons.httpclient.HttpConnection$WrappedInputStream.handleException
(HttpConnection.java:1369)
at org.apache.commons.httpclient.HttpConnection$WrappedInputStream.read
(HttpConnection.java:1379)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at java.io.PushbackInputStream.read(PushbackInputStream.java:120)
at org.apache.commons.httpclient.HttpParser.readRawLine
(HttpParser.java:109)
at org.apache.commons.httpclient.HttpParser.readLine
(HttpParser.java:135)
at org.apache.commons.httpclient.HttpConnection.readLine
(HttpConnection.java:1037)
at org.apache.commons.httpclient.HttpMethodBase.readStatusLine
(HttpMethodBase.java:1842)
at org.apache.commons.httpclient.HttpMethodBase.readResponse
(HttpMethodBase.java:1611)
at org.apache.commons.httpclient.HttpMethodBase.execute
(HttpMethodBase.java:997)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry
(HttpMethodDirector.java:316)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod
(HttpMethodDirector.java:172)
at org.apache.commons.httpclient.HttpClient.executeMethod
(HttpClient.java:468)
at org.apache.commons.httpclient.HttpClient.executeMethod
(HttpClient.java:355)
at com.bac.amg.acs.HTTPBatch.execute(HTTPBatch.java:158)
at com.bac.amg.acs.HTTPBatch.main(HTTPBatch.java:76)

Thanks.

--
Sincerely,
David Webb
Vice-President
Hurff-Webb, Inc.
http://www.hurff-webb.com
(904) 861-2366
(904) 534-8294 Mobile


Quoting Michael Becke <[EMAIL PROTECTED]>:

> Hi David,
> 
> I would suggest trying the SO_TIMEOUT, though I am not sure this is the  
> cause.  It seems that you are using HttpClient from HEAD.  In this  
> version you can set the default timeout using:
> 
> HttpClient client = 
> client.getHttpConnectionManager().getParams().setSoTimeout(SOME_TIMEOUT) 
> ;
> 
> Mike
> 
> On Jan 23, 2004, at 3:11 PM, David Webb wrote:
> 
> > I have written a program that uses HttpClient to call servlets that do  
> > batch
> > jobs and wait for their return...usually no more that 15 minutes.  I  
> > have the
> > Server timeout on the Web/App Server that the servlets reside on set  
> > to 1 hour
> > or 3600 seconds.  I have tested this in 2 environments using  
> > HttpClient to call
> > the Servlets that are in the same environment.
> >
> > 1) Windows 2K / JDK1.4.X - Works Fine, calls servlet, receives return  
> > code 8-9
> > minutes later and exits without error
> >
> > 2) HP-UX / JDK1.4.X - Runs for about 15 minutes then throws the  
> > following
> > exception:
> >
> > Exception thrown:
> > java.net.SocketException: Connection reset
> > at java.net.SocketInputStream.read(SocketInputStream.java:168)
> > at java.net.SocketInputStream.read(SocketInputStream.java:182)
> > at  
> > org.apache.commons.httpclient.HttpConnection$WrappedInputStream.read
> > (HttpConnection.java:1377)
> > at java.io.FilterInputStream.read(FilterInputStream.java:66)
> > at  
> > java.io.PushbackInputStream.read(PushbackInputStream.java:120)
> > at org.apache.commons.httpclient.HttpParser.readRawLine
> > (HttpParser.java:109)
> > at org.apache.commons.httpclient.HttpParser.readLine
> > (HttpParser.java:135)
> > at org.apache.commons.httpclient.HttpConnection.readLine
> > (HttpConnection.java:1037)
> > at org.apache.commons.httpclient.HttpMethodBase.readStatusLine
> > (HttpMethodBase.java:1842)
> > at org.apache.commons.httpclient.HttpMethodBase.readResponse
> > (HttpMethodBase.java:1611)
> > at org.apache.commons.httpclient.HttpMethodBase.execute
> > (HttpMethodBase.java:997)
> > at  
> > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry
> > (HttpMethodDirector.java:316)
> > at  
> > org.apache.commons.httpclient.HttpMethodDirector.executeMethod

Re: Re: I'm a big loser

[D Alvarado]

Ok, looked at the web page about turning on wire
logs and it asked me to add these lines to my
java program:

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"); 

But I guess since I'm not root I got the
following exception:

java.security.AccessControlException: access
denied (java.util.PropertyPermission
org.apache.commons.logging.Log write)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)

Can I add these properties somewhere else?  Or
where does the sysadmin have to add them?

Thanks - 

 Begin Original Message 

From: Eric Johnson <[EMAIL PROTECTED]>
Sent: Mon, 26 Jan 2004 09:57:59 -0500
To: Commons HttpClient Project
<[EMAIL PROTECTED]>
Subject: Re: I'm a big loser


Dave,

*You* have to generate the wire log.

See this link
http://jakarta.apache.org/commons/httpclient/logging.html

that Oleg pointed you to.

-Eric.


D Alvarado wrote:

>Again, here is my noviceness coming out, but
>where would I find this wirelog of the HTTP
>session?  I am running Apache Web Server 1.27
>with WebLogic 5.1, sp 12, if that's useful.
>
> Begin Original Message 
>
>From: Oleg Kalnichevski <[EMAIL PROTECTED]>
>Sent: Sat, 24 Jan 2004 11:42:12 +0100
>To: Commons HttpClient Project
><[EMAIL PROTECTED]>
>Subject: Re: RE: I'm a big loser
>
>
>Dave,
>
>Realm is a set of documents/URLs protected by the
>same authentication
>scheme and backed by the same user registry. You
>may leave the realm
>parameter null if you do not know what your
>authentication realm name
>is. Null realm basically means any realm. In very
>security caution
>applications you should probably avoid sending
>your credentials to any
>realm, but if you trust the target host, realm
>does not really matter
>too much, if you do not have to authenticate
>against multiple realms
>
>I am afraid I can't be of any further help,
>unless I get to see the
>wirelog on the HTTP session in question. Feel
>free to strip or obfuscate
>all the information you deem sensitive: host
>names, username, passwords,
>upload file content, etc. I am only interested in
>request/response
>headers
>
>Oleg
>  
>

-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



 End Original Message 




Care2 make the world greener!
Eighty-six nations have signed the international Framework Convention on Tobacco 
Control. Help get the U.S. on the list! http://www.care2.com/go/z/10840/1060

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26139] - Memory leak in MultiThreadedHttpClient caused by bad .equals()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26139

Memory leak in MultiThreadedHttpClient caused by bad .equals()





--- Additional Comments From [EMAIL PROTECTED]  2004-01-26 15:58 ---
Mike, the patch looks good. Can you take care of *ProtocolSocketFactory classes
in the contrib package too, please?

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Recoverable error question

[Eric Johnson]

Oleg Kalnichevski wrote:

Hi Tim,

See my comments in-line below
 

[snip]

My challenge is that the bank processes each GET request, even if it has 
the same parameters as a previous request (yes, I know that GETs should 
be idempotent but I don't have a choice).  I can't charge people twice. 
 I want to retry the request, though, if I know that the bank hasn't 
received it (DNS failure, connection refused, connection timeout), but I 
CAN'T retry it if they MAY have received the request (e.g. response read 
timeout, 500 error, etc.).

   

[snip]

The problem you are having should better be addressed at the application
level, not at the transport level. 
 

Oleg is precisely correct here.  The *only* way you can guarantee that 
you aren't duplicating requests is to address the problem at a higher 
level.  Perhaps put a "transaction id" or "message id" on each "GET" 
request, and the server will detect duplicate requests.

Failing that, you would need to make sure that the two machines were 
connected to the same network hub, so that communications failures of 
any sort help guarantee that *both* machines stop communicating with the 
outside world, and thus the server would recognize the problem as well.  
And that is still not a guarantee.

You could let us know which bank is in question, so the rest of us know 
not to leave our money with them, since they seem to have missed an 
important lesson in CS about ACID transactions.  For that matter, their 
investors probably want to know.  OK, don't tell us, since it probably 
violates some agreement you signed with them, but I sure would love to 
know

There are so many better solutions that come to mind for this kind of 
functionality, like JMS based solutions, which offer support 
functionality like guaranteed delivery.  Of course, my company sells 
such a product, so I should stop now before I cross the line into 
advertisement.

-Eric.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Connection Reset Error

[Eric Johnson]

There may be nothing you can do.  The underlying OS may simply choose to 
close an idle connection after a certain amount of time.  Seems odd to 
me, but possible.  An HTTP proxy server, for example, is free to close a 
connection after a certain amount of time with no activity.

You might try a telnet, FTP, or some such request from the command line, 
and see if they also get reset after 15 minutes of no activity on the HP 
box.

I don't suppose it is possible for you to connect your application 
differently?  For example, send in your requests, and the server 
responds immediately with an acknowledgement of the request received.  
On another connection, you can constantly reconnect a connection that 
waits 30-60s at most on the server to see if the activities have 
finished.  Once an activity succeeds, return some indication on this 
connection of which activity finished.  Then you can "call back" from 
your client application to get the results.

A little trickier that what you're doing, but not dramatically so.  
Perhaps you already thought of it, and were just wondering if there was 
a way to avoid the work?  It would have the benefit that it could 
actually consistently and reliably through proxy servers and routers 
that might otherwise drop an idle connection.

-Eric Johnson.

David Webb wrote:

I have written a program that uses HttpClient to call servlets that do batch 
jobs and wait for their return...usually no more that 15 minutes.  I have the 
Server timeout on the Web/App Server that the servlets reside on set to 1 hour 
or 3600 seconds.  I have tested this in 2 environments using HttpClient to call 
the Servlets that are in the same environment.

1) Windows 2K / JDK1.4.X - Works Fine, calls servlet, receives return code 8-9 
minutes later and exits without error

2) HP-UX / JDK1.4.X - Runs for about 15 minutes then throws the following 
exception:

Exception thrown:
java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:168)
   at java.net.SocketInputStream.read(SocketInputStream.java:182)
   at org.apache.commons.httpclient.HttpConnection$WrappedInputStream.read
(HttpConnection.java:1377)
   at java.io.FilterInputStream.read(FilterInputStream.java:66)
   at java.io.PushbackInputStream.read(PushbackInputStream.java:120)
   at org.apache.commons.httpclient.HttpParser.readRawLine
(HttpParser.java:109)
   at org.apache.commons.httpclient.HttpParser.readLine
(HttpParser.java:135)
   at org.apache.commons.httpclient.HttpConnection.readLine
(HttpConnection.java:1037)
   at org.apache.commons.httpclient.HttpMethodBase.readStatusLine
(HttpMethodBase.java:1842)
   at org.apache.commons.httpclient.HttpMethodBase.readResponse
(HttpMethodBase.java:1611)
   at org.apache.commons.httpclient.HttpMethodBase.execute
(HttpMethodBase.java:997)
   at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry
(HttpMethodDirector.java:316)
   at org.apache.commons.httpclient.HttpMethodDirector.executeMethod
(HttpMethodDirector.java:172)
   at org.apache.commons.httpclient.HttpClient.executeMethod
(HttpClient.java:468)
   at org.apache.commons.httpclient.HttpClient.executeMethod
(HttpClient.java:355)
   at com.bac.amg.acs.HTTPBatch.execute(HTTPBatch.java:157)
   at com.bac.amg.acs.HTTPBatch.main(HTTPBatch.java:75)
Is there anything I can do in HttpClient to prevent this from happening?

Thanks.

--
Sincerely,
David Webb
Vice-President
Hurff-Webb, Inc.
http://www.hurff-webb.com
(904) 861-2366
(904) 534-8294 Mobile




-
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: I'm a big loser

[Eric Johnson]

Dave,

*You* have to generate the wire log.

See this link http://jakarta.apache.org/commons/httpclient/logging.html 
that Oleg pointed you to.

-Eric.

D Alvarado wrote:

Again, here is my noviceness coming out, but
where would I find this wirelog of the HTTP
session?  I am running Apache Web Server 1.27
with WebLogic 5.1, sp 12, if that's useful.
 Begin Original Message 

From: Oleg Kalnichevski <[EMAIL PROTECTED]>
Sent: Sat, 24 Jan 2004 11:42:12 +0100
To: Commons HttpClient Project
<[EMAIL PROTECTED]>
Subject: Re: RE: I'm a big loser
Dave,

Realm is a set of documents/URLs protected by the
same authentication
scheme and backed by the same user registry. You
may leave the realm
parameter null if you do not know what your
authentication realm name
is. Null realm basically means any realm. In very
security caution
applications you should probably avoid sending
your credentials to any
realm, but if you trust the target host, realm
does not really matter
too much, if you do not have to authenticate
against multiple realms
I am afraid I can't be of any further help,
unless I get to see the
wirelog on the HTTP session in question. Feel
free to strip or obfuscate
all the information you deem sensitive: host
names, username, passwords,
upload file content, etc. I am only interested in
request/response
headers
Oleg
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10794] - User interaction for authentication

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10794

User interaction for authentication





--- Additional Comments From [EMAIL PROTECTED]  2004-01-26 14:02 ---
Hi Oleg,

I would leave it to the implementor of the callbacks to make sure there
is only one dialog on the screen. What about a multiuser-browser that is
running multiple browser windows for different users on different X Servers?
I guess there would be an instance of HTTP Client for each user, but we
cannot know for sure.
Also, one might have some default GUI handlers installed but want to
execute individual methods with other, non-GUI callbacks in place.

HttpState sounds like a good place to me. Especially if the callbacks are
part of the hierarchical parameters, as you suggested. Is it possible to
modify the global defaults parameters via API? I don't remember.

cheers,
  Roland

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26139] - Memory leak in MultiThreadedHttpClient caused by bad .equals()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26139

Memory leak in MultiThreadedHttpClient caused by bad .equals()





--- Additional Comments From [EMAIL PROTECTED]  2004-01-26 13:49 ---
Hi Mike,

Sorry for answering late, I've been offline for a while.
Your implementation beats all concerns I would have raised
about deriving classes from singletons. I like it.

cheers,
  Roland

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re: RE: I'm a big loser

[D Alvarado]

Again, here is my noviceness coming out, but
where would I find this wirelog of the HTTP
session?  I am running Apache Web Server 1.27
with WebLogic 5.1, sp 12, if that's useful.

 Begin Original Message 

From: Oleg Kalnichevski <[EMAIL PROTECTED]>
Sent: Sat, 24 Jan 2004 11:42:12 +0100
To: Commons HttpClient Project
<[EMAIL PROTECTED]>
Subject: Re: RE: I'm a big loser


Dave,

Realm is a set of documents/URLs protected by the
same authentication
scheme and backed by the same user registry. You
may leave the realm
parameter null if you do not know what your
authentication realm name
is. Null realm basically means any realm. In very
security caution
applications you should probably avoid sending
your credentials to any
realm, but if you trust the target host, realm
does not really matter
too much, if you do not have to authenticate
against multiple realms

I am afraid I can't be of any further help,
unless I get to see the
wirelog on the HTTP session in question. Feel
free to strip or obfuscate
all the information you deem sensitive: host
names, username, passwords,
upload file content, etc. I am only interested in
request/response
headers

Oleg


On Fri, 2004-01-23 at 23:11, D Alvarado wrote:
> I'm pretty sure the authentication is basic.  It
> is done through the Apache .htaccess and
> .htpasswd files.  However, I don't have a value
> for "realm" and I'm wondering if I need to put a
> value there.  I'm not even sure what a realm is,
> to be honest with you.
> 
> Thanks for your help - Dave
> 
>  Begin Original Message 
> 
> From: "Kalnichevski, Oleg"
> <[EMAIL PROTECTED]>
> Sent: Fri, 23 Jan 2004 09:01:16 -
> To: "Commons HttpClient Project"
> <[EMAIL PROTECTED]>
> Subject: RE: I'm a big loser
> 
> 
> Dave,
> 
> What kind of authentication does the target
> server expect: basic|digest|NTLM or form-based?
> At the moment it is not quite clear what is going
> on on the server side. If you posted a wire log
> of the HTTP session that exhibits the problem, I
> believe I would be able to tell more. See
> HttpClient logging guide for details
>

> 
> Oleg
> 
> 
> -Original Message-
>  From: D Alvarado
[mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 22, 2004 23:26
> To: [EMAIL PROTECTED]
> Subject: I'm a big loser
> 
> 
> I can't seem to figure out how to POST data to a
> page that is protected (puts up a gray box where
> you enter the username/password).  The code below
> is in a servlet running on www.mydomain.com and
> submitting to another page also on
www.mydomain.com.
> 
> // Create an instance of HttpClient.
> HttpClient client = new HttpClient();
> // submit username/password for the
gray box.
>
>
client.getState().setAuthenticationPreemptive(true);
> UsernamePasswordCredentials creds = new
> UsernamePasswordCredentials("username",
"password");
> client.getState().setCredentials(null,
> request.getServerName(), creds);
> 
> // Now submit this file to the piece that
> uploads batch files.
> String targetURL = "http://"; +
> request.getServerName() +
> "/hrw/ecom/HRWImportCOPSData";
> MultipartPostMethod method = new
> MultipartPostMethod(targetURL);
> method.addParameter("import_file",
> completeEcomFile.getName(), completeEcomFile);
> method.setDoAuthentication(true);
> 
> but when I try to submit the request using
> 
> statusCode = client.executeMethod(method);
> 
> I repeatedly get the exception "Connection
> refused."  I'm pretty sure the authentication is
> being required by the Apache webserver.  Any help
> is greatly appreciated - Dave
> 
> 
> Care2 make the world greener!
> Eighty-six nations have signed the international
> Framework Convention on Tobacco Control. Help get
> the U.S. on the list!
> http://www.care2.com/go/z/10840/1060
> 
>
-
> 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 Original Message 
> 
> 
> 
> 
> Care2 make the world greener!
> Eighty-six nations have signed the
international Framework Convention on Tobacco
Control. Help get the U.S. on the list!
http://www.care2.com/go/z/10840/1060
> 
>
-
> 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 Original Message 




Care2 make the world greener!
Eighty-six nations have signed the international Framework Convention on Tobacco 
Control. Help get