DO NOT REPLY [Bug 10816] - User/Developer Documentation

[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=10816

User/Developer Documentation





--- Additional Comments From [EMAIL PROTECTED]  2003-06-02 12:44 ---
Created an attachment (id=6597)
Update for the redirect docs to include information about the special redirect types.

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

Re: 300 Multiple Choices handling?

[Mike Moran]

Michael Becke wrote:
My guess is that it responds 300 for HTTP 1.0 and 302 for HTTP 1.1.  
Just a guess.
[ ... ]

It would seem not, as wget uses 1.1

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

Re: 300 Multiple Choices handling?

[Adrian Sutton]

I wonder... is HttpClient perhaps parsing out "www.blooberry.com/" as 
the value for the Host: header? My URL is slightly bogus, though 
perhaps technically valid. What happens with:
http://www.blooberry.com/indexdotpreview/html/index8.htm
(Note no double slash)

www.eskimo.com and www.blooberry.com appear to be on the same subnet; 
www.eskimo.com is perhaps the default VirtualHost.
ahhh, heh ya see, I *may* have just copied the URL wrong... :)  
There was a full stop at the end of the URL as I copied it - once 
that's removed I do indeed get a 300 response and HttpClient returns 
the 300 status along with the body just like wget.  Serves me right for 
trusting the Mail.app to automatically copy the URL for me.

Just wondering ...
Looks like this X-File can be closed with a really boring ending.

--
Mike Moran
Adrian Sutton.

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

Re: 300 Multiple Choices handling?

[Michael Becke]

My guess is that it responds 300 for HTTP 1.0 and 302 for HTTP 1.1.  
Just a guess.

Mike

On Monday, June 2, 2003, at 08:11 AM, Adrian Sutton wrote:

On Monday, June 2, 2003, at 09:57  PM, Mike Moran wrote:

Adrian Sutton wrote:
Hi Mike,
HttpClient returns 300 as the status code as would be expected in 
such a case.
Sounds reasonable. Does it also make the body available in this case?
Yes, the retrieved document is always available and (as everyone 
should know by now :) furthermore *must* always be read to avoid 
problems.  To make life easier when you call releaseConnection on a 
method any remaining response body is read before the connection is 
put back into the pool.

The developer is then free to select whichever option they want.
The URL you gave however return 302 not 300 and HttpClient throws an 
exception because cross-site redirects are not supported.
Umm. I think HttpClient and wget must disagree:

$ wget --server-response 
http://www.blooberry.com//indexdotpreview/html/index8.htm
--12:48:55--  
http://www.blooberry.com//indexdotpreview/html/index8.htm
   => `index8.htm'
Resolving www.blooberry.com... done.
Connecting to www.blooberry.com[204.122.16.82]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 300 Multiple Choices

...

A telnet to port 80 for that page also gives 300 Multiple Choices.
Interesting  I do get a 300 from telnet, but a 302 from HttpClient:
302


302 Found

Found
The document has moved http://www.eskimo.com/notfound.html";>here.


I'll have to play around with some logging information to find out 
exactly what's happening, but I have used a hand crafted response to 
show that HttpClient will return the 300 status code.

I'll create a patch for the docs to mention 300 responses.  Anything 
particularly important about them that I should note?
I'm not sure what the docs should say other than pointing out that 
you'll need to parse or display the body in some non-HTTP way to get 
any sense out of it.
There's actually a few status codes in the 3xx range that need a 
special mention so I'm adding them all in now.  The concept of a 304 
Not Modified is wierd, it's effectively a redirect to cache but that's 
not the way I'd ever thought of it.

Mike Moran
Regards,

Adrian Sutton.

-
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: 300 Multiple Choices handling?

[Mike Moran]

Adrian Sutton wrote:
On Monday, June 2, 2003, at 09:57  PM, Mike Moran wrote:

Adrian Sutton wrote:
[ ... ]
Umm. I think HttpClient and wget must disagree:

$ wget --server-response 
http://www.blooberry.com//indexdotpreview/html/index8.htm
--12:48:55--  http://www.blooberry.com//indexdotpreview/html/index8.htm
   => `index8.htm'
