Edgar Friendly <thelema at cs-mercury.truman.edu> writes: > > But for the first alternative, accessing CHK at xyz directly will not > > give you a proper MIME type, [...]
> If this is the case, fproxy (or whatever client you're using) needs to > be fixed. How is fproxy going to whip up the MIME type from thin air? > > Do we really need to work around these insertion mistakes? In a way > > it's /not/ the same data if it has a different MIME type. > But there's no reason to hold two copies of a large CHK if the only > thing that differs is the MIME type. Did I say there was? But deprecating metadata on CHKs is not the only solution to this common(?) mistake. I'd rather see insert clients give users more guidance about the MIME type. -- Robbe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.ng Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021103/5f2d1a62/attachment.pgp>
