I'm also not certain why the URIs are being recreated, but it's only done in four places in the code. Two are within DefaultRedirectHandler.getLocationURI, and the other two are within DefaultClientRequestDirector.rewriteRequestURI. One of them within DefaultRedirectHandler seems to be harmless, since it's just for ensuring there are no circular redirects. The other method in DefaultRedirectHandler already calls resolve on the newly-built URI.
To be honest I have no clue what the methods are trying to do (nor can I understand what's going on in the resolve or relativize mehods), so I'm not sure what'd be required to fix them. I do think it should be possible to basically replace whatever calls the multi-arg constructors with a quick method toURI(multi-args) that returns a new URI(a+b+c+d+e), essentially concatenating the non-null parts together and returning a URI from the single-arg constructor. Of course, that could also fail miserably... Tim has looked into this in much greater detail than I, so he likely has more suggestions and/or insight than I can provide. It should be possible to write tests that want to send a request for something like http://localhost/file%20name?a=b&c=%26d, and see if the server gets the correct request. I did a quick glance through the httpclient tests, but couldn't find a class that was testing similar things. Where would a test like this go? (And is there any test that does something similar?) Sam On Jan 20, 2008 10:16 AM, Roland Weber <[EMAIL PROTECTED]> wrote: > Oleg Kalnichevski wrote: > > On Sat, 2008-01-19 at 09:33 -0800, Sam Berlin wrote: > >> It almost certainly would work, however HttpClient would then be > >> broken (as far as URI parsing goes) for everyone else. As others have > >> pointed out (and as Tim explained to me in sad detail), URI is just > >> basically broken when it comes to using it with the multi-arg > >> constructors. It's flat-out impossible to recreate a URI with the > >> multi-arg constructors and have it point to the correct resource. > > > > What would be your suggestion on dealing with the issue? Is there anyway > > we could avoid rewriting the whole URI class and leverage functionality > > already available in the JRE? > > I don't know by heart where we are creating URIs. If path escaping > is the problem, maybe we can use some workaround like: > > URI base = new URI(scheme, hostport, null); > URI full = base.resolve(pathonly); // maps to single-arg constructor > > cheers, > Roland > > > --------------------------------------------------------------------- > 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]
