On 11/07/2010 13:01, Simone Tripodi wrote: > 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...
So throw an exception then, or let the server reject it? > Does someone else have other ideas? Yes. Anyone? p > 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' >>>> >>>> >> >> >>
signature.asc
Description: OpenPGP digital signature
