OK, so going to replace URL using URI, sounds a good compromise. I wouldn't force clients to the automatic correction. Users have to know the risks using PLAINTEXT without SSL, as explained in the spec notes... Does someone else have other ideas?
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, Jul 11, 2010 at 1:44 PM, Pid <[email protected]> wrote: > On 11/07/2010 12:26, Simone Tripodi wrote: >> I understand well your point of view. So, a good compromise can be >> reached using the URI class; users can use that[1] method to create >> urls in a "safety" way. >> In the signature part, we need to acces to various URL part (protocol, >> host, port) and I wouldn't rewrite a parse at all. > > Crap, yes, you're right of course. URI is a good solution. > > WDYT about automatically correcting a plaintext+http request to https? > > > p > >> WDYT? >> Simo >> >> [1] >> http://java.sun.com/javase/6/docs/api/java/net/URI.html#create(java.lang.String) >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Sun, Jul 11, 2010 at 11:53 AM, Pid <[email protected]> wrote: >>> On 11/07/2010 10:41, Simone Tripodi wrote: >>>>> >>>>> I think maybe the requestURL should be a String too - I'm trying to >>>>> handle all of the IOExceptions in the HttpConnector. >>>>> >>>> >>>> discouraged. making the requestURL as a proper URL saves to check the >>>> string is a proper URL and we shouldn't reinvent the wheel. >>> >>> The requestURL is only passed to the HttpConnector, nowhere else. >>> >>> It will start as a String somewhere in the system, so we have to catch >>> an IOException to create the URL object. >>> >>> This isn't a case of reinventing the wheel at all, it's a case of >>> putting all of the IO operations/checks associated with making the >>> request in one place. >>> >>> I don't see any advantage in doing that try+catch at anywhere before the >>> IO processing begins. >>> >>> >>> The related issue is whether to validate the request before making it - >>> which will probably be necessary in the case of checking the plaintext >>> method is an HTTPS one. >>> >>> Leading on from that, if we automatically* upgraded the plaintext >>> connection to HTTPS, it would mean recreating the URL object, complete >>> with try+catch etc, rather than a simple String regex. >>> >>> >>> >>> >>> * Checked via a system property, defaults to 'on' >>> >>> > > >