Resolving www.blooberry.com... done.
Connecting to www.blooberry.com[204.122.16.82]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 300 Multiple Choices

...

A telnet to port 80 for that page also gives 300 Multiple Choices.


Interesting  I do get a 300 from telnet, but a 302 from HttpClient:
302


302 Found

Found
The document has moved http://www.eskimo.com/notfound.html";>here.

[ ... ]

I wonder... is HttpClient perhaps parsing out "www.blooberry.com/" as 
the value for the Host: header? My URL is slightly bogus, though perhaps 
technically valid. What happens with:
http://www.blooberry.com/indexdotpreview/html/index8.htm
(Note no double slash)

www.eskimo.com and www.blooberry.com appear to be on the same subnet; 
www.eskimo.com is perhaps the default VirtualHost.

Just wondering ...

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

Re: 300 Multiple Choices handling?

[Adrian Sutton]

On Monday, June 2, 2003, at 09:57  PM, Mike Moran wrote:

Adrian Sutton wrote:
Hi Mike,
HttpClient returns 300 as the status code as would be expected in 
such a case.
Sounds reasonable. Does it also make the body available in this case?
Yes, the retrieved document is always available and (as everyone should 
know by now :) furthermore *must* always be read to avoid problems.  To 
make life easier when you call releaseConnection on a method any 
remaining response body is read before the connection is put back into 
the pool.

The developer is then free to select whichever option they want.
The URL you gave however return 302 not 300 and HttpClient throws an 
exception because cross-site redirects are not supported.
Umm. I think HttpClient and wget must disagree:

$ wget --server-response 
http://www.blooberry.com//indexdotpreview/html/index8.htm
--12:48:55--  http://www.blooberry.com//indexdotpreview/html/index8.htm
   => `index8.htm'
Resolving www.blooberry.com... done.
Connecting to www.blooberry.com[204.122.16.82]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 300 Multiple Choices

...

A telnet to port 80 for that page also gives 300 Multiple Choices.
Interesting  I do get a 300 from telnet, but a 302 from HttpClient:
302


302 Found

Found
The document has moved http://www.eskimo.com/notfound.html";>here.


I'll have to play around with some logging information to find out 
exactly what's happening, but I have used a hand crafted response to 
show that HttpClient will return the 300 status code.

I'll create a patch for the docs to mention 300 responses.  Anything 
particularly important about them that I should note?
I'm not sure what the docs should say other than pointing out that 
you'll need to parse or display the body in some non-HTTP way to get 
any sense out of it.
There's actually a few status codes in the 3xx range that need a 
special mention so I'm adding them all in now.  The concept of a 304 
Not Modified is wierd, it's effectively a redirect to cache but that's 
not the way I'd ever thought of it.

Mike Moran
Regards,

Adrian Sutton.

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

Re: 300 Multiple Choices handling?

[Mike Moran]

Ortwin Glück wrote:
Has anybody ever seen a 300 in the wild?
Yes. I gave an example in the email I sent. This page is linked to on 
that site.

However, I would say that they aren't numerous.

--
Mike Moran


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

Re: 300 Multiple Choices handling?

[Adrian Sutton]

Only when I went searching for them. :)

http://www.who.int/world-health-day/index.en.shtml

and for all the examples Google knows about:

http://www.google.com/search?q=HTTP+300+%22Multiple+Choices%22&ie=UTF- 
8&oe=UTF-8

I quite like the www.who.int idea of doing a search for the document  
and returning the results.

Adrian.

On Monday, June 2, 2003, at 09:54  PM, Ortwin Glück wrote:

Has anybody ever seen a 300 in the wild?

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



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

Re: 300 Multiple Choices handling?

[Mike Moran]

Adrian Sutton wrote:
Hi Mike,
HttpClient returns 300 as the status code as would be expected in such a 
case.  
Sounds reasonable. Does it also make the body available in this case?

The developer is then free to select whichever option they want.
The URL you gave however return 302 not 300 and HttpClient throws an 
exception because cross-site redirects are not supported.
Umm. I think HttpClient and wget must disagree:

$ wget --server-response 
http://www.blooberry.com//indexdotpreview/html/index8.htm
--12:48:55--  http://www.blooberry.com//indexdotpreview/html/index8.htm
   => `index8.htm'
Resolving www.blooberry.com... done.
Connecting to www.blooberry.com[204.122.16.82]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 300 Multiple Choices

...

A telnet to port 80 for that page also gives 300 Multiple Choices.

I'll create a patch for the docs to mention 300 responses.  Anything 
particularly important about them that I should note?
I'm not sure what the docs should say other than pointing out that 
you'll need to parse or display the body in some non-HTTP way to get any 
sense out of it.

--
Mike Moran


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

Re: 300 Multiple Choices handling?

[Ortwin Glück]

Has anybody ever seen a 300 in the wild?

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

Re: 300 Multiple Choices handling?

[Adrian Sutton]

Hi Mike,
HttpClient returns 300 as the status code as would be expected in such 
a case.  The developer is then free to select whichever option they 
want.  The URL you gave however return 302 not 300 and HttpClient 
throws an exception because cross-site redirects are not supported.

I'll create a patch for the docs to mention 300 responses.  Anything 
particularly important about them that I should note?

Regards,

Adrian Sutton.

On Monday, June 2, 2003, at 08:57  PM, Mike Moran wrote:

I was just skimming through the updated site and I noticed:

http://jakarta.apache.org/commons/httpclient/redirects.html

It explictly mentions 301/2/3/7 but makes no mention of 300 (Multiple 
Choices). I wouldn't expect any client library to handle these 
programmatically since the format of the body is undefined, but I'm 
slightly concerned about the example code which would recommend 
treating a 300 as if it was a 404 or some other sort of error.

I don't have the latest code up and running here to test what it would 
do. A reasonable example of a 300 is: 
http://www.blooberry.com//indexdotpreview/html/index8.htm. I'd be 
thankful if someone could test what HttpClient does on such a page.

--
Mike Moran


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

300 Multiple Choices handling?

[Mike Moran]

I was just skimming through the updated site and I noticed:

http://jakarta.apache.org/commons/httpclient/redirects.html

It explictly mentions 301/2/3/7 but makes no mention of 300 (Multiple 
Choices). I wouldn't expect any client library to handle these 
programmatically since the format of the body is undefined, but I'm 
slightly concerned about the example code which would recommend treating 
a 300 as if it was a 404 or some other sort of error.

I don't have the latest code up and running here to test what it would 
do. A reasonable example of a 300 is: 
http://www.blooberry.com//indexdotpreview/html/index8.htm. I'd be 
thankful if someone could test what HttpClient does on such a page.

--
Mike Moran


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

DO NOT REPLY [Bug 20240] - Cookies with null path attribute are rejected in the compatibility mode

