On Sunday 11 February 2007 16:21, Dan Diephouse wrote: > As a side note, do we really think http chunking should be on by default? > We ended up making users having to turn it on in XFire because of > interoperability issues with various HTTP servers. So it makes me nervous > to default to having chunking on.
If chunking is not turned off (or redirects turned on BTW), then streaming is effectively disabled and performance for large messages drops significantly (and memory usage goes way up). The HTTPUrlConnection object buffers the entire message into a byte[] so that it can calculate the Content-Length header (if one isn't specified which we don't calculate) or resend if it gets a 30# response code. With chunking, the Content-Lenght header is not needed so if redirect support is off, it can stream directly. However, that also breaks the 401 resend. What we could do is disable chunking if there is a 401 callback registered and the we're already not authenticated. If there is a basic auth header to go out (AuthenticationPolicy object filled out), keep the chunking. > The java.net.HttpURLConnection does have an authenticator scheme that > > allows "automatic" use of Password Authentication, > > java.net.Authenticator. This Authenticator, (apparently only one per > > JVM), has an interface with which to query certain aspects of the site > > "requesting" authentication, such as IP address, port numbers, URL, etc. > > This object does provide differentiation of figuring out which username > > and passwords to send, but is slightly lacking in deciding trust whether > > to send them or not. > > > > The big question is, can we do better than this? Can we organize > > something in CXF that will allow us to use security in a good way? First > > establishing trust before sending sensitive information? Can we do this > > without solely programming everything into an XML file? > > > > Even this java.net.Authenticator is woefully inadequate as there is now > > way too look up an SSL authentication on the HttpURLConnection. > > > > I don't imagine that the use of HttpURLConnection will go away inside > > CXF, but there should be some better way to "configure" or at least > > dynamically direct the HTTPConduit in use for a particular endpoint. > > Would it be beneficial to the team for me to spend time on proposing a > > good security solution? Couple caveats/use cases that must be supported: 1) If there isn't a callback and we get a 401, we must throw a proper exception that is propagated back with all useful information to the user. 2) If the user has specified a username/password programatically (ex: BindingProvider keys from JAX-WS frontend), we need to put them on the wire immediately, even if it's just http. (spec compliance) I'm not going to pretend to understand half of what this thread is talking about (I'm not a security expert by any means), but the "simple" usecases need to be the defaults due to JAX-WS spec compliance. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
