Fix MDQ Endpoint Behavior for EntityIDs with .xml or Trailing Slash

[CzNorbi]

Problem

In PyFF 2.x, the MDQ handler attempts to parse the URL path and remove the extensions (like .xml or .json) under the assumption that these are used to indicate the desired response format.

However, in some cases, clients request metadata using fully encoded entityIDs like:

/entities/https%3A%2F%2Fidp.example.org.xml

In this case, the .xml is part of the actual entityID. PyFF would remove this suffix and attempt to resolve https://idp.example.org, which does not exist in the metadata. The result is an empty EntitiesDescriptor in XML responses or an empty list in JSON.

Solution

This patch modifies the _d() function to:

Only strip .xml or .json suffixes if the remaining path does not appear to be a percent-encoded entityID or a hash-based entityID ({sha1}, {sha256}, {md5}).
If the entityID appears to be encoded or hashed and ends in .xml or .json, it is treated as part of the true entityID and preserved during lookup.

Additional fix: Preserves a trailing / if present in the request path.

[andrewbcoyle]

I really appreciate everyone taking a look at this.

FWIW, I do not consider in-line comments in source code "easy to find documentation". I don't consider in-line comments documentation at all. One of the major challenges my team has found troubleshooting this is the only thorough documentation that appears to exist for e.g. "How to customize a pipeline", only exist as in-line comments for each available function. Compare that to, say, Kubernetes documentation.

I can see how that would be enough for the folks who wrote/maintain the code, but for an outsider who is needing to discover how all this works in order to fix something, it is effectively useless. Just finding the relevant documentation is half the battle.

[theseal]

Will not the content_negotiation_policy be enough for solving the content-type issues?