Fix #79178 parse_url check control chars on host

[nawarian]

This PR aims to fix the bug ticket #79178.

There's something bothering me though:
php_replace_controlchars_ex seems to replace every control char with _ instead of panicking.

Meanwhile, RFC 1738 says the following:

URLs are written only with the graphic printable characters of the US-ASCII coded character set. The octets 80-FF hexadecimal are not used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent control characters; these must be encoded.

The above states that characters like new line should be encoded. PHP, for some reason I couldn't figure out so far, replaces them with underscores.

Even though this fixes the bug on PHP_URL_HOST, the same issue still happens on other URL parts.

<?php

// There's no backslash after .net and before PHP_EOL!!
var_dump(parse_url('https://php.net' . PHP_EOL));
// bool(false)

// There IS a backslash after .net and before PHP_EOL!!
var_dump(parse_url('https://php.net/' . PHP_EOL));
// array(3) {
//   ["scheme"]=>
//   string(5) "https"
//   ["host"]=>
//   string(7) "php.net"
//   ["path"]=>
//   string(2) "/_"
// }

Path seems to be still wrong in my opinion.

Shall we discuss a better solution for this maybe?

[patrickallaert]

Last message on related issue:

The "_" has been used to prevent CR/LF injection issues, see: 184323c

I don't really know what you should expect from parse_url() provided that you give him an invalid URL.

Expecting "yandex.ru" while the host "yandex.ru\n" has been provided feels wrong to me.

What would you expect from:

var_dump(parse_url("http://yan\ndex.ru\n", PHP_URL_HOST));

for example?

To me, your case and the one above could equally give: bool(false) IMHO.

I am closing this issue (and the related PR) as it isn't really a bug, nor it has evolved in 17 months and there is no clear outcome of what to expect from parsing invalid URLs.

You are very welcome to re-open this issue and/or it's PR if you have more thoughts about it.