Maybe you can even alter the overall behaviour. The servlet can fork the
actual work to a new thread and immediately return. Then provide another
servlet that you can poll about the progress of your process.
-
To unsubscribe,
Hi Eric,
from RFC 2616 (HTTP 1.1), section 10.1:
A client MUST be prepared to accept one or more
1xx status responses prior to a regular response,
even if the client does not expect a 100 (Continue)
status message.
Our HTTP Client handles this correctly.
cheers,
Roland
Eric Johnson
Teemu,
We are aware that exception handling in the current stable version of HttpClient
leaves much more to be desired, but for API compatibility reasons, we can't change it.
Next major release of HttpClient will feature new exception handling framework. The
exception handling in HttpClient has
Folks,
Any objections to committing this one?
Oleg
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, January 16, 2004 15:38
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 15297] - [HttpClient] Authenticator() -
ability to perform alternate
Teemu,
This is the right place, no worries. It appears both 2.0 and HEAD exhibit the reported
problem. Do you want me to file a bug report on your behalf? Usually we prefer to have
a bugzilla ticket for all known bugs/feature requests, so the bug resolution audit
trail can be retained.
Oleg
Yep, if You can do it by my behalf it would be great :)
Otherwise I´ll have to try to familiarize myself with bugzilla..
- Teemu
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: 28. tammikuuta 2004 11:35
To: Commons HttpClient Project
Subject: RE: Bug in read
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26328.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26139.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15297.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26328.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26328.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Odi,
Fair enough. As to the documentation update, I believe we should wait until 3.0 API
freeze (beta 1). It's kind of pointless to start documenting stuff that has not gone
through alpha testing (read, I am too lazy to update documentation twice ;-)).
Oleg
-Original Message-
From:
Hey all,
I am experiencing very strange behavior using HttpClient over SSL, and
I wondered if someone could enlighten me as to how it works.
Basically, I have a small app that uses HttpClient to contact a web
server over https. What the app does is unimportant, but I have been
playing around
Brad O'Hearne wrote:
The results of this testing has put me into a state of confusion
regarding what httpclient's relationship is to the Java keystore.
I short: There is *no* relationship between HttpClient and the Java
keystore. HttpClient is completely unaware of the underlying SSL
The results of this testing has put me into a state of confusion
regarding what httpclient's relationship is to the Java keystore.
snip
Can someone clarify how HttpClient
works with respect to SSL, CA certs, server certs, and keystores?
Brad,
There's no _direct_ relationship between
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26499.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26328.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15297.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26499.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26500.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26499.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Eric,
Yes, we're using Maven, but it does not appear to handle this sort of
thing automatically. Any Maven experts out there know of a solution to
this one? I assume it can be done, but researching this one is pretty
low on my priority list :)
Mike
Eric Johnson wrote:
Mike,
The Ant task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15297.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
We seem to be having quite a variety of opinions here, but things do not
look any clearer to me.
Mike, Odi, please help. What do you see as a better place for
credentials callbacks: HttpState, HttpClientParams or something else?
Oleg
On Tue, 2004-01-27 at 07:13, [EMAIL PROTECTED] wrote:
DO
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26500.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
What do you need to do?
i.e. which goal produces your text files etc
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Michael Becke [EMAIL PROTECTED] wrote on 29/01/2004 08:37:34 AM:
Eric,
Yes, we're using Maven, but it does not appear to handle
Hi dIon,
If possible we'd like to make README, LICENSE, etc. have Windows EOLs
in the generated .zip distributions. Currently we use site:generate
and dist to build the HttpClient release. Any thoughts?
Thanks,
Mike
On Jan 28, 2004, at 9:40 PM, [EMAIL PROTECTED] wrote:
What do you need to
Howdy,
I have the example MultipartFileUploadApp working as an application.
When I try and do the same thing with an applet I can get everything to work
except setCredentials. (For testing I have allowed all in the java.policy
file)
If I put my user:pw in the url it works. That is
28 matches
Mail list logo
