Doc #74599 [Opn->Ver]: parse_url allows bad characters in the common name

[email protected]
Newsgroups php.doc.bugs
Message-ID <[email protected]>
Edit report at https://bugs.php.net/bug.php?id=74599&edit=1

 ID:                 74599
 Updated by:         [email protected]
 Reported by:        bj dot cardon at gmail dot com
 Summary:            parse_url allows bad characters in the common name
-Status:             Open
+Status:             Verified
 Type:               Documentation Problem
 Package:            URL related
 Operating System:   Linux
 PHP Version:        7.0.19
-Assigned To:        
+Assigned To:        cmb
 Block user comment: N
 Private report:     N

 New Comment:

> To be fair, I was thinking "sensible" would be to interpret the
> parts in the same way an error-correcting browser might interpret
> them.

I agree that it would be nice to have such function, but it is
important to note that parse_url() also tries to parse incomplete
URLs, what browsers usually don't do.


Previous Comments:
------------------------------------------------------------------------
[2017-05-16 02:25:42] bj dot cardon at gmail dot com

To be fair, I was thinking "sensible" would be to interpret the parts in the same way an error-correcting browser might interpret them. Otherwise, I'm not really sure what the purpose of a function like parse_url would be (since it couldn't even be used to necessarily get accurate URL parts and perform your own sanity validations).

I would agree that at the very least the documentation should be more clear, and you are correct that filter_var already provides a close enough approximation of what I'm looking for.

------------------------------------------------------------------------
[2017-05-16 01:59:26] [email protected]

The underscores are only applied to control characters - guaranteed to be invalid everywhere. The docs should clarify that "invalid" does not consider what is allowed in each component.

> not parse the URL in a nonsensical way
parse_url tries to break the string into pieces in the most reasonable way it can figure. Mostly based on the presence of delimiters. Backslashes don't have significance, unlike : or / or ?, so they're ignored.

If you think that a "nonsensical way" is parsing a string without validation then a "sensical way" would be parsing it *with* validation, and parse_url is only designed to do half of that.

Parsing with validation is trivial:

function parse_valid_url($url, $component = -1) {
  return filter_var($url, FILTER_VALIDATE_URL) ? parse_url($url, $component) : false;
}

------------------------------------------------------------------------
[2017-05-16 01:37:42] bj dot cardon at gmail dot com

On a side note, perhaps returning FALSE is not the actual expected behavior, however I don't think the behavior as it currently exists is ideal for this scenario.

------------------------------------------------------------------------
[2017-05-16 01:31:32] bj dot cardon at gmail dot com

I don't need "validation". I need a function that claims to parse a URL to not parse the URL in a nonsensical way.

The documentation also says:

> Invalid characters are replaced by _

Which is not happening with the invalid character of '\'.

------------------------------------------------------------------------
[2017-05-15 23:56:20] [email protected]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

> This function is not meant to validate the given URL, it only breaks it up into
> the above listed parts.

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


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

    https://bugs.php.net/bug.php?id=74599


--
Edit this bug report at https://bugs.php.net/bug.php?id=74599&edit=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.