Open phschafft opened 1 year ago
Thanks, @phschafft. Are you volunteering or is this strictly a request?
Thanks, @phschafft. Are you volunteering or is this strictly a request?
First of all it is a request and/or to see if there is a consensus that it will be in best interest for the module.
I'm currently a bit busy, but if nobody else wants to take it I'm happy to have a look.
Nobody has objected to a patch for this, but we're short on people power, so we'd need a PR with some rigorous tests to accompany it.
Is there any specific request for a function name? Otherwise I would go with $uri->has_origin($origin)
. ($origin
being a URI object in canonical form or a string that is auto converted via URI->new($origin)->canonical
.)
I would avoid a getter (only implement matching), as per RFC 6454 Section 4:
- If the URI does not use a hierarchical element as a naming authority (see [RFC3986], Section 3.2) or if the URI is not an absolute URI, then generate a fresh globally unique identifier and return that value.
It is unclear/implementation specific what a "globally unique identifier"'s value is: From RFC 6454 Section 2.3:
A globally unique identifier is a value that is different from all other previously existing values. For example, a sufficiently long random string is likely to be a globally unique identifier. If the origin value never leaves the user agent, a monotonically increasing counter local to the user agent can also serve as a globally unique identifier.
If there are no objects and time allows I would have a look at this the next days.
This sounds like a good approach, @phschafft.
It would be very nice to have a function similar to
eq()
performing same-origin matching. Such a feature could be used by other modules to calculate service boundaries, blacklisting, per-site settings etc.It is defined in RFC 6454 Section 4 and Section 5.