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.dotnet .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]
