Although I still don't know why, I did find in the archives where a "redirect was requested while redirect is disabled" was referenced and as I debugged I found this was the cause of my application's inability to connect.
The http://localhost:8080/slide on tomcat 4 worked but did not work on tomcat 5. However, http://localhost:8080/slide/ worked on both. I modified my application to check uri and set the trailing '/' on connect and AOK. Michael Oliver CTO Alarius Systems LLC 3325 N. Nellis Blvd, #1 Las Vegas, NV 89115 Phone:(702)643-7425 Fax:(702)974-0341 *Note new email changed from [EMAIL PROTECTED] -----Original Message----- From: Michael Oliver [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 12:11 PM To: 'Slide Users Mailing List' Subject: Tomcat 4 and Tomcat 5 Client differences I am having a problem connecting to slide on Tomcat 5 similar to a previous thread that ends with http://mail-archives.apache.org/mod_mbox/jakarta-slide-user/200409.mbox/ [EMAIL PROTECTED] I had slide 2.1 running fine on Tomcat 4 at http://localhost:8080/slide I have my application talking to slide via the webdavresource in the client libs also just fine to Tomcat 4 at that URL. When I upgraded to Tomcat 5 it throws an HttpException org.apache.commons.httpclient.HttpException at org.apache.webdav.lib.WebdavResource.propfindMethod(WebdavResource.java: 3467) at org.apache.webdav.lib.WebdavResource.propfindMethod(WebdavResource.java: 3423) at org.apache.webdav.lib.WebdavResource.setNamedProp(WebdavResource.java:96 7) at org.apache.webdav.lib.WebdavResource.setBasicProperties(WebdavResource.j ava:912) at org.apache.webdav.lib.WebdavResource.setProperties(WebdavResource.java:1 894) at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1301 ) at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1320 ) at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1408 ) at org.apache.webdav.lib.WebdavResource.<init>(WebdavResource.java:290) at com.alariusj.contentclient.AJContentClient.Connect(AJContentClient.java: 924) at com.alariusj.contentclient.test.AJContentClientTest.testConnect(AJConten tClientTest.java:67) which is this part of the code try { httpURL = new HttpURL(stringUrl); webdavResource = new WebdavResource(httpURL); webdavResource.setDebug(debugLevel); setPath(webdavResource.getPath()); retStatus = webdavResource.getPath(); } catch (HttpException we) { // Check authorization and try it again. we.printStackTrace(); log.debug("HttpException:"+ we.getLocalizedMessage()); if (we.getReasonCode() == HttpStatus.SC_UNAUTHORIZED) { was that previous thread ever resolved? Michael Oliver CTO Alarius Systems LLC 3325 N. Nellis Blvd, #1 Las Vegas, NV 89115 Phone:(702)643-7425 Fax:(702)974-0341 *Note new email changed from [EMAIL PROTECTED] -----Original Message----- From: Miguel Figueiredo [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 2:19 AM To: 'Slide Users Mailing List' Subject: RE: custom authentication with slide and httpclient Hello Aaron, Lately I have been very upset by that 'expect: continue' handshake. I'll just link you with my results in this urls: http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.do tnet .framework&mid=a515168f-df63-4ff3-8e2b-ec7f6fb76c0a http://issues.apache.org/bugzilla/show_bug.cgi?id=31567 In short, there seems to be an exploit Micro$oft found about to make their http 1.1 implementation incompatible with tomcat 5.0.28 (at least this version it's true). Seems like M$ uses the 'expect: continue' header for authentication handshake but instead of waiting for the response, from the remote server, before starting to send the body content, it starts to send the body content anyway. That is bad because tomcat replies with an obvious 401 Unauthorized, and for the following HTTP request it uses the data from the body content from the previous request as the start of the following request. That results in another error response 505 HTTP Version Not Supported. In those links I complained to M$ and they just told me to disable the 'expect' headers (LOL), and to Tomcat, Remy just wasn't very reasonable to make an enhancement (discard the data of the invalid content body) witch I though it was the right thing to do... It was just a warning about the expect headers. Best regards, Miguel Figueiredo ____ Hi Aaron, See my comments in-line On Mon, 2005-02-07 at 10:49 -0500, Aaron Hamid wrote: > Hi folks, sorry for the cross posting but I think this issue is relevant > to both projects. > <snip> > There are two problems I have found, one in http client, one in Slide. > First, it seems that CredentialsProvider ONLY is called upon a challenge > from the server (HttpMethodDirector, 'promptForCredentials'), and never > pre-emptively, even if I setAuthenticationPreemptive(true). My > expectation would be that if I set preemptive authentication than my > registered CredentialsProvider should be called prior to the request > being made. Our custom auth doesn't use an HTTP challenge, so the creds > are required to be there to begin with. I can explain this. The problem is that only Basic authentication can be used preemptively and required by HTTP spec for compatibility reasons. All other schemes either cannot be used preemptively (NTLM) or should not be used preemptively (Digest to some extent). Firstly, challenge-less authentication schemes are inherently insecure, because they allow the authentication credentials to be sent to an unknown party. Even if the credentials are encrypted using a predefined encryption algorithm, one can still easily pull off a 'man in the middle' type of exploit. Secondly, the so called 'expect: continue' handshake renders the preemptive authentication virtually superfluous. For a fairly small price one gains a lot in terms of security. Bottom line, if your web server supports HTTP/1.1, which is a commonplace these days, disable the preemptive authentication, enable the 'expect: continue' handshake and live happily ever after. > > In addition, it seems that the HTTP Method implementations of Slide use > a default AuthState (in HttpMethodBase). Apparently it uses BASIC auth > as the default scheme, and does not pick up the global defaults (I tried > registering my parameters on the DefaultParams* singleton after > discovering this, to see if they would be picked up, but they are not). > I do not know much about Slide's inner working, but I'll be willing to take a look at the Slide source code, should this be required. > I think the first quick fix is to update HttpMethodDirector so it uses > CredentialsProvider preemptively (if one is defined, and > setAuthenticationPreemptive is set). > See above. > I'm not sure how to handle the second problem because I am not > thoroughly familiar with the design decisions and abstractions behind > HttpClient and expected usage. I would think either the Slide > WebdavResource should expose the HttpClient with the real AuthState it > will use (I know I can get HttpClient through > WebdavSession.getSessionInstance... but it appears the default AuthState > in the Method "overrides" anything I set), or have the default authstate > inherit global defaults (perhaps lazily). > See above. Cheers, Oleg --------------------------------------------------------------------- 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]
