Ah, yes, Content-Encoding...
1. Does the CGI idea make sense for right now? Or is there an obvious flaw I'm
missing?
For now, a CGI makes sense, but you won't be exposing the file, you
will be exposing a CGI that downloads the file - it's a subtle
difference, but it means it's not quite as easy to download the file
via curl or wget or similar clients. It's a workaround, that's okay,
it's just not ideal.
2. Does the feature sound reasonable for a future version of tipidee?
The problem with Content-Encoding, and a few other similar headers,
is that it falls into a category I did not originally plan for when
writing tipidee: resource-specific custom headers. As in, a custom
header
that you conditionally add depending on what file you're serving. It's
doable, but it means quite a lot of rework in the way resource
attributes
are stored in the configuration database and how custom headers are
added
to the response when serving a file.
So, yeah, it's definitely something that could, and probably should, be
added in a future version of tipidee, but not in the short term, because
it would incur pretty heavy modifications of the engine so I'm not sure
yet when I can devote the energy to it - sorry about that.
Another approach (don't take this too seriously) is to compress *all*
the files you're serving, and add a fixed Content-Encoding custom
header,
valid for everything. 😄
--
Laurent
