You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rather than having to gzip on the fly, other static file server middleware have the ability to serve a pre-gzipped file based on the file name and extension to avoid the overhead of gzip on the fly (sometimes this feature can even create the gzipped file the first time so subsequent requests can make use of it).
Ideal Solution
At the very minimum, check if there is a .gz file for the resource in question. If there is, use that file content instead, set the appropriate content-encoding, and use the non-gz extension for the content-type.
Why can't this be implemented outside of Rocket?
I tried wrapping the FileServer but I couldn't edit the request to change the URI... and even if I could, I'm not sure that's a really clean way of doing things... because the request wasn't for that file.
Are there workarounds usable today?
Nothing that I've found that is maintainable.
Alternative Solutions
Maybe if fileServer could be given an optional function to help locating the source of the file and adjusting the header.
That could still lead to confusion when trying to set the correct headers based on a previous call to another function that redirected the source of the response. Would make the attempt to unify the response very disjointed.
Additional Context
FileServer lacks gzip capabilities, and issues in the past on this tracker have lamented the performance of gip-on-the-fly approaches.
System Checks
I do not believe that this feature can or should be implemented outside of Rocket.
I was unable to find a previous request for this feature.
The text was updated successfully, but these errors were encountered:
What's missing?
Rather than having to gzip on the fly, other static file server middleware have the ability to serve a pre-gzipped file based on the file name and extension to avoid the overhead of gzip on the fly (sometimes this feature can even create the gzipped file the first time so subsequent requests can make use of it).
Ideal Solution
At the very minimum, check if there is a .gz file for the resource in question. If there is, use that file content instead, set the appropriate content-encoding, and use the non-gz extension for the content-type.
Why can't this be implemented outside of Rocket?
I tried wrapping the FileServer but I couldn't edit the request to change the URI... and even if I could, I'm not sure that's a really clean way of doing things... because the request wasn't for that file.
Are there workarounds usable today?
Nothing that I've found that is maintainable.
Alternative Solutions
Maybe if fileServer could be given an optional function to help locating the source of the file and adjusting the header.
That could still lead to confusion when trying to set the correct headers based on a previous call to another function that redirected the source of the response. Would make the attempt to unify the response very disjointed.
Additional Context
FileServer lacks gzip capabilities, and issues in the past on this tracker have lamented the performance of gip-on-the-fly approaches.
System Checks
The text was updated successfully, but these errors were encountered: