[RFC] Add RFC 3986 and WHATWG compliant URL parsing support

[kocsismate]

2nd take after the failed experiment with #11315

RFC: https://wiki.php.net/rfc/url_parsing_api

[kocsismate]

Removed for benchmarking purposes

[kocsismate]

Approach is copy-pasted from lexbor/lexbor#206

[nielsdos]

I need to pull in a new version of Lexbor as well in 8.4 for the GB18030 changes so I'll handle the encoding changes.

[kocsismate]

@nielsdos Ah thanks for the link! I totally missed the readme :/ TBH I silenced the compiler errors with -Wno-int-conversion.

I was about to report your findings back to my Lexbor issue, but I've just seen that you beat me to do it :)

[nielsdos]

TBH I silenced the compiler errors with -Wno-int-conversion.

I'll make a PR to update Lexbor now, then once that's merged you can rebase on master and get rid of the warning silencer.

[kocsismate]

@nielsdos I would like to ask your opinion about a problem I recently realized.

Context: I added a normalize_uri handler that is able to normalize the URI. It is used in multiple places (e.g. normalize(), toNormalizedString, equalsTo() methods). However, this would possibly cause some unexpected behavior when a built-in URI is extended in userland: if a child class overrides the normalize() method, they would legitimately assume that doing so will affect the rest of the relevant methods (toNormalizedString(), equalsTo()), but no, this won't be the case, since the internal handler is reused in fact... which PHP programmers have no control over. I can see two solutions so far:

• make the built-in URI implementations final: there's no more problem with method overrides, but using composition instead of inheritance requires more work (implementing all the methods of the UriInterface), you can't just substitute an internal URI class with your own implementation etc.
• the normalize() method itself should be called instead of the normalize_uri internal handler: this solves the issue, but it results in quite some performance overhead

Do you have any preference/insights about this question?

[nielsdos]

@kocsismate Interesting.

Here's an idea:
We can know upfront if the "normalize" method is overridden when we create the internal uri object. We can do this by checking whether the entry for "normalize" in the function table has type ZEND_USER_FUNCTION instead of ZEND_INTERNAL_FUNCTION. In that case, we know we should call the user handler, otherwise we should call the internal handler.

Create a helper function invoke_normalize_uri (name is just illustrative) that you use to invoke either the internal normalize handler or the user function. Then you can use invoke_normalize_uri everywhere without worrying. To make the invocation fast you can have a zend_function* field in the internal object that is NULL when the user did not override it, and points to the user function if the user did override it. Then you can use the Zend APIs to call that user function if necessary.

[kocsismate]

@nielsdos Thanks for the brilliant idea! :) That's really impressive. I'll have to think about in which cases a similar issue can happen, but if it's not too frequent, then your solution will perfectly mitigate it. I wouldn't like though if i.e. all the property reader functions would have to use this workaround, but hopefully it won't be the case.