Bug #21013 [Com]: problem with two dots without trailing slash

From: Date: Wed, 31 Aug 2016 10:19:37 +0000
Subject: Bug #21013 [Com]: problem with two dots without trailing slash
References: 1  Groups: php.pear.bugs 
Request: Send a blank email to pear-bugs+get-11341@lists.php.net to get a copy of this message
Edit report at https://pear.php.net/bugs/bug.php?id=21013&edit=1 ID: 21013 Comment by: qdinar@gmail.com Reported By: qdinar at gmail dot com Summary: problem with two dots without trailing slash Status: Assigned Type: Bug Package: Net_URL2 Operating System: windows 10 Package Version: Unknown PHP Version: 5.5.11 Assigned To: tkli Roadmap Versions: New Comment: i opened bug and only then have seen your new comment. email had not come to me. i have read it and i see you do not have strong arguments to support the current behaviour of net_url2 , and opening the bug is correct. i think you should read and understand texts not so straightly, but should make error-fixing. you are not a bad artificial inteligence, but a human ) . as the normalization of base is optional, result with it and without it should be same. but net url2 does not give same result, because it follows error, and result in case of resolving without the pre-normalization is not correct. Previous Comments: ------------------------------------------------------------------------ [2016-08-31 05:59:26] qdinar -Status: Bogus +Status: Open ------------------------------------------------------------------------ [2016-08-27 20:27:04] tkli Sounds a lot like a misunderstanding. There is no objection that the base-URI normalization is optional. In fact that is the reason that Net_URL2 does not apply it *always*. It's up to Net_URL2's user to decide whether or not to make use of that option. The example I was giving was just a code example of such a (optional) normalization of the base-URI prior to resolution. That is covered in 5.2.1. Pre-parse the Base URI. RFC 3986 sections 5.2.4 is about the path component, not the base-URI. And RFC 3986 section 6 is not even about URI resolution. Then you write that the RFC has an error and as you also write that Net_URL2 has an error, I think we can agree that Net_URL2 is RFC conform. In this sense I'm fine, it's just that I do not think that the RFC has an error there. It just specifies the algorithm which is then to be followed to be conform. If you really think that the text in the Section 5.2.3. Merge Paths bullet #2 is wrong, please do not only discuss it with me but with persons who can say much better than I ever could. IIRC the IETF governs the RFC documents and each RFC has an errata process. Perhaps <http://www.ietf.org/> has more information, I think they have an issue tracking mechanism for every RFC. The last point you give is redundant in the misunderstanding. We already agreed that normalization is *optional*. This is why ->resolve() can not apply it always as it would not be optional any longer. I hope it is now more clear that normalization of the base-URI really is optional and Net_URL2 does not enforce it on ->resolve() and that is not in error but by intention following the procedures as outlined in RFC 3986. Personally I can't hardly imagine that authors would have forgotten about it, dot-sequences are totally in that part of the document. ------------------------------------------------------------------------ [2016-08-27 10:22:33] qdinar "The point you're missing is to normalize the base URI first, then you'll get the result you expect." - my point is ok: base uri has not to be normalized, that (normalization) is optional, see RFC 3986 5.2.1 . "The important part here is that the base-URIs path component is already normalized (See RFC 3986, sections section 5.2.4 and 6)." - RFC 3986 sections 5.2.4 and 6 do not say that base uri must be normalized. "The expected result you present is not RFC conform resolution of an URI to a base URI." "For the merging of paths in resolve(), please see section 5.2.3." - there is a error in 5.2.3 after "otherwise": author(s) have just forgotten about case with ".." at end of path or author(s) just speak shortly like if the base url is normalized. in the case with ".." at end of path, " excluding any characters after the right-most "/" " is not correct algorithm. (most easy way to fix it in that case is to append "/" to it and only then append reference's path to it). "Example: ... $base->normalize(); " - if normalisation was required for base uri, by rfc, this "base->normalize" would not expected to be used by programmer (user of Net_URL2) (as you show in the example), but it would be done inside "base->resolve" by programmers of Net_URL2. ------------------------------------------------------------------------ [2016-01-06 19:10:18] tkli -Status: Assigned +Status: Bogus Behaviour is not unexpected. ------------------------------------------------------------------------ [2016-01-06 19:08:32] tkli I can reproduce your report against the current stable version but this is not a bug. The expected result you present is not RFC conform resolution of an URI to a base URI. The point you're missing is to normalize the base URI first, then you'll get the result you expect. Example: $base = new Net_URL2('http://example.com/a/b/..'); $base->normalize(); var_dump((string) (string) $base->resolve('c.php')); # string(26) "http://example.com/a/c.php" The important part here is that the base-URIs path component is already normalized (See RFC 3986, sections section 5.2.4 and 6). For the merging of paths in resolve(), please see section 5.2.3. ------------------------------------------------------------------------ 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=21013 -- Edit this bug report at https://pear.php.net/bugs/bug.php?id=21013&edit=1

« previous php.pear.bugs (#11341) next »