From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id BBC861FF16B for ; Tue, 15 Jul 2025 12:56:57 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1C5983970B; Tue, 15 Jul 2025 12:57:56 +0200 (CEST) Message-ID: Date: Tue, 15 Jul 2025 12:57:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Thomas Lamprecht , Yew framework devel list at Proxmox , Shannon Sterz References: <20250710102812.2480856-1-d.csapak@proxmox.com> <20250710102812.2480856-2-d.csapak@proxmox.com> <5a4469d2-9904-4284-bffa-90105f053a86@proxmox.com> <774a7343-86c0-4f38-8066-7e69c3114ef8@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <774a7343-86c0-4f38-8066-7e69c3114ef8@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.022 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_MSPIKE_H2 0.001 Average reputation (+2) RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [anyevent.pm] Subject: Re: [yew-devel] [PATCH http-server 1/1] api server: add 'wasm' as valid extension X-BeenThere: yew-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Yew framework devel list at Proxmox List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Yew framework devel list at Proxmox Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: yew-devel-bounces@lists.proxmox.com Sender: "yew-devel" On 7/15/25 11:26, Thomas Lamprecht wrote: > Am 14.07.25 um 14:05 schrieb Dominik Csapak: >> On 7/14/25 14:00, Shannon Sterz wrote: >>> On Thu Jul 10, 2025 at 12:28 PM CEST, Dominik Csapak wrote: >>>> otherwise the server won't serve wasm files to the client. >>>> >>>> Signed-off-by: Dominik Csapak >>>> --- >>>> src/PVE/APIServer/AnyEvent.pm | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/src/PVE/APIServer/AnyEvent.pm b/src/PVE/APIServer/AnyEvent.pm >>>> index 8f2c3ff..b00e074 100644 >>>> --- a/src/PVE/APIServer/AnyEvent.pm >>>> +++ b/src/PVE/APIServer/AnyEvent.pm >>>> @@ -431,6 +431,7 @@ my $file_extension_info = { >>>> mp3 => { ct => 'audio/mpeg', nocomp => 1 }, >>>> oga => { ct => 'audio/ogg', nocomp => 1 }, >>>> tgz => { ct => 'application/x-compressed-tar', nocomp => 1 }, >>>> + wasm => { ct => 'application/wasm' }, >>> >>> just a quick question: do you intend to serve the mobile quarantaine as >>> pure wasm or as a gzip-ed archive like we do now for pdm & peat? because >>> in the later case, the content type "application/octet-stream" is fine >>> to my understanding anyway. >> >> currently i have it served as wasm but it'll be compressed by >> the proxy daemon on the fly. > > Seems like a waste of resources compared to a plain sendfile when > doing the compression on build like in PDM. We naturally do not > have any usage numbers, but there are some bigger known deployments, > so this might see some usage. > >> imho if we'd want to precompress it, I'd add >> 'wasm.gz' for example as an additional content type >> >> Ideally, we could precomress it in a way that the browser still gets the correct >> content-type (wasm) and the http response has the right content-encoding header >> (gzip) but that would require a bit of work in the api server I think > > But is that always correct? what do you mean? if the file is a gzip compressed wasm. setting the content-encoding to gzip and content-type to wasm seems to be the right choice? > Anyhow, for now using something like > DecompressionStream + manually setting the content type in the > header (which just improves performance) would be enough IMO. So like we do it in pdm? Sure, we can do that. just to note that we do compress the remaining resources in pve/pmg on the fly (js/css/etc. which add up to a few megabyte too) _______________________________________________ yew-devel mailing list yew-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/yew-devel