openvsx
openvsx copied to clipboard
eclipse
Enable compression
Contributes to #379
Enabled compression
Added Content-Type response header to SitemapController, so that the response is recognized as XML
Added paging for extensionId and extensionName queries
You can test compression by navigating to a couple endpoints in your browser, open the developer tools and check that the Content-Encoding: gzip header is set. The transfer size of the response should be significantly lower than the actual size of the response. Endpoints to test:
-
/sitemap.xml, Content-Type header should beapplication/xml -
/api/-/query?extensionId={extensionId}&includeAllVersions=true -
/admin/log, delete some extensions first to generate log entries
If the response is below 1024 bytes (1kB) the response isn't compressed, e.g. the /admin/report?token={token}&year=2022&month=2 currently only returns a couple bytes.
You can test extensionquery paging by posting a request with multiple extension name filter objects and setting pageSize to 1.
You can then play with the pageNumber field.
The response should contain 1 extension, but the TotalCount field should be the same as the number of filter objects in the request. When the pageNumber is greater than TotalCount, then the response should contain an empty extensions array.
I've already enabled compression at the spring level on production with https://github.com/EclipseFdn/open-vsx.org/commit/adfde558e8aafd6453b8bdd47144f9d2f3eb0183. Will this have an impact?
I've already enabled compression at the spring level on production with EclipseFdn/open-vsx.org@adfde55. Will this have an impact?
Ok, then this PR only contains a few minor improvements. Can you or @eclipsewebmaster update #379 to reflect the current situation or close it if bandwidth usage is acceptable?
@akosyakov No, compression was already enabled in EclipseFdn/open-vsx.org.
@akosyakov @filiptronicek I've reduced this PR to only setting Content-Type: application/xml for the /sitemap.xml endpoint.