I'd suggest to let provider adopt his own policy, BTW someone else feedback would more than welcome. Come on guys, don't be shy! :)
PS Pid, why don't you start committing your concrete stuff under the client module? It would be easy see the progresses. http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, Jul 11, 2010 at 2:06 PM, Pid <[email protected]> wrote: > 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' >>>>> >>>>> >>> >>> >>> > > >