[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=20240

Cookies with null path attribute are rejected in the compatibility mode

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED



--- Additional Comments From [EMAIL PROTECTED]  2003-06-02 09:00 ---
Ok, I compiled from CVS source and now it works for me.

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

Re: MultipartPostMethod takes long time to execute

[Martin Chan]

Kalnichevski, Oleg wrote:

>Martin, 
>I suppose you are running HttpClient 2.0alpha3 which is known to have a few issues 
>with 'expect: 100-continue' handshake. Please upgrade to 
>
Yes, and sorry that I haven't tell which version I use in the pervious
email.

>2.0beta1. If the problem still persists after the upgrade, please follow the 
>instructions of the trouble shooting guide:
>
I'll try it, Thanks.

>
>http://jakarta.apache.org/commons/httpclient/troubleshooting.html
>
>Oleg 
>
>-Original Message-
>From: Martin Chan [mailto:[EMAIL PROTECTED]
>Sent: Monday, June 02, 2003 09:02
>To: [EMAIL PROTECTED]
>Subject: MultipartPostMethod takes long time to execute
>
>
>Hi,
>
>I use MultipartPostMethod to do upload, but I found that it takes 3-4
>seconds to execute even for a very small file (<1KB).
>int status = httpClient.executeMethod(filePost);
>
>Does anyone have the same problem? How to improve the speed?
>
>
>I also found that the HttpClient fragment the post method to many
>packets, each with a few adte byte in content. Can we change it?
>
>Thanks,
>
>Martin Chan
>
>
>-
>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: MultipartPostMethod takes long time to execute

[Martin Chan]

Thanks Ortwin, I added "filePost.setUseExpectHeader(false);" and it works.

Ortwin Glück wrote:

Martin Chan wrote:

Hi,

I use MultipartPostMethod to do upload, but I found that it takes 3-4
seconds to execute even for a very small file (<1KB).
int status = httpClient.executeMethod(filePost);
Does anyone have the same problem? How to improve the speed?

I also found that the HttpClient fragment the post method to many
packets, each with a few adte byte in content. Can we change it?
Thanks,

Martin Chan


This can have two reasons:

- When TCP_NODELAY is set and the data is delivered to slow, the data 
may fragment more than with TCP_NODELAY disabled.

- There can be a wait time involved due to 100-Continue handshake. Try 
and disable 100-Continue handshake.

-
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: MultipartPostMethod takes long time to execute

[Kalnichevski, Oleg]

Martin, 
I suppose you are running HttpClient 2.0alpha3 which is known to have a few issues 
with 'expect: 100-continue' handshake. Please upgrade to 2.0beta1. If the problem 
still persists after the upgrade, please follow the instructions of the trouble 
shooting guide:

http://jakarta.apache.org/commons/httpclient/troubleshooting.html

Oleg 

-Original Message-
From: Martin Chan [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2003 09:02
To: [EMAIL PROTECTED]
Subject: MultipartPostMethod takes long time to execute


Hi,

I use MultipartPostMethod to do upload, but I found that it takes 3-4
seconds to execute even for a very small file (<1KB).
int status = httpClient.executeMethod(filePost);

Does anyone have the same problem? How to improve the speed?


I also found that the HttpClient fragment the post method to many
packets, each with a few adte byte in content. Can we change it?

Thanks,

Martin Chan


-
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: MultipartPostMethod takes long time to execute

[Ortwin Glück]

Martin Chan wrote:
Hi,

I use MultipartPostMethod to do upload, but I found that it takes 3-4
seconds to execute even for a very small file (<1KB).
int status = httpClient.executeMethod(filePost);
Does anyone have the same problem? How to improve the speed?

I also found that the HttpClient fragment the post method to many
packets, each with a few adte byte in content. Can we change it?
Thanks,

Martin Chan
This can have two reasons:

- When TCP_NODELAY is set and the data is delivered to slow, the data 
may fragment more than with TCP_NODELAY disabled.

- There can be a wait time involved due to 100-Continue handshake. Try 
and disable 100-Continue handshake.

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

Re: Https, ProxyAuthentication and HttpClient

[Ortwin Glück]

You should be aware of this bug as well:

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

Workarounds are proposed in the bug notes.

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

Re: [VOTE] nominate Adrian Sutton for committer status

[Ortwin Glück]

+1

Adrian's work is excellent.

Michael Becke wrote:

Adrian Sutton has been an active contributor to HttpClient for some time 
now.  He has been a consistent and reliable contributor, and in 
particular his work with NTLM and the developer documentation has been 
invaluable.

I would like to nominate Adrian Sutton for HttpClient committer status.

Please vote as follows:
+1 = Yes
0 = abstain
-1 = no
Mike

-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]
--
_
 NOSE applied intelligence ag
   [www]  http://www.nose.ch
 ortwin glück  [email] [EMAIL PROTECTED]
 hardturmstrasse 171   [pgp key]  0x81CF3416
 8005 zurich   [office]  +41-1-277 57 35
 switzerland   [fax] +41-1-277 57 12
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

MultipartPostMethod takes long time to execute

[Martin Chan]

Hi,

I use MultipartPostMethod to do upload, but I found that it takes 3-4
seconds to execute even for a very small file (<1KB).
int status = httpClient.executeMethod(filePost);

Does anyone have the same problem? How to improve the speed?


I also found that the HttpClient fragment the post method to many
packets, each with a few adte byte in content. Can we change it?

Thanks,

Martin Chan


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

Re: [VOTE] nominate Adrian Sutton for committer status

[Oleg Kalnichevski]

+1 

Oleg

On Mon, 2003-06-02 at 04:29, Michael Becke wrote:
> Adrian Sutton has been an active contributor to HttpClient for some 
> time now.  He has been a consistent and reliable contributor, and in 
> particular his work with NTLM and the developer documentation has been 
> invaluable.
> 
> I would like to nominate Adrian Sutton for HttpClient committer status.
> 
> Please vote as follows:
> +1 = Yes
> 0 = abstain
> -1 = no
> 
> Mike
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

Re: Java can leak...

[Brett Knights]

A useful profiler is included with the JSDK. Just check the
documentation for the java -Xrunhprof option.

HTH

Brett Knights


- Original Message - 
From: "Jan Gonsalves" <[EMAIL PROTECTED]>
To: "Commons HttpClient Project"
<[EMAIL PROTECTED]>
Sent: Thursday, May 29, 2003 5:45 PM
Subject: Re: Java can leak...


> We need to do more investigation on our side for sure, I just wanted
to
> know if anyone had noticed memory leaks over long recycled
connections.
> The JVM my app runs in alots 768Mb as the max, but I work in
conjunction
> with serveral apps.  I'm the only app using HttpClient.  When I run
and
> I really get going processing large chunks of data memory usage for
the
> system really takes a hit.  My personal memory footprint based off
qps
> for linux says I max out at about 380mb.  If I loose a reference to
an
> object ROOT has, does that count against my memory usage or does
that
> consume memory but no under a particular JVM?
>
> My personal belief is that my app does things a new way in our
system
> and I'm putting stress on other objects in the system that aren't
> normally accustomed to it and they are having difficulty.  Anyone
know
> of a good, user friendly (read inexperienced to memory profilling)
> application?
>
> Jan
>
> Michael Becke wrote:
>
> > My impression of your first email was that the server had used up
the
> > 4GB of memory.  Are you saying it was HttpClient?  If so, you must
> > have run the JVM and specified the max heap size to something like
> > -Xmx4GB.  If that's the case then this is probably something you
don't
> > want to do.  Once Java gets over the minimum heap size, specified
by
> > -Xms, it will continue to expand all the way up to the max, even
if it
> > doesn't need to.  Once the JVM allocates memory to the heap it
never
> > releases it.  Is this what's happening?
> >
> > Mike
> >
> > On Thursday, May 29, 2003, at 06:09 PM, Jan Gonsalves wrote:
> >
> >> Oleg,
> >>
> >> I understand what you mean my mem alloc, but Java can leak, it's
a
> >> proven fact.  Anytime ROOT has a reference to something it makes
it
> >> unable to GC, however, if you loose your reference and ROOT still
has
> >> it's, that's a memory leak.  ROOT will never GC that memory.  Ask
> >> youself this, if Memory leaks were impossible in JAVA, how can
> >> programs such as JProfiler or OptimizIt sell?
> >>
> >> Jan
> >>
> >> Oleg Kalnichevski wrote:
> >>
> >>> Jan,
> >>>
> >>> HttpClient is a pure Java application and as such does not
manage
> >>> memory
> >>> allocation directly. I suggest that you check if there are any
known
> >>> issues with the jvm you are using. Upgrading to HttpClient
beta-1 would
> >>> not hurt, anyways.
> >>>
> >>> Oleg
> >>>
> >>>
> >>> On Thu, 2003-05-29 at 16:36, Jan Gonsalves wrote:
> >>>
>  Does anyone know of any memory issues with opening a connection
and
>  continuely re-using it, only closing it when a socket timeout
>  happens? I'm currently using ALPHA 3.  I have to "fake out a
>  browser" and navigate through a website to extract information
>  because they don't offer a straight DB connection.  I re-use
this
>  connection the whole time, never closing it, only recycling it,
>  unless I get a socket timeout, ConnectionException, or
>  HTTPRecoverableException.  Our Production server has 4GB of
ram.
>  Last night we ran and the system went down to 4MB free, 4!  I'm
>  just wondering if I'm leaking due to HTTP Client.  I've gone
over
>  my stuff and it looks relatively solid, I'm wondering now if
I'm
>  using HttpClient incorrectly.  Does Beta 1 help with any memory
>  issues?
> 
>  Jan Gonsalves
> 
> 
>
 -

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



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

Re: [VOTE] nominate Adrian Sutton for committer status

[Michael Becke]

+1

On Sunday, June 1, 2003, at 10:29 PM, Michael Becke wrote:

Adrian Sutton has been an active contributor to HttpClient for some 
time now.  He has been a consistent and reliable contributor, and in 
particular his work with NTLM and the developer documentation has been 
invaluable.

I would like to nominate Adrian Sutton for HttpClient committer status.

Please vote as follows:
+1 = Yes
0 = abstain
-1 = no
Mike

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



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

[VOTE] nominate Adrian Sutton for committer status

[Michael Becke]

Adrian Sutton has been an active contributor to HttpClient for some 
time now.  He has been a consistent and reliable contributor, and in 
particular his work with NTLM and the developer documentation has been 
invaluable.

I would like to nominate Adrian Sutton for HttpClient committer status.

Please vote as follows:
+1 = Yes
0 = abstain
-1 = no
Mike

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

Re: [ANNOUNCE] Release of Commons HttpClient 2.0 Beta 1

[Michael Becke]

Thank you for the support.  The jar appears to be on ibiblio now.  I'm 
looking in http://www.ibiblio.org/maven/commons-httpclient/jars/.  
Thank you for spotting the error in downloads.html.  It will be fixed 
when the site is next published.

Mike

On Sunday, June 1, 2003, at 08:37 PM, Tetsuya Kitahata wrote:

Congratulations, Mike and all of HttpClient team.

When will it be relected to ibiblio?

And (IMHO) it is better to rewrite
http://jakarta.apache.org/commons/httpclient/downloads.html

commons-httpclient
2.0-alpha3
http://jakarta.apache.org/commons/httpclient/

to


commons-httpclient
2.0-beta1
http://jakarta.apache.org/commons/httpclient/

Again, congratulations!!

--

On Sun, 1 Jun 2003 18:44:37 -0400
(Subject: [ANNOUNCE] Release of Commons HttpClient 2.0 Beta 1)
Michael Becke <[EMAIL PROTECTED]> wrote:
The Jakarta Commons HttpClient team is proud to announce the release 
of
HttpClient 2.0 beta 1.  This is the first feature complete release of
HttpClient 2.0.  The focus for the rest of the 2.0 development will be
on bug fixes and documentation.  Please visit the HttpClient website
(http://jakarta.apache.org/commons/httpclient/) and download this
latest release.

The following changes have been made since Alpha 3:

  * Changed HttpConnection to use socket timeout instead of busy
waiting while expecting input.
  * Added a getResponseContentLength() method to HttpMethod.

  * Changed HttpClient to accept correctly encoded URLs instead of
attempting to encode them within HttpClient.
  * 'Expect: 100-continue' logic factored out into an abstract
ExpectContinueMethod class
  * 'Expect: 100-Continue' handshake disabled per default, as it may 
not
work
properly with older HTTP/1.0 servers or proxies.

  * Reengineered authentication code.  This includes a fix for
HttpClient continually attempting to authenticate to digest realms
and
provides for better future extensibility.
  * Authenticator class deprecated

  * Improved user documentation and example code.

  * Added ability to differentiate between different hosts using the
same realm names.
  * Added support for specifying a virtual host name to use.

  * Fixed problem with half-closed connections causing a
HttpRecoverableException to be thrown when HttpClient attempts to
read
from a socket.
  * Improved reliability with the HEAD method and servers that
incorrectly include a response body.
  * Improved support for connection keep-alive when communicating via 
a
proxy

  * Added an override of HttpClient.executeMethod that lets the
caller specify an HttpState object.
  * HttpConnectionManager is now a property of the HttpClient class,
not of the HttpState class
  * Added ability to specify the local address that HttpClient should
create connections from.
Thank you,

Commons HttpClient Development Team

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Tetsuya Kitahata --  Terra-International, Inc.
E-mail: [EMAIL PROTECTED]
http://www.terra-intl.com/
(Apache Jakarta Translation, Japanese)
http://jakarta.terra-intl.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: [ANNOUNCE] Release of Commons HttpClient 2.0 Beta 1

[Tetsuya Kitahata]

(BCongratulations, Mike and all of HttpClient team.
(B
(BWhen will it be relected to ibiblio?
(B
(BAnd (IMHO) it is better to rewrite
(Bhttp://jakarta.apache.org/commons/httpclient/downloads.html
(B
(B
(Bcommons-httpclient
(B2.0-alpha3
(Bhttp://jakarta.apache.org/commons/httpclient/
(B
(B
(Bto
(B
(B
(Bcommons-httpclient
(B2.0-beta1
(Bhttp://jakarta.apache.org/commons/httpclient/
(B
(B
(B
(BAgain, congratulations!!
(B
(B--
(B
(BOn Sun, 1 Jun 2003 18:44:37 -0400
(B(Subject: [ANNOUNCE] Release of Commons HttpClient 2.0 Beta 1)
(BMichael Becke <[EMAIL PROTECTED]> wrote:
(B
(B> The Jakarta Commons HttpClient team is proud to announce the release of 
(B> HttpClient 2.0 beta 1.  This is the first feature complete release of 
(B> HttpClient 2.0.  The focus for the rest of the 2.0 development will be 
(B> on bug fixes and documentation.  Please visit the HttpClient website 
(B> (http://jakarta.apache.org/commons/httpclient/) and download this 
(B> latest release.
(B> 
(B> The following changes have been made since Alpha 3:
(B> 
(B>   * Changed HttpConnection to use socket timeout instead of busy
(B> waiting while expecting input.
(B> 
(B>   * Added a getResponseContentLength() method to HttpMethod.
(B> 
(B>   * Changed HttpClient to accept correctly encoded URLs instead of
(B> attempting to encode them within HttpClient.
(B> 
(B>   * 'Expect: 100-continue' logic factored out into an abstract
(B> ExpectContinueMethod class
(B> 
(B>   * 'Expect: 100-Continue' handshake disabled per default, as it may not 
(B> work
(B> properly with older HTTP/1.0 servers or proxies.
(B> 
(B>   * Reengineered authentication code.  This includes a fix for
(B> HttpClient continually attempting to authenticate to digest realms 
(B> and
(B> provides for better future extensibility.
(B> 
(B>   * Authenticator class deprecated
(B> 
(B>   * Improved user documentation and example code.
(B> 
(B>   * Added ability to differentiate between different hosts using the
(B> same realm names.
(B> 
(B>   * Added support for specifying a virtual host name to use.
(B> 
(B>   * Fixed problem with half-closed connections causing a
(B> HttpRecoverableException to be thrown when HttpClient attempts to 
(B> read
(B> from a socket.
(B> 
(B>   * Improved reliability with the HEAD method and servers that
(B> incorrectly include a response body.
(B> 
(B>   * Improved support for connection keep-alive when communicating via a 
(B> proxy
(B> 
(B>   * Added an override of HttpClient.executeMethod that lets the
(B> caller specify an HttpState object.
(B> 
(B>   * HttpConnectionManager is now a property of the HttpClient class,
(B> not of the HttpState class
(B> 
(B>   * Added ability to specify the local address that HttpClient should
(B> create connections from.
(B> 
(B> Thank you,
(B> 
(B> Commons HttpClient Development Team
(B> 
(B> 
(B> -
(B> To unsubscribe, e-mail: [EMAIL PROTECTED]
(B> For additional commands, e-mail: [EMAIL PROTECTED]
(B
(B-
(BTetsuya Kitahata --  Terra-International, Inc.
(BE-mail: [EMAIL PROTECTED]
(Bhttp://www.terra-intl.com/
(B(Apache Jakarta Translation, Japanese)
(Bhttp://jakarta.terra-intl.com/
(B
(B
(B-
(BTo unsubscribe, e-mail: [EMAIL PROTECTED]
(BFor additional commands, e-mail: [EMAIL PROTECTED]

[ANNOUNCE] Release of Commons HttpClient 2.0 Beta 1

[Michael Becke]

The Jakarta Commons HttpClient team is proud to announce the release of 
HttpClient 2.0 beta 1.  This is the first feature complete release of 
HttpClient 2.0.  The focus for the rest of the 2.0 development will be 
on bug fixes and documentation.  Please visit the HttpClient website 
(http://jakarta.apache.org/commons/httpclient/) and download this 
latest release.

The following changes have been made since Alpha 3:

 * Changed HttpConnection to use socket timeout instead of busy
   waiting while expecting input.
 * Added a getResponseContentLength() method to HttpMethod.

 * Changed HttpClient to accept correctly encoded URLs instead of
   attempting to encode them within HttpClient.
 * 'Expect: 100-continue' logic factored out into an abstract
   ExpectContinueMethod class
 * 'Expect: 100-Continue' handshake disabled per default, as it may not 
work
   properly with older HTTP/1.0 servers or proxies.

 * Reengineered authentication code.  This includes a fix for
   HttpClient continually attempting to authenticate to digest realms 
and
   provides for better future extensibility.

 * Authenticator class deprecated

 * Improved user documentation and example code.

 * Added ability to differentiate between different hosts using the
   same realm names.
 * Added support for specifying a virtual host name to use.

 * Fixed problem with half-closed connections causing a
   HttpRecoverableException to be thrown when HttpClient attempts to 
read
   from a socket.

 * Improved reliability with the HEAD method and servers that
   incorrectly include a response body.
 * Improved support for connection keep-alive when communicating via a 
proxy

 * Added an override of HttpClient.executeMethod that lets the
   caller specify an HttpState object.
 * HttpConnectionManager is now a property of the HttpClient class,
   not of the HttpState class
 * Added ability to specify the local address that HttpClient should
   create connections from.
Thank you,

Commons HttpClient Development Team

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

DO NOT REPLY [Bug 10809] - Developer documentation

[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=10809

Developer documentation





--- Additional Comments From [EMAIL PROTECTED]  2003-06-01 18:55 ---
The cookie docs and the updated troubleshooting have been committed.  I love 
"Specifying the 
Specification" :)

Mike

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

Re: HttpClient Powered

[Michael Becke]

Done.  Mule will be included the next time the HttpClient site is 
published.

Mike

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

HttpClient Powered

[Ross Mason]

Hi,

 

Great product! We've just started using it to implement all http
connectivity in Mule (see http://mule.sourceforge.net
  ).  Could you put us on you're HttpClient
Powered page as - 

 

Mule - Universal Message Objects

 

Mule is a robust and highly scalable broker and services ESB framework. It
is designed as a light-weight, event-driven component technology that
handles communication with disparate systems transparently providing a
simple component interface.

 

Thanks,

 

Ross