Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 41800 invoked from network); 27 Jun 2002 05:32:25 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by 209.66.108.5 with SMTP; 27 Jun 2002 05:32:25 -0000 Received: (qmail 13452 invoked by uid 97); 27 Jun 2002 05:32:30 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 13412 invoked by uid 97); 27 Jun 2002 05:32:30 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 13400 invoked by uid 98); 27 Jun 2002 05:32:29 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Subject: Re: [httpclient] Volunteering to add support for PROXY AUTH andSTREAMING INPUT for POST requests From: Evert Hoff To: Jakarta Commons Developers List In-Reply-To: <021801c21d57$20a6ae70$820a0a0a@FWPC304> References: <3D19DA01.2020102@nose.ch> <1025108485.12583.23.camel@localhost.localdomain> <021801c21d57$20a6ae70$820a0a0a@FWPC304> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.7 Date: 27 Jun 2002 06:50:57 +0200 Message-Id: <1025153458.12599.37.camel@localhost.localdomain> Mime-Version: 1.0 X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N Hi, I have the same requirement. The patch that I sent yesterday includes a setter for SSLSocketFactory in HttpMultiClient. I have preferred not to make it a static, because someone somewhere someday might have a requirement to run different instances HttpMultiClient that each uses a different factory. The setter in HttpMultiClient just calls the same setter in HttpConnectionManager which in turn creates HttpConnections with this factory. Evert On Wed, 2002-06-26 at 23:19, Simon Roberts wrote: > Hi guys, >=20 > I've got a patch that I've been using myself, but it might be of some use= to > others. Or (better!) perhaps someone could tell me a way around my need f= or > it! If they do, I'll document it for USING_HTTPS.txt :) >=20 > The (fugly) patch makes HttpConnection use a static to find a > SSLSocketFactory, rather than using SSLSocketFactory.getDefault. The rea= son > is that the US-export version of JSSE doesn't allow the users to override > the implementation created by SSLSocketFactory.getDefault(). >=20 > The default implementation (of SSLSocketFactory) can be configured by > setting a few system/security properties, such as "javax.net.ssl.keyStore= " > etc, but we need to be able to use a different trustmanager (our acceptan= ce > of server certs is more involved than certificate chains). There is a > security property "sun.ssl.keymanager.type" which can be used to set the > default keymanager algorithm, but I can't figure out how to register my o= wn > KeyManager against that name. Help! >=20 > See > http://java.sun.com/products/jsse/doc/guide/API_users_guide.html#Installa= tio > nAndCustomization >=20 > I'd love to hear if anyone knows about registering KeyManager algorithms,= or > wants my fugly patch. >=20 > Cheers, Simon >=20 > ----- Original Message ----- > From: "Evert Hoff" > Newsgroups: gmane.comp.jakarta.commons.devel > Sent: Thursday, June 27, 2002 4:21 AM > Subject: Re: [httpclient] Volunteering to add support for PROXY AUTH > andSTREAMING INPUT for POST requests >=20 >=20 > Hi Ortwin, >=20 > Please have a look at the patch that I sent on 13 June. It includes > changes sent by Sachin on June 12. My part of the code is still > untested, because I am still trying to get access to an authenticated > proxy server that supports HTTPS that I can test with. >=20 > Your proposed changes sound great to me. >=20 > I am not a committer on this project, so I can't give you the assurance > that your changes will be incorporated. I don't think anyone would give > you such an assurance before seeing the final product. But, on the > bright side, I doubt if your changes will be turned down, because they > are useful and well thought through. >=20 > Regards, >=20 > Evert >=20 > On Wed, 2002-06-26 at 17:13, Ortwin Gl=FCck wrote: > > Hello > > > > Our company would like to help in the HttpClient project. > > > > We wish to add the following features: > > > > ______________________________________ > > 1. Support for authenticating proxies > > > > The HttpClient currently only supports authentication against the web > > server but not against the proxy. > > > > We hereby suggest to change the API as follows: > > > > HttpState: > > - add field: proxyCredentials > > - add setter method for proxyCredentials > > We could have used the existing credential map. But we prefer to > > create a separate field for two reasons: > > - proxy auth uses different HTTP Headers than WWW Auth. So we want > > to avoid mixing up www auth and proxy auth. > > - A connection can only have one proxy. Its realm is not relevant > > and in most cases not known to the programmer anyway. > > > > - change HttpMethodBase.execute > > Include a case for the SC_PROXY_AUTHENTICATION_REQUIRED status code > > which performs proxy authentication > > > > - change Authenticator.authenticate > > Include proxy auth > > > > The changes leave the HttpClient compatible with previous versions. > > > > _________________________________________________ > > 2. Support for streaming input for POST requests > > > > The HttpClient currently only accepts Strings as the body of a POST > > request. This is not suitable for applications like upload of huge file= s > > or binary data. Moreover buffering the whole request in memory is > > problematic when dealing with large amounts of data. > > > > We hereby suggest to change the API as follows: > > > > PostMethod: > > - add setContentLength(int) > > A convenience method to add the content length header directly or in > > an indirect fashion. See below. > > > > - add int constants CONTENT_LENGTH_AUTO =3D 0, CONTENT_LENGTH_CHUNKED = =3D -1 > > They are used with setContentLength > > > > - add setRequestBody(InputStream) > > The stream is handled depending on the argument of setContentLength. > > If the content length was set to CONTENT_LENGTH_AUTO or the content > > length was not set at all, the input is buffered and the correct conten= t > > length is calculated automatically. If content length was set to > > CONTENT_LENGTH_CHUNKED the stream is not buffered and sent with chunked > > transfer encoding (note that chunked POST is not widely supported by we= b > > servers, but it works okay with Tomcat and actually defined in rfc > > 2068). If content length was set to anything else the stream is not > > buffered and the content length will be used as set by the user. If > > however the stream ends before that length, an IOException is thrown (i= n > > HttpClient.executeMethod). > > This enables POSTing of large files without the need to buffer the > > data in memory thus beeing more conservative on memory. More complex > > data structures (like Multipart MIME, Base64 encoded data) can be > > wrapped in a user defined input stream which is then passed to the HTTP > > client. > > > > - deprecate setRequestBody(String) because it is dangerous > > The platform's default character encoding is used here. This is bad > > for portability. Have a Mac OS-X and a Windows client talk to a Linux > > Server and you will be messing up data completely. When writing to a > > network connection only byte data should be used and not strings that > > are implicitely encoded. > > > > > > We need these features for one of our projects. Please let us know if > > you will incorporate these feature into the current code base if we > > submit a patch. > > > > Best regards > > > > Ortwin Glueck > > > > -- > > _________________________________________________________________ > > NOSE applied intelligence ag [perspectix-nose digital b.i] > > [www] http://www.nose.ch > > ortwin gl=FCck [email] ortwin.glueck@nose.ch > > hardturmstrasse 171 [office] +41-1-277 57 35 > > 8005 zurich [fax] +41-1-277 57 12 > > switzerland > > > > > > > > -- > > To unsubscribe, e-mail: > > > For additional commands, e-mail: > > > >=20 >=20 > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.371 / Virus Database: 206 - Release Date: 16/06/2002 >=20 >=20 > -- > To unsubscribe, e-mail: > For additional commands, e-mail: >=20 -- To unsubscribe, e-mail: For additional commands, e-mail: