Daniel Kulp wrote:
Polar,
On Monday 12 February 2007 16:00, Polar Humenn wrote:
Daniel Kulp wrote:
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.
Can chunking be turned on a connection after an authentication? Is that
allowed?
On subsequent request, yes. Shouldn't be a big deal.
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.
That currently does not happen because the HttpURLConnection
implementation hides the needed information. I am now looking into the
Jakara commons HTTPClient, which looks quite promising, if it works like
it web page says.
Are you sure? What information is missing?
I seem to be able to get all the information for basic auth....
connect.getResponseCode() returns 401
connect.getHeaderFields().get("WWW-Authenticate") returns Basic realm="WebDAV
Restricted" for my webdav site.
If you wait until you call getInputStream() and catch that exception, the
information is indeed gone. If you grab the code and HeaderFields first,
it seems to be there. (and note that other stuff would be in the
ErrorStream, not the InputStream)'
Yep, the HTTPConduit implementation right now currently just goes for
the getInputStream() and then that's when the Conduit caught the error
about authentication during streaming. So, it would be easy enough to
get the realm information needed and throw it back, but what about a
retry after a call back? If we do this in the Conduit, we might be doing
just as much work as this Jakarta HTTPClient does already.
The implementation of java.net is still lacking, (as coincidently the
Jakarta HTTPClient web state says). Before one gives up the sensitive
username/password information one would like to examine the SSL
information of the server and protection quality of the "tunnel" to it.
Unfortunately, at a look at the Jakarta code, I think the HTTPClient
missed the boat in terms of this assurance as well. Although it allows
to use SSLSocket Factories, its authentication callback does not let you
get at the information from that socket. I may be wrong, but I've been
looking at it all afternoon, I don't think so.
Thanks!
