Tim Julien wrote:
Also I think a bug should be filed against the JDK; I think this is a
design bug.
They will never fix design bugs in existing code. As it may break
existing applications... They fix design bugs by deprecation and new
APIs. But Sun is a completely different story anyway.
-
Oleg Kalnichevski wrote:
On Sat, 2008-01-19 at 09:33 -0800, Sam Berlin wrote:
Here's my take. There is nothing wrong with j.u.URI as such. It just
needs a better parser that can deal with escaped and unescaped queries,
as well as be more lenient about common non-compliant behaviors, and
then con
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-
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 b
FWIW, replacing the else branch in
DefaultClientRequestDirector.rewriteRequestURI with
--
String path = uri.getRawPath();
String query = uri.getRawQuery();
String fragment = uri.getRawFragment();
String newUri =
(path
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
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,
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
>> bas
On Sat, 2008-01-19 at 09:33 -0800, Sam Berlin wrote:
> > Here's my take. There is nothing wrong with j.u.URI as such. It just
> > needs a better parser that can deal with escaped and unescaped queries,
> > as well as be more lenient about common non-compliant behaviors, and
> > then construct the
> Here's my take. There is nothing wrong with j.u.URI as such. It just
> needs a better parser that can deal with escaped and unescaped queries,
> as well as be more lenient about common non-compliant behaviors, and
> then construct the URI instance using a multi-arg constructor. It was
> long on m
On Fri, 2008-01-18 at 21:35 +0100, Ortwin Glück wrote:
> Oleg Kalnichevski wrote:
> > needs a better parser that can deal with escaped and unescaped queries,
>
> Sorry, Oleg, nobody can deal with unescaped queries. It's NOT POSSIBLE (tm).
>
Escape, maybe? ;-)
Oleg
> -
Oleg Kalnichevski wrote:
> needs a better parser that can deal with escaped and unescaped queries,
Sorry, Oleg, nobody can deal with unescaped queries. It's NOT POSSIBLE (tm).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addit
Tim Julien wrote:
>
> For example, suppose I want to produce this URL:
>
> http://foo.com/bar?a=b&c=jon%26doe
>
> // %26 is the encoded value of &
> // %25 is the encoded value of %
>
> uri = new URI("http", null, "foo.com", -1, "/bar", "a=b&c=jon%26doe",
> null);
> uri.toASCIIString() -> htt
On Fri, 2008-01-18 at 09:47 -0500, Tim Julien wrote:
> All,
>
> I've spent a few days looking into some strange URL encoding issues on
> http client 4.0 alpha 2. I'll describe some things I've found,
> hopefully I am thinking about this correctly.
>
> I think there is a regression from 3.0 ->
All,
I've spent a few days looking into some strange URL encoding issues on
http client 4.0 alpha 2. I'll describe some things I've found,
hopefully I am thinking about this correctly.
I think there is a regression from 3.0 -> 4.0 due to the use of java.net.URI
On the old commons http client
15 matches
Mail list logo
