Re: Making Net_URL2 Stable

Hi Bertrand, On 22.07.2011 18:42, Bertrand Mansion wrote:

The old Net_URL package tried to handle the multiple slashes case (////) in its resolvePath() method.

I've maintained another package written by the same author (HTTP_Request) and should note that "a package Foo does bar" does not exactly mean that bar is the proper / sane behaviour as defined by the relevant RFC.

Other url libraries in other languages can also deal with this, for example : http://pypi.python.org/pypi/urlnorm If Net_URL2 cannot deal with that, it should maybe be renamed Net_RFC3986 so we could keep using Net_URL when we want to be productive.

A good idea, we can also rename HTTP_Request(2) to Net_RFC2616!

Actually I am not sure RFC3986 says anything about how to normalize multiple slashes in path and it seems to give just examples, not a test suite. A library that is supposed to make working with urls easier should in my opinion be able to normalize this. That's what Net_URL was doing.

I did a quick check with Firefox / IE / Chrome on client side and Apache on server side. Each of the browsers normalized URL http://localhost/foo/bar/../ to http://localhost/foo/ However, none of them tries to change URL http://localhost/foo//bar/ Apache reports the same URL for request, it doesn't try to "normalize" it either.

Maybe the current maintainers have an opinion on that ? Cheers, Bertrand On Fri, Jul 22, 2011 at 12:37 PM, Alexey Borzov<borz_off@cs.msu.su> wrote:

Hi Bertrand, On 22.07.2011 0:27, Bertrand Mansion wrote:

Net_URL2 could use the QF2 version instead, looks more robust.

Both are more or less verbatim implementations of algorithm from RFC 3986, in fact. Anyway, I'd suggest getting rid of $j and the frightening comment in removeDotSegments() at the very least.

Also, don't you think the following rules should be handled :

- '/foo//' =>    '/foo/'
- '/foo///bar//' =>    '/foo/bar/'

I am not sure whether this is a good idea: such changes are not described in RFC 3986, unlike removing dot segments. I suppose /foo///bar// is a valid path according to RFC 3986 and different from /foo/bar/

On Thu, Jul 21, 2011 at 6:33 PM, Alexey Borzov<borz_off@cs.msu.su>    wrote:

Hi Bertrand, On 21.07.2011 15:27, Bertrand Mansion wrote:

The removeDotSegments() method looks a bit weak with its while() loop and its comment : "Make sure not to be trapped in an infinite loop due to a bug in this method" ...

Hopefully there isn't an actual infinite loop bug there and this is just a "safety valve"...

I suggest that you use an explode('/') on $path, then iterate to fill a second array with tokens from $path using an index that increase/decrease according to the '..' it meets.

...and we have such a method in HTML_QuickForm2, in fact: http://svn.php.net/viewvc/pear/packages/HTML_QuickForm2/trunk/HTML/QuickForm2/Controller/Action/Jump.php?revision=311435&view=markup (see HTML_QuickForm2_Controller_Action_Jump::normalizePath()) However, both of these methods use the test suite described in RFC 3986 so probably are on the same level of robustness: http://svn.php.net/viewvc/pear/packages/Net_URL2/trunk/tests/Net/URL2Test.php?revision=309226&view=markup (see testResolve()) http://svn.php.net/viewvc/pear/packages/HTML_QuickForm2/trunk/tests/QuickForm2/Controller/Action/JumpTest.php?revision=309664&view=markup (see testRedirectToAbsoluteUrl()) Speaking of test suites, why aren't tests for Net_URL2 added to package.xml and consequently installed with the package?

On Thu, Jul 21, 2011 at 1:05 PM, till<till@php.net>      wrote:

This is still open: http://pear.php.net/bugs/bug.php?id=14399 Can you check it out and either close/wontfix, etc.? On Tue, Jul 19, 2011 at 4:47 PM, David Coallier<davidc@php.net> wrote:

Thanks Alexey, Not planning on any BC breaks just now. Cheers, -- David Coallier -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php