-
@ Anthony Accioly
2025-05-13 10:36:58
Morning nostr:nprofile1qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgpzfmhxue69uhkummnw3e82efwvdhk6tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszythwden5te0dehhxarj9emkjmn99urf278z. Many thanks!
Yes, this makes sense. The "default implementation" redirects GET /{sha256}[.ext] to some other URL containing {sha256}[.ext], as per the specs (and I’d love to make the extension non-optional to avoid Content-Type shenanigans, as per my ticket on your repo).
Of course, since Khatru is more of a framework, we need to leave the functionality open to extension, and the user can indeed write a custom handler to redirect to a URL that doesn’t end with {sha256}[.ext]. But I don’t see much that can be done in Khatru to prevent this, other than maybe adding a line or two to the docs asking users to keep the hash intact in redirect URLs.
I had to do some... Interesting things.... on my IPFS POC to accommodate this. I ended up exposing a URL with both a CID and a SHA256 of the blob to conform to both specs. But it's working and blobs can even be mirrored to picky Blossom servers like blossom.band while serving the main blob P2P (proxied to http by a IPFS gateway) :). How cool is that?
As for this sentence from the specs, if I open a small PR making codes 307 and 308 official, would you mind?
> If the endpoints returns a 301 or 302 redirect it MUST redirect to a URL containing the same sha256 hash as the requested blob.
https://github.com/hzrd149/blossom/blob/master/buds/01.md#:~:text=If,blob.
Both status codes also work with GET, and browser behaviour around caching, etc. is way more predictable than with 301 or 302. Also, we’ll need this if we want to properly redirect, say, OPTIONS requests in the future without some of the browsers converting it to GET.