Thanks for this.

MementoEmbed uses the requests library to find the values for the Link header. requests presents all HTTP headers as a case-insensitive dictionary. If a header is specified multiple times, requests is smart enough to combine the values together, so MementoEmbed does actually get all of the values for Link.

The problem exists in the function convert_LinkTimeMap_to_dict seen on lines 108-109 above. This function expects all relations to be surrounded by quotes (e.g., rel="timegate" is parseable, but rel=timegate fails). Link header values like <https://wp.me/4cEB>; rel=shortlink are a product of WordPress. They do not surround the argument to rel in quotes. Memento entries in the Link header, on the other hand, do surround the argument to rel in quotes (e.g., rel="timegate"). The convert_LinkTimeMap_to_dict function is stumbling over that shortlink relation because it has no quotes and it never gets to parse the rest of the string.

All examples in RFC 8288 - Web Linking use quotes, but section 3 states:

Note that any link-param can be generated with values using either
the token or the quoted-string syntax; therefore, recipients MUST be
able to parse both forms. In other words, the following parameters
are equivalent:

x=y
x="y"

and

Previous definitions of the Link header did not equate the token and
quoted-string forms explicitly; the title parameter was always
quoted, and the hreflang parameter was always a token. Senders
wishing to maximize interoperability will send them in those forms.

So, MementoEmbed needs to support both.

I have discovered a possible solution. The requests library has its own link format parsing function. When I tested this function a few years ago, it failed miserably on parsing Memento headers, but a recent test last weekend indicates that it may have matured enough for us to use here.

It looks like the requests library implementation works.

I will have to test with some other URI-Ms.