Santy, Michael wrote: > I think I understand what you're getting at. I dug through the code a > bit late last night, and can definately see that its not straightforward > as I thought. Its the Authenticator framework in java that abstracts > away some of the details that we need. > > My assumption is that the actual loading of the remove content is done > with the URLUtil class. When the URL.openConnection() method is called > and the server requires authentication, java calls back to the XXE > Authenticator module automatically. Couldn't we modify the > openConnection(URL, boolean) method to test if the connection returned > is a java.net.HttpURLConnection? If so, you then have access to the > response code and message.
The architecture of XXE does not make this idea easy to implement: URL.openConnection and XXE's Authenticator belong to two different, ``very distant'', code layers. > What heuristic did you use to workaround this? If XXE's Authenticator is invoked 10 times in a row to return credentials for exactly the same host/port/prompt/scheme, then it is probably because the credentials previously returned the 9 preceding times were rejected by the server. In such case, XXE stops returning the old, cached, credentials and prompts the user one more time. This seems to work fine with Apache 2.2+mod_dav. If you want to test that, I can tell you where to download XXE v3.6.2 final beta this evening or next Monday in the morning.
