Feature request for origin matching

[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.

[oalders]

Thanks, @phschafft. Are you volunteering or is this strictly a request?

[phschafft]

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.

[oalders]

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.

[phschafft]

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:

1. 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.

[oalders]

This sounds like a good approach, @phschafft.