a legacy security.txt can be easily be clearer

[janwillemstegink]

Internet.nl could show test results such as:

Information for legacy does not exist
Only information for legacy exists
The information for legacy is identical
The information for legacy is not identical

Note: It could contain previous confidential information.

Not just for compatibility, but also practical.
For the programmer: An identical url may be an easy way to compare content.

[bwbroersma]

RFC 9116 states:

3. Location of the security.txt File

For web-based services, organizations MUST place the "security.txt" file under the "/.well-known/" path, e.g., https://example.com/.well-known/security.txt as per [RFC8615] of a domain name or IP address. For legacy compatibility, a "security.txt" file might be placed at the top-level path or redirect (as per Section 6.4 of [RFC7231]) to the "security.txt" file under the "/.well-known/" path. If a "security.txt" file is present in both locations, the one in the "/.well-known/" path MUST be used.

So the legacy location MUST be ignored it's also found in "/.well-known/", therefore I don't think we should do compares (also quite complex, the content could also be 'the same' but ordered differently).
I would tend to agree a legacy location could give an ℹ️ informational.

[janwillemstegink]

Code in https://www.hostingtool.nl/server_headers/:

[bwbroersma]

• Closing this in favor of No hint when only using legacy security.txt location #1510.
  Compare won't be done, since the RFC standard clearly specifies the /.well-known/-variant over the other.