From:  pear-qa@lists.php.net ("qdinar@gmail.com")
Date:  31 Aug 2016 18:19:37 Hong Kong Time
Newsgroup:  news.php.net/php.pear.bugs
Subject:  

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

NNTP-Posting-Host:  null

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
 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