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=17158.
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=17166.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi Vincent
HTTP spec defines two types of encoding: HTTP element encoding content
encoding. HTTP elements such as request line, status line,
request/response headers must be hard-coded in US-ASCII.
Request/response content encoding is not hard-coded and can be specified
by the HTTP agent by
Thanks Oleg. It does help a lot.
-Vincent
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]]
Sent: 19 February 2003 14:22
To: Commons HttpClient Project
Subject: Re: Cactus and HttpClient encoding issue
Hi Vincent
HTTP spec defines two types of encoding:
Could we provide the code below in some Utility function?
I guess this is convenient for people making Applets - although Applets
are generally a bad idea :-)
Sadly, this code will not work on OS X or most non-sun JREs. The location
of proxy information is very much platform, JVM and plugin
Adrian (and all)
I agree that with you about keeping HttpClient JVM independent and
reasonably generic. Clearly proxy detection should be kept outside
HttpClient package IMHO.
But you know what? Maybe HttpClient have matured well enough so that we
have reached the point where we should start
Sounds like a fine idea Oleg.
I agree we should probably look to other jakarta project for how they
handle this kind of thing. As you said Ant does this and I believe
Log4j does as well.
Mike
Oleg Kalnichevski wrote:
Adrian (and all)
I agree that with you about keeping HttpClient JVM
Hi Oleg and all,
I am using HttpClient for my diploma thesis and read this list for
two months now. I guess, there is really the demand for more optional
components around HttpClient, like:
- a Cache (mentioned a while ago on the list)
- Proxy-Detection
- Some kind of User-Agent on
Max Voelkel wrote:
- a Cache (mentioned a while ago on the list)
- Proxy-Detection
okay
- Some kind of User-Agent on top of HttpClient which:
- handles Framesets (return urls of subframes)
- possibly parses FORM-Tags
- eventually handles JavaScript-Code and
return
- a Cache (mentioned a while ago on the list)
A possibility, but likely more re-usable as a seperate project (there is
currently the beginnings of a cache in the sandbox, but appears idle)
- Proxy-Detection
Another possibility
- Some kind of User-Agent on top of HttpClient which:
Mike Becke has been an active contributor for many months. He has
worked on a diverse range of problems with high quality results. He has
been consistant, reliable, helpful and open to ideas and criticism.
There are many excellent contributors to HttpClient, but at this time I
would like to
+1
I do fully support Jeff's words!
Ortwin Glück
Jeffrey Dever wrote:
Mike Becke has been an active contributor for many months. He has
worked on a diverse range of problems with high quality results. He has
been consistant, reliable, helpful and open to ideas and criticism.
+1
-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
Sent: miércoles, 19 de febrero de 2003 18:28
To: Commons HttpClient Project
Subject: [VOTE] nominate Michael Becke as a committer
Mike Becke has been an active contributor for many months. He has
worked on a diverse
In general, I support anyone that wants to vote. Due to the structure
of Apache and Jakarta, only committer votes are binding so only these
votes are reported to the PMC and recorded.
If we get to a point where the committers disagree with the community as
a whole, then I want to know about
Hi,
I brought this up on the commons dev thread and forgot
to post the idea here.
You'll need to write your own implementation of the
SecureProtocolSocketFactory to replace the
SSLProtocolSocketFactory implementation. Add a
socketFactory argument to the constructor of this
class and use the
Yes, as Eric is saying you have to register your SSLSocketFactory with
HttpClient. To do this you have to register it with the Protocol class
using something like:
Protocol myHttpsProtocol = new Protocol(https, new
MySSLProtocolSocketFactory(), 443);
Protocol.registerProtocol(https,
There are some changes coming down the pipe for the structure of
Jakarta. I have not been involved in these types of discussions untill
now, and am still grappling with what is going on. The most immeadiate
issue is who is going to make up the PMC. The idea seems to be that all
committers
Adrian Sutton wrote:
Just run into a non-standards compliance problem with IIS proxies in certain
configurations. At times instead of returning a Connection: close header,
it returns a Proxy-connection: close header.
For what it's worth, I've noticed that Squid sometimes uses a
+1
And that is a VERY BIG PLUS ONE from me
Oleg
On Wed, 2003-02-19 at 18:28, Jeffrey Dever wrote:
Mike Becke has been an active contributor for many months. He has
worked on a diverse range of problems with high quality results. He has
been consistant, reliable, helpful and open to
Oleg et al,
I think this would be an excellent solution. Perhaps it could start out as
a useful tools and tips page? We could provide the code to detect proxy
settings in applets there as a start and am sure there's other stuff that
could be added as well?
Post 2.1 we could then expand this to
Great!
I also noticed that Sun's HttpsURLConnection class
allows you to specify a HostNameVerifier. I'm not
really sure how this works but it might be worth
thinking about including in httpclient.
Eric
--- Michael Becke [EMAIL PROTECTED] wrote:
Attached is a patch that adds an
+1
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Armando Anton [EMAIL PROTECTED] wrote on 20/02/2003 04:51:47
AM:
+1
-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
Sent:
Adrian Sutton wrote:
Do you have any idea how to make squid use that header?
I don't think we're doing anything special to make it happen. Here are
the headers from a couple of typical transaction, with a few host names
slightly obscured. This is using my own Java-based caching code on top
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=13463.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Patch committed.
Aurelien Pernoud wrote:
10 users using 5 requests (no cache implemented for this test), I have some
recoverable exception, but no errors at all !
Nice work ;)
I'll try it later on a real server with more users cause here I was limited
with total connections allowed by my
In a very large project I am a senior on, I use to be using HTTPClient v0.3-3
(www.innovation.ch/java/HTTPClient/).
b) After looking at the code to try to fix the problem, not only did I give up
trying to fix the problem, but I also gave up on the product :)
Yes, I went through exactly the
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=10809.
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=10809.
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=17166.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
29 matches
Mail list logo
