Open patrick-werner opened 5 years ago
I love the idea- triggering it by parameter seems a little bit hard to discover though. I wonder if there is any reason to not just always normalize CodeSystem/ValueSet URIs.
I think my vote would be a method in UrlUtil called something like normalizeCanonicalUri
that strips trailing slashes.. it could be called from anywhere we're gonna be comparing CS/VS URIs.
Can it be ignored? Any standards basis for that claim?
Sent from my iPhone
On 3 Sep 2019, at 9:43 am, James Agnew notifications@github.com wrote:
I love the idea- triggering it by parameter seems a little bit hard to discover though. I wonder if there is any reason to not just always normalize CodeSystem/ValueSet URIs.
I think my vote would be a method in UrlUtil called something like normalizeCanonicalUri that strips trailing slashes.. it could be called from anywhere we're gonna be comparing CS/VS URIs.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
This StackOverflow has some discussion on the subject, and seems to conclude that URIs that differ only in the trailing slash are equivalent only if the trailing slash is at the root path.
I think I'd see this as a postel's law kind of thing though. I haven't personally seen any cases where a trailing slash meaningfully distinguished a canonical URI from a different URI.
There’s a pretty thorough discussion here that recommends supporting both and canonicalizing:
https://www.seoblog.com/remove-trailing-slash-urls/
On Mon, Sep 2, 2019 at 8:01 PM James Agnew notifications@github.com wrote:
This StackOverflow https://stackoverflow.com/questions/39717742/http-ftp-does-trailing-slash-in-url-mean-another-resource has some discussion on the subject, and seems to conclude that URIs that differ only in the trailing slash are equivalent only if the trailing slash is at the root path.
I think I'd see this as a postel's law kind of thing though. I haven't personally seen any cases where a trailing slash meaningfully distinguished a canonical URI from a different URI.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jamesagnew/hapi-fhir/issues/1462?email_source=notifications&email_token=AANBORRF23PC3SC2ECX7CYDQHWSPJA5CNFSM4IS54I52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5WVTHY#issuecomment-527260063, or mute the thread https://github.com/notifications/unsubscribe-auth/AANBORQAUMRCXT2VIKKIEUTQHWSPJANCNFSM4IS54I5Q .
Can it be ignored? Any standards basis for that claim?
actually yes: https://tools.ietf.org/html/rfc3986#section-6.2.4
And i don't see a reason why we should distinguish between http://organisation/foo and http://organisation/foo/ as a organisation creating URIs in their namespace shouldn't declare distinct CS/VS with the same URI with only a trailing slash as difference.
Describe the issue If there is a mismatch between the URI of a CS/VS and the Coding/Binding of an Instance because of a trailing backslash (which can be ignored) the Validation fails as the system will not be found.
My proposal is to extend IValidationSupport by a default method which removes trailing slashes of URIs and call it from the relevant methods of the implementing classes. Would Implement that as an optional feature, triggered by a parameter.
Would this be a desired feature?
(kind of related zulip topic with Grahame proposing such a functionality: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Trailing.20slashes.20in.20code.20system.20URLs.3F)