Re: Net_URL Bug #6470

Andrei Railean wrote:

I've added a new comment to the bug report with a link to the new patch http://delta.squiz.net/~arailean/pear6479.udiff.patch It simply introduces a new method encodePath() that can be used standalone. Decided not to call resolvePath in it because they can easily be nested like encodePath(resolvePath($path)) or the other way around. At the moment, nothing in the Class is using this function. Something probably should. There are two places where it could (or should) be used. Constructor and/or getUrl(). Constructor is better, as once constructed, the path property of the URL object is guaranteed to be RFC valid.

Case the parse_url() does not answer false. See my example in complement, the url is not wrong, just assuming the current scheme and not encoding (what is the target of your susbsequent method) the "/"in query. In french, we talk of a fish eating its own tail for that. Anuway, the result of parse_url() is nowadays to be checked , you won't foreach(false as $k => $v) Then, if checked, it will gently fail as do modern PHPs I believe, myself, that just missing the scheme is ok. Don't reply we should ensure it before : in this case I don't need parse_url() Anyway, it's unusable as it is. Only gurus could save us.

getURL is OK but not the best because putting it there implies that this is the only official way to extract a valid URL from this object, which means that many other classes that depend on Net_URL's parsing capabilities (to extract components) will not see the encoded path. Alternatively, we could add a 'setPath' method that will encode the path component when it is being set (similar to case 1 above - encoding in the constructor) Or a getPath that will encode (and possibly resolve) the path on access.