Hi Matthew: I've noticed this behavior too. The question, in my opinion, is how to decide when to invoke the "preemptive strike" behavior. You don't know until a 401 has been returned exactly what realm is required for authentication for a particular request.
Storing the URL, as you suggest is overly restrictive, and would potentially require caching every separate URL that has required authentication for a particular realm. Most browsers appear to send credentials for every subsequent request to the same host and port. This can be a bit risky in my opinion, as the user's credentials could be supplied to unrelated services on the same host. Some of this risk is mitigated in browser implementations by the fact that credentials can be sent using digest. Unfortunately, only basic authentication is provided in HttpClient so far, causing credentials to always be sent virtually in plaintext (actually, base64). If we decided to implement digest authentication in HttpClient, I'd be supportive of taking the approach of storing a collection of hosts and ports with the realm and credentials and send the credentials unconditionally to the same hosts and ports in subsequent requests. If the host doesn't support digest, we'd continue to send with basic. At least we provided the opportunity to use a more secure authentication method with that server, so if the credentials are sent to an undesireable service, too bad. My initial idea of Behavior: Attempt to find realm by host and port in HttpState (in new host/port map). Not found. Make request without credentials. Receive 401 response with realm. Lookup credentials by realm returned with 401. Found. Store realm for host and port in host/port map. Future attempts to find realm by host and port will result in the stored realm. That's my thinking thus far. Thoughts? Anyone? Yours truly, Paul C. Bryan <[EMAIL PROTECTED]> http://pbryan.net/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
