Content-Encoding

[zweibieren]

Compression can greatly improve response speed, so discarding Content_Encoding headers is unfortunate.

One possibility is to define header X-SendFile-Content-Encoding, which xsendfile would convert into a Content-Encoding header. (The file being sent would be expected to be already correctly encoded.)

It does appear, however, that nmaier has moved on to other great work. Is there any hope of someone else taking up the burden?

[Kijewski]

Hey @zweibieren, please have a look at an old comment by me: #22 (comment)

[zweibieren]

Your old note involves commenting out two lines. Neat and effective.

Sadly, those lines are still uncommented in the distribution. I don't really have the option of administering my own x-sendfile, so I was hoping for a more portable/distributable/compatible version.

[jmwebservices]

I am also for a resolution to the Content-Encoding problem. Although I have been using this module for years to send binary files, I just wasted several hours refactoring a caching class that sends text/html responses when I realized the download times increased since the payload was sent uncompressed over the wire.

Without knowing the inner workings of Apache and mod_xsendfile, I would like to suggest the following, and possibly naive, solutions:

1. Allow mod_xsendfile to recognize a X-SENDFILE-GZIP header which contains the full path to the gziped counterpart set in X-SENDFILE. With this, mod_xsendfile can serve either the uncompressed or the compressed version based on the incoming accept-encoding header. It is the programmers responsibility to create the compressed file. Correct me if I am wrong, but @Kijewski modifications moves the burden of parsing the accept-encoding header to the programmer. I am keen on keeping that responsibility to the web server.

2. Support a XSendFileCacheDirectory directive where mod_xsendfile creates and saves the compressed counterpart of the file specified by the X-SENDFILE header and based on the incoming accept-encoding header. Out of the two solutions, this is the most convenient since the programmer will not have to worry about creating the compressed version at all. mod_xsendfile will simply interface with gzip as Apache presumably already does.

[zweibieren]

Based on the ongoing inactivity on X-SENDFILE, I suggest you not hold your breath on this. Sigh. On Sunday, March 10, 2019, 3:12:21 AM EDT, Jerry Martinez <[email protected]> wrote: I am also for a resolution to the Content-Encoding problem. Although I have been using this modules for years to send binary files, I just wasted several hours refactoring a caching class that sends text/html responses when I realized the download times increased since the payload was sent uncompressed over the wire. Without knowing the inner workings of Apache and mod_xsendfile, I would like to suggest the following, and possibly naive, solutions: - Allow mod_xsendfile to recognize a X-SENDFILE-GZIP header which contains the full path to the gziped counterpart set in X-SENDFILE. With this, mod_xsendfile can serve either the uncompressed or the compressed version based on the incoming accept-encoding header. It is the programmers responsibility to create the compressed file. Correct me if I am wrong, but @Kijewski modifications moves the burden of parsing the accept-encoding header to the programmer. I am keen on keeping that responsibility to the web server. - Support a XSendFileCacheDirectory directive where mod_xsendfile creates and saves the compressed counterpart of the file specified by the X-SENDFILE header and based on the incoming accept-encoding header. Out of the two solutions, this is the most convenient since the programmer will not have to worry about creating the compressed version at all. mod_xsendfile will simply interface with gzip as Apache presumably already does. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.