[PEAR-BUG] Bug #20421 [Fbk]: Reject invalid path

Edit report at https://pear.php.net/bugs/bug.php?id=20421&edit=1

 ID:               20421
 Updated by:       [email protected]
 Reported By:      jan dot prachar at gmail dot com
 Summary:          Reject invalid path
 Status:           Feedback
 Type:             Bug
 Package:          Net_URL2
 Package Version:  2.0.7
 PHP Version:      Irrelevant
 Assigned To:      tkli
 Roadmap Versions: 
 New Comment:

I agree with you that Net_URL2::getUrl() mustn't always return a string
of a valid URI. And I think no more that 
exception should be thrown.

I was just trying to point out the inconsistency in case of

$url = new Net_URL2('index.html');
$url->setHost('example.com');
$url->getUrl(); // returns //example.com/index.html

where you are modyfing path from index.html to /index.html in order to
get valid URL instead of returning just string 
'//example.comindex.htm'. But maybe it is only specualtive problem, as
you said. I don't run into it in a real 
concrete example but just when I was reading Net_URL2 source code.

Thanks


Previous Comments:
------------------------------------------------------------------------

[2014-10-08 13:51:34] tkli

-Status: Assigned
+Status: Feedback
this becomes more and more speculative.

as written Net_URL2 does not validate an URI. Therefore you can set a
path to "//h" which would create a valid 
URI if there is an authority but an invalid URI if there is no authority
(compare RFC 3986 3.3. Path).

The later is the case with your example:

$url = new Net_URL2('http:g');                                          
           
$url->setPath('//h');                                                   
           
echo $url->getUrl(); 

URI "http:g" does not have an authority.

Is it expected for you that Net_URL2::getUrl() always returns a string
of a valid URI? I could not say so, 
therefore I say no. Therefore this would not be an exception, but just a
string with an invalid URI. Something 
you write is unexpected to you.

Do you have a concrete example where you ran into this?

------------------------------------------------------------------------

[2014-10-08 11:43:59] pracj3am

Another point of view. Let's say we want to fullfil following:

$u = new Net_URL2($url);
$u->setPath($path);
$this->assertSame($path, (new Net_URL2($u->getUrl()))->getPath());

For url 'http:g' and path '//h' you get that '//h' is not equal to
false
For url 'http://example.com' and path 'h' you get that 'h' is not equal
to false or (after the fix #20159) 'h' is not equal to 
'/h'

Since there is now way to get this test passing in these two examples I
think it is legit to make all setters private. Is 
there any valid use case for them anyway? But it would be a major bc
break...

------------------------------------------------------------------------

[2014-10-08 01:54:18] tkli

-Status: Feedback
+Status: Open


------------------------------------------------------------------------

[2014-10-08 01:52:36] tkli

thanks for sharing, I did overlook the setPath() call in the actual
example code.

however the problem still remains: if you set "//h" as path and there is
no authority, Net_URL2 
actually leaves that up to the user. As it starts with "//" and with no
authority, this denotes "h" as 
the new authority and no path.

not saying this is a good way to deal with it, i need to think about
this a little. exception throwing is 
not my preferred option to solve this one.

using a method with "path" in it's name to change the authority is not
fine, too.

as you rightfully say, this is inconsistent.

------------------------------------------------------------------------

[2014-10-08 01:10:44] pracj3am

At least now you are inconsistent in handling invalid path in case of
present and missing authority.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://pear.php.net/bugs/bug.php?id=20421

-- 
Edit this bug report at https://pear.php.net/bugs/bug.php?id=20421&edit=1