You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Dirk Verbeeck <di...@pandora.be> on 2001/11/06 21:45:05 UTC
Re: SSL support in webdav client library
Hi Ian
I made the changes in the code where you indicated but in a different
way. I used reflection for the SSLSocket and check the port number for
copy and move method.
Can you test/fix my changes and let me know if it works?
Thanks,
Dirk
"Ian Kallen " wrote:
>
> Wow, the enthusiastic response so was overwhelming :) I've attached a
> patch that enables SLIDE_1_0_15 to use SSL, there might be other places
> besides copyMethod() and moveMethod() that need to have the hardcoded
> scheme "http://" factored out of the Destination header generation but
> that's all I've noticed so far.
>
> Note: I used the same method of SSLSockets in HttpClient that is used in
> jakarta-commons' HttpClient -- my local tests included hacks to circumvent
> the TrustManager issues stemming from self signed certificates (without a
> KeyStore and using keytool to muck with the KeyStore
> contents). Ultimately, I think the HttpClient code is going to need some
> refactoring to deal with the different ways sockets can be generated more
> flexibly, but that's another, probably longer, conversation...
>
> On Tue, 30 Oct 2001, Ian Kallen <ia...@covalent.net> wrote:
>
> >
> > There's more to fixing the ssl support than this. For instance, the COPY
> > and MOVE methods' headers generated by
> > WebdavResource.copyMethod(src,dest)
> > WebdavResource.moveMethod(src, dest)
> >
> > Includes
> > Destination: http//host:port/dest
> > ^^^^
> > That this is not https is a 502 Bad Gateway error. I pulled the
> > SLIDE_1_0_15 tag (sorry, last few times I pulled HEAD, it didn't build,
> > so I gave up on it) to work against, those methods have
> > "http://" hardcoded in :(
> >
> > The fix that I'm implementing will have a flag set similar to HttpClient
> > in WebdavResource that in turn can be propagated, to the Copy/MoveMethod
> > classes as well as HttpClient. This will just be in the constructor, to
> > be consistent with the HttpClient implementation. I'm using the HttpClient
> > in that tree, not the one in the jakarta-commons tree (there seems to be a
> > minor fork in there).
> >
> > Any objections to fixing it in this manner? If not, I should have patches
> > a little later today. The patches would be against the SLIDE_1_0_15 tag
> > though, someone else with commit access and an eye on the commit mails can
> > assess the work to patch HEAD.
> >
> > thanks!
> >
> > On Mon, 1 Oct 2001, Remy Maucherat wrote:
> >
> > > > That exactly is the problem. After I uncomment the SSLSocketFactory
> > > > code. My test program for SSL works.
> > > > This requires to import javas.net.ssl.* for the HttpClient class. Should
> > > > this fix be in the coming beta?
> > >
> > > Yes, but it is already, AFAIK.
> > > Although I didn't remove the source files yet, we should be back to be using
> > > the HTTP client soon-to-be 1.0 from jakarta-commons (which includes the SSL
> > > code). I'll try to release that one in sync for the beta.
> > >
> > > Remy
> > >
> > >
> >
> > cheers,
> > -Ian
> >
> > --
> > Ian Kallen <ia...@covalent.net> | AIM: iankallen
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
> cheers,
> -Ian
>
> --
> Ian Kallen <ia...@covalent.net> | AIM: iankallen
>
> ------------------------------------------------------------------------
> Name: jakarta-slide-SLIDE_1_0_15-enable_ssl.patch
> jakarta-slide-SLIDE_1_0_15-enable_ssl.patch Type: Plain Text (TEXT/PLAIN)
> Encoding: BASE64
>
> ------------------------------------------------------------------------
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
Slide 1.0.16 and Slide 1.0 branch
Posted by Remy Maucherat <rm...@home.com>.
Hi,
I'm tagging the CVS later this evening. I'll only make the binaries
available tomorrow or the day after, so please try to do a final testing
round if you can (I'll do that myself).
The tag for Slide 1.0.16 is "SLIDE_1_0_16".
The tag for the Slide 1.0 maintenance branch (ie, Slide 1.0.17 and
subsequent releases - if needed, of course) is "SLIDE_1_0". Check it out if
you're interested in maintaining Slide 1.0.
New features development should happen in the CVS HEAD branch.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CVS updates
Posted by Sung-Gu <je...@hoonsecure.com>.
Hi guys,
My vote +1 :)
Sung-Gu
----- Original Message -----
From: "Dirk Verbeeck" <di...@pandora.be>
To: "Slide Developers List" <sl...@jakarta.apache.org>
Sent: Thursday, November 08, 2001 4:34 AM
Subject: Re: CVS updates
> Hi guys,
>
> Great work, the last blocking item is fixed...
> I think slide 1.0.16 is ready for prime time ;-)
>
>
> Dirk
>
>
>
> Remy Maucherat wrote:
> >
> > > Remy Maucherat wrote:
> > > >
> > > > Hi Dirk and Michael,
> > > >
> > > > Do the updates I made this WE fix the problems you found ?
> > > > The example behaves much better now, so the issue might have been fixed.
> > > >
> > > > Can you confirm that ?
> > > >
> > > > If that's the case, I will proceed with the release of 1.0.16.
> > > >
> > > > Remy
> > >
> > >
> > > Looks good to me - been running a heavy stress test here for a few
> > > hours, haven't been any apparent problems so far. (note that my local
> > > copy still has those methods changed to synchronized - I can rebuild and
> > > test with those removed tonight or tomorrow if you think that'd be
> > > useful).
> >
> > Thanks for the feedback.
> >
> > > Thanks a lot Remy - your help has been invaluable.
> >
> > Dirk's test case was extremely useful too.
> >
> > > My vote's +1 on release now, since I can't easily kill slide any more
> > > :-)
> >
> > Thanks :-)
> >
> > Remy
Re: CVS updates
Posted by Dirk Verbeeck <di...@pandora.be>.
Hi guys,
Great work, the last blocking item is fixed...
I think slide 1.0.16 is ready for prime time ;-)
Dirk
Remy Maucherat wrote:
>
> > Remy Maucherat wrote:
> > >
> > > Hi Dirk and Michael,
> > >
> > > Do the updates I made this WE fix the problems you found ?
> > > The example behaves much better now, so the issue might have been fixed.
> > >
> > > Can you confirm that ?
> > >
> > > If that's the case, I will proceed with the release of 1.0.16.
> > >
> > > Remy
> >
> >
> > Looks good to me - been running a heavy stress test here for a few
> > hours, haven't been any apparent problems so far. (note that my local
> > copy still has those methods changed to synchronized - I can rebuild and
> > test with those removed tonight or tomorrow if you think that'd be
> > useful).
>
> Thanks for the feedback.
>
> > Thanks a lot Remy - your help has been invaluable.
>
> Dirk's test case was extremely useful too.
>
> > My vote's +1 on release now, since I can't easily kill slide any more
> > :-)
>
> Thanks :-)
>
> Remy
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CVS updates
Posted by Remy Maucherat <rm...@home.com>.
> Hi, Remy,
>
> This problem is not totally fixed yet. I get the latest codes (an hour
ago)
> and buid it. I run the multithread test with both Oracle discriptor and
> content stores. In TestThread.java, I changed the count to 100 from 10.
Then
> I got the following errors:
That was not the problem which was fixed, which was a more general bug in
the transaction manager, where it could have ended in an incorrect state
after a failed enlist (bad).
I don't get the problems you describe with hSQL, so this looks more Oracle
specific.
> Thread-0: Put uri = /DOG65
> 07 Nov 2001 21:23:21 - slidestore.reference.JDBCDescriptorsStore - ERROR -
> java.
> sql.SQLException: ORA-01002: fetch out of sequence
>
> java.sql.SQLException: ORA-01002: fetch out of sequence
>
> at
oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
> at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
> at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
> at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
> at oracle.jdbc.ttc7.TTC7Protocol.fetch(TTC7Protocol.java:889)
> at
> oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.jav
> a:1681)
> at
> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStateme
> nt.java:1870)
> at
> oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePrepar
> edStatement.java:363)
> at
> oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePrepare
> dStatement.java:314)
> at
> slidestore.reference.JDBCDescriptorsStore.retrieveObject(JDBCDescript
> orsStore.java:593)
> at
> org.apache.slide.store.StandardStore.retrieveObject(StandardStore.jav
> a:171)
> at
> org.apache.slide.security.SecurityImpl.getPrincipal(SecurityImpl.java
> :765)
> at
> org.apache.slide.security.SecurityImpl.checkCredentials(SecurityImpl.
> java:378)
> at
> org.apache.slide.structure.StructureImpl.create(StructureImpl.java:34
> 4)
> at multithread.TestThread.run(TestThread.java:129)
> at java.lang.Thread.run(Thread.java:484)
> 07 Nov 2001 21:23:21 - org.apache.slide.common.Domain - WARNING - Service
> slides
> tore.reference.JDBCDescriptorsStore@2786c3 access error : ORA-01002: fetch
> out o
> f sequence
>
> >>>> org.apache.slide.common.ServiceAccessException: Service
> slidestore.referenc
> e.JDBCDescriptorsStore@2786c3 access error : ORA-01002: fetch out of
> sequence
>
> In the test, there are 200 PUT operations. Above error happens twice.
> There is a race condition there. The two threads share the same database
> connection at same time. It is much better than before. But you still can
> see it happen.
>
> Also, I got lots of followin errors:
>
> Thread-0: Put uri = /DOG99
> 07 Nov 2001 21:24:01 - org.apache.slide.common.Domain - WARNING - Service
> jdbc(o
> rg.apache.slide.store.StandardStore) access error : Failed to enlist
service
> sli
> destore.reference.JDBCDescriptorsStore@2786c3 in active transaction
> >>>> org.apache.slide.common.ServiceAccessException: Service
> jdbc(org.apache.sli
> de.store.StandardStore) access error : Failed to enlist service
> slidestore.refer
> ence.JDBCDescriptorsStore@2786c3 in active transaction
> Thread-1: Put uri = /KAT87
> 07 Nov 2001 21:24:01 - org.apache.slide.transaction.SlideTransaction -
> WARNING -
> Enlist failure: Resource manager
> slidestore.reference.JDBCDescriptorsStore@2786
> c3 Error code XAER_OUTSIDE in Transaction 191 xid
> Thread-1-1005197041098-191- in
> thread Thread-1
That's normal. Since the store isn't using a connection pool, it's limited
in what it can do concurrently. The XAER_OUTSIDE means the store / resource
manager was busy executing an update on behalf of another transaction.
Obviously, one of the first features which should be added to the 1.0 branch
is a connection pool based store.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: CVS updates
Posted by Ting Ning <ti...@yahoo.com>.
Hi, Remy,
This problem is not totally fixed yet. I get the latest codes (an hour ago)
and buid it. I run the multithread test with both Oracle discriptor and
content stores. In TestThread.java, I changed the count to 100 from 10. Then
I got the following errors:
Thread-0: Put uri = /DOG65
07 Nov 2001 21:23:21 - slidestore.reference.JDBCDescriptorsStore - ERROR -
java.
sql.SQLException: ORA-01002: fetch out of sequence
java.sql.SQLException: ORA-01002: fetch out of sequence
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
at oracle.jdbc.ttc7.TTC7Protocol.fetch(TTC7Protocol.java:889)
at
oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.jav
a:1681)
at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStateme
nt.java:1870)
at
oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePrepar
edStatement.java:363)
at
oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePrepare
dStatement.java:314)
at
slidestore.reference.JDBCDescriptorsStore.retrieveObject(JDBCDescript
orsStore.java:593)
at
org.apache.slide.store.StandardStore.retrieveObject(StandardStore.jav
a:171)
at
org.apache.slide.security.SecurityImpl.getPrincipal(SecurityImpl.java
:765)
at
org.apache.slide.security.SecurityImpl.checkCredentials(SecurityImpl.
java:378)
at
org.apache.slide.structure.StructureImpl.create(StructureImpl.java:34
4)
at multithread.TestThread.run(TestThread.java:129)
at java.lang.Thread.run(Thread.java:484)
07 Nov 2001 21:23:21 - org.apache.slide.common.Domain - WARNING - Service
slides
tore.reference.JDBCDescriptorsStore@2786c3 access error : ORA-01002: fetch
out o
f sequence
>>>> org.apache.slide.common.ServiceAccessException: Service
slidestore.referenc
e.JDBCDescriptorsStore@2786c3 access error : ORA-01002: fetch out of
sequence
In the test, there are 200 PUT operations. Above error happens twice.
There is a race condition there. The two threads share the same database
connection at same time. It is much better than before. But you still can
see it happen.
Also, I got lots of followin errors:
Thread-0: Put uri = /DOG99
07 Nov 2001 21:24:01 - org.apache.slide.common.Domain - WARNING - Service
jdbc(o
rg.apache.slide.store.StandardStore) access error : Failed to enlist service
sli
destore.reference.JDBCDescriptorsStore@2786c3 in active transaction
>>>> org.apache.slide.common.ServiceAccessException: Service
jdbc(org.apache.sli
de.store.StandardStore) access error : Failed to enlist service
slidestore.refer
ence.JDBCDescriptorsStore@2786c3 in active transaction
Thread-1: Put uri = /KAT87
07 Nov 2001 21:24:01 - org.apache.slide.transaction.SlideTransaction -
WARNING -
Enlist failure: Resource manager
slidestore.reference.JDBCDescriptorsStore@2786
c3 Error code XAER_OUTSIDE in Transaction 191 xid
Thread-1-1005197041098-191- in
thread Thread-1
Thanks,
Ting
-----Original Message-----
From: Remy Maucherat [mailto:rmaucher1@home.com]
Sent: Tuesday, November 06, 2001 11:07 PM
To: Slide Developers List
Subject: Re: CVS updates
> Remy Maucherat wrote:
> >
> > Hi Dirk and Michael,
> >
> > Do the updates I made this WE fix the problems you found ?
> > The example behaves much better now, so the issue might have been fixed.
> >
> > Can you confirm that ?
> >
> > If that's the case, I will proceed with the release of 1.0.16.
> >
> > Remy
>
>
> Looks good to me - been running a heavy stress test here for a few
> hours, haven't been any apparent problems so far. (note that my local
> copy still has those methods changed to synchronized - I can rebuild and
> test with those removed tonight or tomorrow if you think that'd be
> useful).
Thanks for the feedback.
> Thanks a lot Remy - your help has been invaluable.
Dirk's test case was extremely useful too.
> My vote's +1 on release now, since I can't easily kill slide any more
> :-)
Thanks :-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CVS updates
Posted by Remy Maucherat <rm...@home.com>.
> Remy Maucherat wrote:
> >
> > Hi Dirk and Michael,
> >
> > Do the updates I made this WE fix the problems you found ?
> > The example behaves much better now, so the issue might have been fixed.
> >
> > Can you confirm that ?
> >
> > If that's the case, I will proceed with the release of 1.0.16.
> >
> > Remy
>
>
> Looks good to me - been running a heavy stress test here for a few
> hours, haven't been any apparent problems so far. (note that my local
> copy still has those methods changed to synchronized - I can rebuild and
> test with those removed tonight or tomorrow if you think that'd be
> useful).
Thanks for the feedback.
> Thanks a lot Remy - your help has been invaluable.
Dirk's test case was extremely useful too.
> My vote's +1 on release now, since I can't easily kill slide any more
> :-)
Thanks :-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: CVS updates
Posted by Michael Smith <ms...@speedlegal.com>.
Remy Maucherat wrote:
>
> Hi Dirk and Michael,
>
> Do the updates I made this WE fix the problems you found ?
> The example behaves much better now, so the issue might have been fixed.
>
> Can you confirm that ?
>
> If that's the case, I will proceed with the release of 1.0.16.
>
> Remy
Looks good to me - been running a heavy stress test here for a few
hours, haven't been any apparent problems so far. (note that my local
copy still has those methods changed to synchronized - I can rebuild and
test with those removed tonight or tomorrow if you think that'd be
useful).
Thanks a lot Remy - your help has been invaluable.
My vote's +1 on release now, since I can't easily kill slide any more
:-)
Michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
CVS updates
Posted by Remy Maucherat <rm...@home.com>.
Hi Dirk and Michael,
Do the updates I made this WE fix the problems you found ?
The example behaves much better now, so the issue might have been fixed.
Can you confirm that ?
If that's the case, I will proceed with the release of 1.0.16.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SSL support in webdav client library
Posted by Dirk Verbeeck <di...@pandora.be>.
Updated, the http client always puts the scheme in the host parameter
now. This way you don't even have to analyse the host parameter, you can
just use it.
Hope this works.
Dirk
"Ian Kallen " wrote:
>
> Cool, I'll look for your updates.
>
> On Sun, 11 Nov 2001, Dirk Verbeeck wrote:
> > or encode everything in the same parameter ("host") just as port is now
> > encoded in the same parameter as the hostname.
> >
> > I would go for the second option, it requirs only 2 minor changes:
> > add "https://" to the host parameter in http client when needed
> > change the test in Copy/MoveMethod.
>
> cheers,
> -Ian
>
> --
> Ian Kallen <ia...@covalent.net> | AIM: iankallen
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SSL support in webdav client library
Posted by "Ian Kallen <iank@covalent.net>" <ia...@covalent.net>.
Cool, I'll look for your updates.
On Sun, 11 Nov 2001, Dirk Verbeeck wrote:
> or encode everything in the same parameter ("host") just as port is now
> encoded in the same parameter as the hostname.
>
> I would go for the second option, it requirs only 2 minor changes:
> add "https://" to the host parameter in http client when needed
> change the test in Copy/MoveMethod.
cheers,
-Ian
--
Ian Kallen <ia...@covalent.net> | AIM: iankallen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SSL support in webdav client library
Posted by Dirk Verbeeck <di...@pandora.be>.
Hi Ian,
Thanks for testing...
I didn't think about https on other ports.
I don't like that flag on Copy/MoveMethod because the information is
already available in the HttpClient object and should be passed on to
the Copy/MoveMethod just like header and port (they are both in the
host parameter).
We can do 2 things now, change generateHeaders to:
public void generateHeaders(String scheme, String host, int port,
State state)
or encode everything in the same parameter ("host") just as port is now
encoded in the same parameter as the hostname.
I would go for the second option, it requirs only 2 minor changes:
add "https://" to the host parameter in http client when needed
change the test in Copy/MoveMethod.
An update of the javadoc is also needed and also add a FIXME to indicate
when an interface change is needed in the future, the 4 parameter change
should be implemented.
Some of my other changes should also be reverted.
Regards
Dirk
"Ian Kallen " wrote:
>
> Hi Dirk,
> Your changes assume you can safely select the protocol based on the port
> number. This won't work because https, like http, can be purveyed across
> any free port -- some folks prefer port 8443 (like they do 8080 for http),
> my usage is grabs an obscure port to keep commonly used ports free for
> other purposes, I can continue with use cases for not doing it that way if
> you like but I think you get the point. Marrying protocol "https" to the
> port "443" is inadequate. My original intention was to set a flag so that
> when HttpClient needs to know what protocol to use, CopyMethod/MoveMethod
> need to generate Destination headers and anywhere else protocol awareness
> is needed, these could be set uniformly. If there's another consideration
> I should keep in mind design-wise, let me know and I'll re-think the
> patches I'd sent :)
>
> best,
> -Ian
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Experimenting with JMX
Posted by Remy Maucherat <rm...@home.com>.
Hi,
I've just added an experimental JMX wrapper which uses the modeler component
from the commons. I discovered it recently thourgh how it was used to
JMX-enable Catalina in an extreely easy and non-intrusive way. I used to
hate JMX because of the annoyance of implementing it, and the modeler solves
that problem.
I don't know if I changed the conditional compile rules the right way. The
Catalina wrapper should now require the JMX RI to build, but building should
be possible without it.
I also upgraded to the new Tomcat 4.1-dev code. I hope it doesn't cause
trouble for anyone (other than maybe change a bit the build environment).
The new Tomcat is more flexible when integrating, and the new auto-deploy
feature and web.xml checking should be really useful for Slide. It also
includes the new JMX code.
I don't know if it would be a good idea to have the admin tool for the
domain and the namespace use JMX to do their work. There have been talks of
building a generic JMX admin tool. Maybe it could be the way to go, if it is
not just too complex to do.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SSL support in webdav client library
Posted by "Ian Kallen <iank@covalent.net>" <ia...@covalent.net>.
Hi Dirk,
Your changes assume you can safely select the protocol based on the port
number. This won't work because https, like http, can be purveyed across
any free port -- some folks prefer port 8443 (like they do 8080 for http),
my usage is grabs an obscure port to keep commonly used ports free for
other purposes, I can continue with use cases for not doing it that way if
you like but I think you get the point. Marrying protocol "https" to the
port "443" is inadequate. My original intention was to set a flag so that
when HttpClient needs to know what protocol to use, CopyMethod/MoveMethod
need to generate Destination headers and anywhere else protocol awareness
is needed, these could be set uniformly. If there's another consideration
I should keep in mind design-wise, let me know and I'll re-think the
patches I'd sent :)
best,
-Ian
On Tue, 6 Nov 2001, Dirk Verbeeck wrote:
> Hi Ian
>
> I made the changes in the code where you indicated but in a different
> way. I used reflection for the SSLSocket and check the port number for
> copy and move method.
>
> Can you test/fix my changes and let me know if it works?
>
> Thanks,
> Dirk
>
>
> "Ian Kallen " wrote:
> >
> > Wow, the enthusiastic response so was overwhelming :) I've attached a
> > patch that enables SLIDE_1_0_15 to use SSL, there might be other places
> > besides copyMethod() and moveMethod() that need to have the hardcoded
> > scheme "http://" factored out of the Destination header generation but
> > that's all I've noticed so far.
> >
> > Note: I used the same method of SSLSockets in HttpClient that is used in
> > jakarta-commons' HttpClient -- my local tests included hacks to circumvent
> > the TrustManager issues stemming from self signed certificates (without a
> > KeyStore and using keytool to muck with the KeyStore
> > contents). Ultimately, I think the HttpClient code is going to need some
> > refactoring to deal with the different ways sockets can be generated more
> > flexibly, but that's another, probably longer, conversation...
> >
> > On Tue, 30 Oct 2001, Ian Kallen <ia...@covalent.net> wrote:
> >
> > >
> > > There's more to fixing the ssl support than this. For instance, the COPY
> > > and MOVE methods' headers generated by
> > > WebdavResource.copyMethod(src,dest)
> > > WebdavResource.moveMethod(src, dest)
> > >
> > > Includes
> > > Destination: http//host:port/dest
> > > ^^^^
> > > That this is not https is a 502 Bad Gateway error. I pulled the
> > > SLIDE_1_0_15 tag (sorry, last few times I pulled HEAD, it didn't build,
> > > so I gave up on it) to work against, those methods have
> > > "http://" hardcoded in :(
> > >
> > > The fix that I'm implementing will have a flag set similar to HttpClient
> > > in WebdavResource that in turn can be propagated, to the Copy/MoveMethod
> > > classes as well as HttpClient. This will just be in the constructor, to
> > > be consistent with the HttpClient implementation. I'm using the HttpClient
> > > in that tree, not the one in the jakarta-commons tree (there seems to be a
> > > minor fork in there).
> > >
> > > Any objections to fixing it in this manner? If not, I should have patches
> > > a little later today. The patches would be against the SLIDE_1_0_15 tag
> > > though, someone else with commit access and an eye on the commit mails can
> > > assess the work to patch HEAD.
> > >
> > > thanks!
> > >
> > > On Mon, 1 Oct 2001, Remy Maucherat wrote:
> > >
> > > > > That exactly is the problem. After I uncomment the SSLSocketFactory
> > > > > code. My test program for SSL works.
> > > > > This requires to import javas.net.ssl.* for the HttpClient class. Should
> > > > > this fix be in the coming beta?
> > > >
> > > > Yes, but it is already, AFAIK.
> > > > Although I didn't remove the source files yet, we should be back to be using
> > > > the HTTP client soon-to-be 1.0 from jakarta-commons (which includes the SSL
> > > > code). I'll try to release that one in sync for the beta.
> > > >
> > > > Remy
> > > >
> > > >
> > >
> > > cheers,
> > > -Ian
> > >
> > > --
> > > Ian Kallen <ia...@covalent.net> | AIM: iankallen
> > >
> > >
> > > --
> > > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > >
> > >
> >
> > cheers,
> > -Ian
> >
> > --
> > Ian Kallen <ia...@covalent.net> | AIM: iankallen
> >
> > ------------------------------------------------------------------------
> > Name: jakarta-slide-SLIDE_1_0_15-enable_ssl.patch
> > jakarta-slide-SLIDE_1_0_15-enable_ssl.patch Type: Plain Text (TEXT/PLAIN)
> > Encoding: BASE64
> >
> > ------------------------------------------------------------------------
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
cheers,
-Ian
--
Ian Kallen <ia...@covalent.net> | AIM: iankallen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>