hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Julien <tjul...@limewire.com>
Subject Re: unable to encode reserved characters using java.net.URI multi-arg constructors
Date Tue, 22 Jan 2008 23:19:19 GMT
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 construct the URI instance using a multi-arg constructor. It was
>>> long on my virtual to-do list to open a feature request for pluggable
>>> URI parsers in JIRA. Probably it is about time.
>>>
>>> Would that work for LimeWire?
>>>
>>> Oleg
>>>
>> 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.
>>
>> Sam
>>
> 
> Sam
> 
> 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?  

In the short term, I think all multi-arg constructors have to be 
replaced with single-arg ones (like Sam's patch in 
https://issues.apache.org/jira/browse/HTTPCLIENT-730).

For correctness - this may or may not require re-implementing much of 
the j.n.URI class. I think we could probably get away with just stealing 
j.n.URI.defineString() (private method).

Also I think a bug should be filed against the JDK; I think this is a 
design bug.

And we need to document that users of httpclient should NOT use the 
multi-arg constructors.

> 
> Oleg
> 
> 
>> ---------------------------------------------------------------------
>> 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