hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Berlin" <sber...@gmail.com>
Subject Re: unable to encode reserved characters using java.net.URI multi-arg constructors
Date Tue, 22 Jan 2008 14:09:12 GMT
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 <olegk@apache.org> 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 <sberlin@gmail.com> 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 <ossfwot@dubioso.net> 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: dev-unsubscribe@hc.apache.org
> > > > For additional commands, e-mail: dev-help@hc.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message