From dridi at varni.sh Mon Jan 3 15:57:47 2022 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 3 Jan 2022 15:57:47 +0000 Subject: bo access from VFP In-Reply-To: References: Message-ID: On Fri, Dec 31, 2021 at 11:48 PM Guillaume Quintard wrote: > > Small follow-up on that one: it would be nice for VFP to be able to disable streaming (bo->do_stream), so that's an extra argument to be able to access the busyobj > > -- > Guillaume Quintard > > > On Sun, Dec 26, 2021 at 6:11 PM Guillaume Quintard wrote: >> >> Happy holidays to everyone, Happy new year ! >> Unless I'm mistaken, there's no way for a VFP to access the busyobj, and was wondering if that could change as I need it to retrieve a vmod_priv. I think your statement is correct. >> For some context, I stumbled on this while working on this vmod: https://github.com/gquintard/vmod_rers/tree/v0.0.2 >> (It's in rust, and I'm using it to explore what kind of bindings we need. I already have a couple of examples for VDP[1] and VFP[2] in the crate[3] repo, but of course they don't need as much as a real vmod.) >> >> With vmod_rers, the user is able to add regex/sub pairs on a per-request basis [4], and they will be acted upon by the VDP. To store and retrieve the pairs I use the regular "fake vrt_ctx trick"[4], since the VDP has access to the req struct, it's very easy to build. >> However, I'm unable to do the same thing on the VFP side since I have neither a req (fair) nor a bo. The big difference between both is that we only use VDPs to deliver client responses, but we use VFPs to fetch both beresp and req bodies, so the VFP operates at the objcore level. >> Is there a big reason for not having access to it, or is it just that nobody asked for it until now? Probably nobody never asked for it? Passing a VRT_CTX to the VFP init function could help grab a req or bo and stash it in vfp_entry::priv1, but I don't see a way to do that today without cheating. *cough* THR_GetBusyobj() *cough* Cheers, Dridi From guillaume.quintard at gmail.com Fri Jan 7 02:40:35 2022 From: guillaume.quintard at gmail.com (Guillaume Quintard) Date: Thu, 6 Jan 2022 18:40:35 -0800 Subject: bo access from VFP In-Reply-To: References: Message-ID: As usual, thanks a bunch for all your help! Using the THR_* functions work: https://github.com/gquintard/vmod_rers/blob/270a2f4272be49f8c1c904b899ec91dafcf2f873/src/lib.rs#L227 and they allow me to merge most of the vfp/vdp init code together (helped by the fact the same rust structure is both a VDP and a VFP) It would be even more legible if we had access to the vrt_ctx directly (for both vfp AND vdp) so I wouldn't have to build my own, OR if we hade VRT_priv_task_raw_parts(const req *, const busyobj *, const void *) so I didn't have to build my own context, but that is already pretty sweet Cheers! -- Guillaume Quintard On Mon, Jan 3, 2022 at 7:58 AM Dridi Boukelmoune wrote: > On Fri, Dec 31, 2021 at 11:48 PM Guillaume Quintard > wrote: > > > > Small follow-up on that one: it would be nice for VFP to be able to > disable streaming (bo->do_stream), so that's an extra argument to be able > to access the busyobj > > > > -- > > Guillaume Quintard > > > > > > On Sun, Dec 26, 2021 at 6:11 PM Guillaume Quintard < > guillaume.quintard at gmail.com> wrote: > >> > >> Happy holidays to everyone, > > Happy new year ! > > >> Unless I'm mistaken, there's no way for a VFP to access the busyobj, > and was wondering if that could change as I need it to retrieve a vmod_priv. > > I think your statement is correct. > > >> For some context, I stumbled on this while working on this vmod: > https://github.com/gquintard/vmod_rers/tree/v0.0.2 > >> (It's in rust, and I'm using it to explore what kind of bindings we > need. I already have a couple of examples for VDP[1] and VFP[2] in the > crate[3] repo, but of course they don't need as much as a real vmod.) > >> > >> With vmod_rers, the user is able to add regex/sub pairs on a > per-request basis [4], and they will be acted upon by the VDP. To store and > retrieve the pairs I use the regular "fake vrt_ctx trick"[4], since the VDP > has access to the req struct, it's very easy to build. > >> However, I'm unable to do the same thing on the VFP side since I have > neither a req (fair) nor a bo. > > The big difference between both is that we only use VDPs to deliver > client responses, but we use VFPs to fetch both beresp and req bodies, > so the VFP operates at the objcore level. > > >> Is there a big reason for not having access to it, or is it just that > nobody asked for it until now? > > Probably nobody never asked for it? > > Passing a VRT_CTX to the VFP init function could help grab a req or bo > and stash it in vfp_entry::priv1, but I don't see a way to do that > today without cheating. > > *cough* THR_GetBusyobj() *cough* > > Cheers, > Dridi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Mon Jan 10 07:56:07 2022 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 10 Jan 2022 07:56:07 +0000 Subject: bo access from VFP In-Reply-To: References: Message-ID: On Fri, Jan 7, 2022 at 2:40 AM Guillaume Quintard wrote: > > As usual, thanks a bunch for all your help! > > Using the THR_* functions work: https://github.com/gquintard/vmod_rers/blob/270a2f4272be49f8c1c904b899ec91dafcf2f873/src/lib.rs#L227 and they allow me to merge most of the vfp/vdp init code together (helped by the fact the same rust structure is both a VDP and a VFP) > > It would be even more legible if we had access to the vrt_ctx directly (for both vfp AND vdp) so I wouldn't have to build my own, OR if we hade VRT_priv_task_raw_parts(const req *, const busyobj *, const void *) so I didn't have to build my own context, but that is already pretty sweet https://github.com/varnishcache/varnish-cache/pull/3772 From scan-admin at coverity.com Mon Jan 31 11:12:19 2022 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 31 Jan 2022 11:12:19 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <61f7c413361cc_1ee432ad3b717599843249@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yrJbcjUxJo9eCHXi2QbgV6mmItSKtPrD4wtuBl7WlE3MQ-3D-3DT2d2_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je49edo4-2Fp9-2FGAMzgH5YifVG-2FMdE4gC-2FWLmKriDXRdyfPam1zZUTs2uwj0AI08-2B-2BswRjb6ttBTKMigL-2FibRyuqTfbNhxfiQ5ECdH-2BY5YyFRCseY10e0vagSphAMd53pVrtvTJjzY9hDSJ4nWPnK6J9wKFK61ZeOOcTc-2BOkOSmgijGMwh-2FuBdeLKSUWgEiwGBS3sc-3D Build ID: 433935 Analysis Summary: New defects found: 6 Defects eliminated: 1 If you have difficulty understanding any defects, email us at scan-admin at coverity.com, or post your question to StackOverflow at https://u15810271.ct.sendgrid.net/ls/click?upn=CTPegkVN6peWFCMEieYYmPWIi1E4yUS9EoqKFcNAiqhRq8qmgeBE-2Bdt3uvFRAFXd-2FlwX83-2FVVdybfzIMOby0qA-3D-3DNCza_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je49edo4-2Fp9-2FGAMzgH5YifVG-2FMdE4gC-2FWLmKriDXRdyfPahjb6GU46tt87vqw-2BNs7oNSg5iEuo8srm9k21ixLafecftFXq8JFXxtsTeUGOS8vVolPgo-2FmQSh7qYNRvOTa69130GZE0RFS5j19tmNKRKN9QdINpSYJoAEC8VMkjZtWd7QdaGeOlSBP40HuNU9hrgo-3D