So... I got bored and had a little time. Here's a testcase which highlights the URI-rewrite changing the URI for requests. It only tests one example of the URI failures right now: DefaultClientRequestDirector.rewriteRequestURI's else branch. I'm not positive how to setup the environment to test the if branch. The other tests can be added to TestRedirects.
Only two testcases fail: testEscapedAmpersandInQueryAbsolute, and testEscapedAmpersandInPathAbsolute. The relative requests pass, because no URI-rewriting is done there. There's probably many more (and other) ways to test it, but assuming no special-casing is done in the core to look for ampersands and do things specially, whatever fixes this should fix other problems. Sam On Jan 21, 2008 1:19 PM, Sam Berlin <[EMAIL PROTECTED]> wrote: > 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]
