Unable to query metadata that ends in .xml or a /

[andrewbcoyle]

This appears to be similar to #193. We are upgrading from 1.1.0 to 2.1.x. Currently I am testing 2.1.2. I am finding that, although all our SP metadata fiels are in our metadata aggregate used for MDQ, when entities ending in .xml or a trailing slash do not return metadata. They just return "Not found".

I apologize if this is a duplicate request, but I do not see any proposed solutions. How can we get pyff to query all entityID's no matter their spelling?

Pipeline with specifics removed:

- when update:
    - load:
        - /$my_aggregate.xml
    - break
- when request:
    - select
    - pipe:
        - when accept application/samlmetadata+xml application/xml:
             - xslt:
                 stylesheet: tidy.xsl
             - first
             - sign:
                 key: /$my_key.key
                 cert: /$my_cert.crt
             - emit application/xml
             - break
        - when accept application/json:
             - discojson
             - emit application/json:
             - break

E.G. for entityID "http://alation.com/" In the logs I see 2025-06-02 16:24:47 INFO pyff.builtins selecting using args: ['http://alation.com'] indicating the trailing slash is removed.

[CzNorbi]

I'm facing a similar issue. Here's what I'm observing:

• When I request a JSON response, the response is an empty list ([]).
• When I request an XML response, but it returns an <md:EntitiesDescriptor> instead of singe entity.

[theseal]

I think I solved the problem with trailing slashes in #302. Main maintainer @mikaelfrykholm will take a look at it when back from vacation.

The content-type issues can be solved by setting the --content_negotiation_policy according to easy to find documentation:

pyFF/src/pyff/api.py

Lines 218 to 230 in 62fe3e2

	# content_negotiation_policy is one of three values:
	# 1. extension - current default, inspect the path and if it ends in
	# an extension, e.g. .xml or .json, always strip off the extension to
	# get the entityID and if no accept header or a wildcard header, then
	# use the extension to determine the return Content-Type.
	#
	# 2. adaptive - only if no accept header or if a wildcard, then inspect
	# the path and if it ends in an extension strip off the extension to
	# get the entityID and use the extension to determine the return
	# Content-Type.
	#
	# 3. header - future default, do not inspect the path for an extension and
	# use only the Accept header to determine the return Content-Type.

It might be time to switch the default as stated in the docs.

[theseal]

There is a cache problem when switching content-type. Will try to solve that as-well in the PR above.

[CzNorbi]

I have also created a PR to fix this issue. #301

[theseal]

Ah didn't see your PR before I started my work @CzNorbi.