Oops, sorry about that. GMail doesn't do a great job letting you know what your outgoing messages look like to everyone else. The JIRA is now at: https://issues.apache.org/jira/browse/HTTPCLIENT-730 .
Sam On Jan 22, 2008 4:55 AM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > On Mon, 2008-01-21 at 21:58 -0500, Sam Berlin wrote: > > 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 > > > > Hi Sam > > The attachments apparently got stripped away. Can you open a JIRA for > this problem and attach the test cases to the report? > > Oleg > > > > > 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] > > > --------------------------------------------------------------------- > 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]
