HTTP 压缩 - 如何发送 EAR 文件中存在的预压缩文件？
是否可以发送 EARfile 中包含的预压缩文件？ 更具体地说，是 WAR 文件中的 jsp 和 js 文件。 我使用 Apache HTTP 作为 Web 服务器，虽然打开 deflate 模块并将其设置为使用文件的预压缩版本很简单，但我想将其应用于 EAR 文件中包含的文件部署到 JBoss。 原因是内容是相当静态的，并且每次动态压缩它在 CPU 时间方面的成本相当高。
坦率地说，我并不完全熟悉 JBoss 如何部署这些 EAR 文件并“服务”它们。 我想要做的要点是预压缩 war 中包含的文件，以便当需要它们时，它们会使用 gzip 发送回客户端进行内容编码。
Is it possible to send pre-compressed files that are contained within an EARfile? More specifically, the jsp and js files within the WAR file. I am using Apache HTTP as the web server and although it is simple to turn on the deflate module and set it up to use a pre-compressed version of the files, I would like to apply this to files that are contained within an EAR file that is deployed to JBoss. The reason being that the content is quite static and compressing it on the fly each time is quite costly in terms of cpu time.
Quite frankly, I am not entirely familiar with how JBoss deploys these EAR files and 'serves' them. The gist of what I want to do is pre-compress the files contained inside the war so that when they are requested they are sent back to the client with gzip for Content-Encoding.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
理论上，您可以在将它们打包到 EAR 之前对其进行压缩，然后使用自定义控制器提供它们，该控制器将 http 标头添加到响应中，告诉客户端它们已被压缩，但这似乎需要付出很大的努力。到。
当您说即时压缩成本相当高时，您是否实际测量过它？ 您是否尝试过请求大量未压缩页面，测量CPU使用率，然后再次与压缩页面捆绑在一起？ 我认为您可能高估了影响。 它使用相当低强度的流压缩，旨在使用很少的 CPU 资源。
在不遗余力地缓解性能问题之前，您需要非常确定确实存在性能问题。
In theory, you could compress them before packging them in the EAR, and then serve them up with a custom controller which adds the http header to the response which tells the client they're compressed, but that seems like a lot of effort to go to.
When you say that on-the-fly compression is quite costly, have you actually measured it? Have you tried requesting a large number of uncompressed pages, measured the cpu usage, then tied it again with compressed pages? I think you may be over-estimating the impact. It uses quite low-intensity stream compression, designed to use little CPU resources.
You need to be very sure that you have a real performance problem before going to such lengths to mitigate it.
我不经常访问这个网站，而且我似乎已经把这个话题挂在一边了。 对于那个很抱歉。 我确实成功地压缩了我的 javascript 和 css 文件。 我所做的是在 ant 构建过程中使用 gzip 预压缩它们。 然后我不得不欺骗这个名字来摆脱 gzip 扩展名。 所以我有 foo.js 并将其压缩为 foo.js.gzip。 我将此 foo.js.gzip 重命名为 foo.js，这是打包到 WAR 文件中的文件。 这样就处理了预压缩部分。 为了正确提供该文件，我们只需通过 http 响应的内容编码标头告诉浏览器该文件已被压缩。 这是通过输出过滤器完成的，该过滤器应用于与 *.js 扩展名匹配的文件（一些 Java/JBoss、WEB-INF/web.xml 如果有帮助的话。我对此不太熟悉，所以对不起大家）。
I don't frequent this site often and I seem to have left this thread hanging. Sorry about that. I did succeed in getting compression to my javascript and css files. What I did was I precompress them in the ant build process using the gzip. I then had to spoof the name to get rid of the gzip extension. So I had foo.js and compressed it into foo.js.gzip. I renamed this foo.js.gzip to foo.js and this is the file that gets packaged into the WAR file. So that handles the precompression part. To get this file served up properly, we just have to tell the browser that this file is compressed, via the content-encoding header of the http response. This was done via a output filter that is applied to files that matched the *.js extension (some Java/JBoss, WEB-INF/web.xml if it helps. I'm not too familiar with this so sorry guys).