i'm playing around with a thought in my head re: URIs and what they identify, in a world where dereferencing that URI usually gets you some text/html
-
i'm playing around with a thought in my head re: URIs and what they identify, in a world where dereferencing that URI usually gets you some text/html
i think using the bare URI to identify the page or document itself is unnecessary, because you can just slap an id="page" attribute on the <html> element if you need to make statements about the page itself.
similarly, slap an id="article" on your <article> if need be.
of course you can also align your fragment ids to other formats like json...
-
i'm playing around with a thought in my head re: URIs and what they identify, in a world where dereferencing that URI usually gets you some text/html
i think using the bare URI to identify the page or document itself is unnecessary, because you can just slap an id="page" attribute on the <html> element if you need to make statements about the page itself.
similarly, slap an id="article" on your <article> if need be.
of course you can also align your fragment ids to other formats like json...
it's a bit unfortunate that a lot of fedi naively expects id to never be a fragment identifier. and in some particularly unfortunate cases, somehow they baked it into their security model, too -- the top-level object's id is expected to match what they requested *after* chopping off the fragment, not *before*.
-
it's a bit unfortunate that a lot of fedi naively expects id to never be a fragment identifier. and in some particularly unfortunate cases, somehow they baked it into their security model, too -- the top-level object's id is expected to match what they requested *after* chopping off the fragment, not *before*.
Some of it might be due to web browsers. I am not sure it's 100% of them, but I've seen some browsers stripping fragments to the URL string when making a request, so if you had an inbox url that was "https://example.com/my-actor#inbox", it would try to make the POST request to "https://example.com/my-actor".
-
Some of it might be due to web browsers. I am not sure it's 100% of them, but I've seen some browsers stripping fragments to the URL string when making a request, so if you had an inbox url that was "https://example.com/my-actor#inbox", it would try to make the POST request to "https://example.com/my-actor".
@raphael that's part of how HTTP works -- your HTTP request doesn't include the fragment, but the HTTP user agent can handle the fragment resolution after it receives its HTTP response.
for inboxes: inboxes are more like endpoints. i guess you could use a fragment, but it wouldn't mean anything for HTTP POST. it would only mean something for when you HTTP GET and are looking for a subresource fragment.
-
@raphael that's part of how HTTP works -- your HTTP request doesn't include the fragment, but the HTTP user agent can handle the fragment resolution after it receives its HTTP response.
for inboxes: inboxes are more like endpoints. i guess you could use a fragment, but it wouldn't mean anything for HTTP POST. it would only mean something for when you HTTP GET and are looking for a subresource fragment.
@raphael really, that's kind of the whole point of a "fragment" identifier, it identifies a "fragment" of the resource, and its semantics are determined by the media type.
for text/html, a fragment corresponds to an id= attribute or otherwise can be read by javascript. see https://www.iana.org/assignments/media-types/text/html for "Fragment identifier considerations"
