|
25 | 25 | parse them correctly. |
26 | 26 | </para> |
27 | 27 | <caution> |
28 | | - <para> |
29 | | - This function may not give correct results for relative or invalid URLs, |
30 | | - and the results may not even match common behavior of HTTP clients. |
31 | | - If URLs from untrusted input need to be parsed, extra validation is |
32 | | - required, e.g. by using <function>filter_var</function> with the |
33 | | - <constant>FILTER_VALIDATE_URL</constant> filter. |
34 | | - </para> |
| 28 | + <simpara> |
| 29 | + This function does not follow any established URI or URL standard. |
| 30 | + It will return incorrect or non-sense results for relative or malformed |
| 31 | + URLs. Even for valid URLs the result may differ from that of a |
| 32 | + different URL parser, since there are multiple different URL-related |
| 33 | + standards that target different use cases and that differ in their |
| 34 | + requirements. |
| 35 | + </simpara> |
| 36 | + <simpara> |
| 37 | + Processing an URL with parsers following different URL standards is a |
| 38 | + common source of security vulnerabilities. As an example, validating |
| 39 | + an URL against an allow-list of acceptable hostnames with parser A |
| 40 | + might be ineffective when the actual retrieval of the resource uses |
| 41 | + parser B that extracts hostnames differently. |
| 42 | + </simpara> |
| 43 | + <simpara> |
| 44 | + The <classname>Uri\Rfc3986\Uri</classname> and <classname>Uri\WhatWg\Url</classname> |
| 45 | + classes strictly follow the RFC 3986 and WHATWG URL Standards respectively. |
| 46 | + It is strongly recommended to use these classes for all newly written code |
| 47 | + and to migrate existing uses of the <function>parse_url</function> function |
| 48 | + to these classes, unless the <function>parse_url</function> behavior needs |
| 49 | + to be preserved for compatibility reasons. |
| 50 | + </simpara> |
35 | 51 | </caution> |
36 | 52 | </refsect1> |
37 | 53 |
|
|
0 commit comments