From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Maximiliano Sandoval <m.sandoval@proxmox.com>
Subject: [pve-devel] applied: [PATCH http-server v3] http: support Content-Encoding=deflate
Date: Thu, 18 Apr 2024 14:47:44 +0200 [thread overview]
Message-ID: <aa34a792-86e8-4c04-9c14-497135dbd86e@proxmox.com> (raw)
In-Reply-To: <20240418091635.227368-1-m.sandoval@proxmox.com>
Am 18/04/2024 um 11:16 schrieb Maximiliano Sandoval:
> Add support for compressing the body of responses with
> `Content-Encoding: deflate` following [RFC9110]. Note that in this
> context `deflate` is actually a "zlib" data format as defined in
> [RFC1950].
>
> To preserve the current behavior we prefer `Content-Encoding: gzip`
> whenever `gzip` is listed as one of the encodings in the
> `Accept-Encoding` header and the data should be compressed.
>
> [RFC9110] https://www.rfc-editor.org/rfc/rfc9110#name-deflate-coding
> [RFC1950] https://www.rfc-editor.org/rfc/rfc1950
>
> Suggested-by: Lukas Wagner <l.wagner@proxmox.com>
> Tested-by: Folke Gleumes <f.gleumes@proxmox.com>
> Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
> ---
>
> Differences from v2:
> - Remove redundant post-ifs
> - Add Tested-by: Folke Gleumes trailer
thanks, but please add new trailers always to the bottom of the existing
trailer list.
>
> Differences from v1:
> - The commit documents the behavior better
> - Add Suggested-by
> - We set both gzip and deflate in the Accept-Encoding header if available
>
> src/PVE/APIServer/AnyEvent.pm | 28 ++++++++++++++++++++++------
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
>
applied, thanks!
While I applied this, I still got some questions:
- this uses the default compression level [0], was this chosen by default,
did you test throughput of the various different levels, e.g. with some
bigger API call to see if it would be worth it to go for a lower or higher
level – doing a rough evaluation of this might still be good.
- you use the compression interface, not the deflate one, the former talks
about RFC 1950 data streams, which often are using the deflate algorithm
but, as per that RFC, do not necessarily have to.
Why not use the deflate interface to ensure it's always using the correct
algorithm?
[0]: https://metacpan.org/pod/Compress::Zlib#COMPRESS/UNCOMPRESS
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2024-04-18 12:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-18 9:16 [pve-devel] " Maximiliano Sandoval
2024-04-18 12:47 ` Thomas Lamprecht [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aa34a792-86e8-4c04-9c14-497135dbd86e@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=m.sandoval@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox