nostr:npub12x8ywtnvel5r0frfzv45sj2xzws97dzt84t3wz6uxc5em9a2erws8fmjy3 nostr:npub1yqwcsafkzl4fequd25qg6yvmyxusk8gmpe7hkpfcnzc34afx4npsfhwajx nostr:npub1dft4ckvyhfpw3n56zm8j42nzrjeummudr2vmkf304eu5jhnn0ahqz7ta3d The content-type Will be set correctly. That seems to me to be the only sensible way.
nostr:npub1yqwcsafkzl4fequd25qg6yvmyxusk8gmpe7hkpfcnzc34afx4npsfhwajx nostr:npub1jtm4dxvu3ccgk60wvvt0uw9j9vz7nuc80f7agrv0vgkkushxk5zq0rrxtn nostr:npub1dft4ckvyhfpw3n56zm8j42nzrjeummudr2vmkf304eu5jhnn0ahqz7ta3d
I see what's going on. The image URL's in James's chapters file are using an encoded URL parameter format that our "local image caching" handler can't handle. PV is assuming the image URLs end with a file extension (.jpg, .png, etc.) but these do not. We need to assign a file extension before saving images to our cache.
I actually don't even know how we can reliably parse out what the image file type is for URLs like this. Anyone have ideas?
Discussion
nostr:npub1jtm4dxvu3ccgk60wvvt0uw9j9vz7nuc80f7agrv0vgkkushxk5zq0rrxtn nostr:npub1yqwcsafkzl4fequd25qg6yvmyxusk8gmpe7hkpfcnzc34afx4npsfhwajx nostr:npub1dft4ckvyhfpw3n56zm8j42nzrjeummudr2vmkf304eu5jhnn0ahqz7ta3d
it's a good call, and I started down that road...but this looks like we're going to have to introduce another layer of storage and data mapping to be able to handle...
we can *request from server and save* the image no problem with a HEAD request...but then to get the chapter image out of our local storage/cache, we only have the original chapter image URL to work with, and at that point we don't know the extension again, so we don't know the file path in storage...