From scan-admin at coverity.com Sun May 2 12:12:42 2021 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 02 May 2021 12:12:42 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <608e973a71c1_32f8e2ad54c2ff9a8357d4@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-3DOnrk_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je4-2BMJw987DbZyBrV4EYRqyBni46heNuTw1oDVQOPlzUeLVKtD48giHPT8QWrieWhk75ERGAH2WWTQlQKNy6nWWHvRdX1UHtx8Zir8CoI-2FM175ZgAKuxLen7EJ8pdnntDDRO1IQk4QpDDgsraGmWQFEvgESiWwK3uWEvzYl1clFF2kMOjhTE7aLpKU5w0xLrCEC4-3D Build ID: 384351 Analysis Summary: New defects found: 0 Defects eliminated: 0 From scan-admin at coverity.com Sun May 9 12:12:58 2021 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 09 May 2021 12:12:58 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <6097d1c9b3578_ffb792afe93d39994133e7@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-3DH5_3_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je48CUV7L-2BuOqDLlhuJCBXcmhEgTpMq8FGuLMnGIsp2sSsSQziao8zU8rpZMl-2FLj7G0mkIFzatieZgcWhcrRXt8k1zuzhLwReT33dgAI114m-2FAOgd0BtlwR1cYZ3kJuzwXPXVUwHL48Gn6t67vcYTRg8vjy6QWWYVILJDO9PrmbutwJ7L4HdK4nWm2fkKwiPxMYM-3D Build ID: 385642 Analysis Summary: New defects found: 1 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-3DkSZc_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je48CUV7L-2BuOqDLlhuJCBXcmhEgTpMq8FGuLMnGIsp2sSsUYOEAEQF4xqMQOn5cvYUEbFrmYf-2Bgomnt2dPZwMtT9qAoCWAcZnSVIgJ9Mj0eHHr1jyDfBB1fRK7kAPPhJ5TpDU236pzUxGfGb7p1AEJJdYuqbFEnfEBuRyPgMAZdZHpXFQZhp9qv1uRGJ9Sgp2KuE-3D From scan-admin at coverity.com Sun May 16 12:13:37 2021 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 16 May 2021 12:13:37 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <60a10c707db7d_815a82b0052c539b0263be@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-3DgRdV_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je48Kv6PVdryrXvbsDN6faTeiJuUJWZ6JcA5T4mzF-2BjLhzSrT-2BNvEbbTlc3fntGCY0q1Mxmk-2F2KVjjNNuOpvHw2VCkfJJsn6HYzT1Zv0dCJuw5fsWpCNDgHQIpEfgBCHLfxT8iPMDZhlxVJ0muBFhTwQ9l0kZfuTBskiwT6XKusoi-2BrDZHIxdBheM1AL3iX41-2BOc-3D Build ID: 386812 Analysis Summary: New defects found: 0 Defects eliminated: 1 From scan-admin at coverity.com Sun May 23 12:13:44 2021 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 23 May 2021 12:13:44 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <60aa46f83b787_14bd782ae2c0d3d9988129f@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-3DgXQQ_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je48-2F2Cr7RKQ28XIWW81icBQOjV98NZaeMJ7pMDyi9w8ejpH7V5YBHzl8uORJpoNXwylXaXgS8i1gft-2F7VxgYyRhBZLsbg8Q3Bxz1WxO5ZxpqtFajzYfJaONxxiwo-2BfnEs-2BX8gBWNkU23Q4OgzYJSAA7QsX-2BsTIlgicL1zXD5AcyFDdXahCKW6phXzoPXxhV-2FudQ-3D Build ID: 387959 Analysis Summary: New defects found: 1 Defects eliminated: 0 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-3DceZI_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je48-2F2Cr7RKQ28XIWW81icBQOjV98NZaeMJ7pMDyi9w8ejuObUsaBZOebVp1cybyLKyylHI1vnXb96yvuRjTkh89RC-2B8OUGcXN07i4H8McYhoNwwEEHI650y85R2wm86SNtlXpx8n9bX1cqhfaGAnYO1A-2FneW-2BLOVpEPcm5iuv-2BKCF8gVyTI5QxibnhdZ-2Bbd1t7Y-3D From dridi at varni.sh Fri May 28 15:50:52 2021 From: dridi at varni.sh (Dridi Boukelmoune) Date: Fri, 28 May 2021 15:50:52 +0000 Subject: Reintroduce a req.uncacheable flag Message-ID: Greetings, I would like to reopen a discussion started by Guillaume via a pull request: https://github.com/varnishcache/varnish-cache/pull/3457 For reasons other than the ones he exposed I have reached the conclusion that such a flag would be both relevant and useful. Not req.hash_always_pass as originally suggested but req.uncacheable (and to Guillaume's credit he did make the suggestion first in the pull request description). I didn't take part in the pull request discussion and don't remember if I took a position but chances are I would have opposed a flag called hash_always_pass. On the other hand, here are the reasons why I think req.uncacheable would make sense. First, we already have a relationship between bereq.uncacheable and bereq.uncacheable: the former implies the latter. I believe the same relationship could exist between req and bereq. Second, since the VCL built-in split it makes even more sense to get the ability to mark a request as uncacheable. If you wish to keep your code organized as per the split, but don't want an early return to prevent a later step to be taken, then a flag instead of a return(pass) lets the flow of execution continue and guarantees that a lookup attempt would result in a pass transition. As we are heading towards a dot-zero release, we could even break the built-in VCL to replace pass transitions with req flagging. That would be a breaking change in the sense that we would no longer break the flow of execution, but in practice that does not change the outcome of existing VCL not taking advantage of the split (for example upgrading from 6.0 LTS) and for VCL authors who already adopted the split, I assume they'd be savvy enough to check their code. Third, one more reason to bring it back as req.uncacheable instead of hash_always_pass is consistency across the board. I'm not diving into implementation details on purpose, my goal with this thread is to discuss the possibility to reintroduce a new iteration on #3457 and shine a new light on it from the perspective of the recent split and the additional opportunity it grants us. Cheers, Dridi From geoff at uplex.de Fri May 28 17:22:42 2021 From: geoff at uplex.de (Geoff Simmons) Date: Fri, 28 May 2021 19:22:42 +0200 Subject: Reintroduce a req.uncacheable flag In-Reply-To: References: Message-ID: <77c07175-4e8c-c3f4-62db-ce9f2730be0d@uplex.de> On 5/28/21 17:50, Dridi Boukelmoune wrote: > > First, we already have a relationship between bereq.uncacheable and > bereq.uncacheable: the former implies the latter. Presumably you meant to write that bereq.uncacheable implies beresp.uncacheable. My quick and superficial first reaction to the proposal -- I don't quite have my head around what you would write in VCL if you do in fact want to return early out of vcl_recv, and you want to say that the response will be uncacheable. You could set req.uncacheable to true, and also say return(pass), but it feels like saying the same thing twice. VCL could also have one but not the other: req.uncacheable=false and return(pass), or req.uncacheable=true and return(lookup). Which one determines whether a cache lookup is attempted or bypassed? The combination req.uncacheable=true and return(lookup) in particular feels like a contradiction. But if the point-oh release eliminates return(pass) as you considered, isn't return(lookup) the only way to return early out of vcl_recv, unless you're going to something like pipe or synth or fail? If so, then is req.uncacheable=true, suggesting no lookup, and then return(lookup) the only way to accomplish what return(pass) does now? I guess this is starting to sound like I'm critical of the idea, which I didn't intend, because there may be good answers to all of these questions. Just trying to get it sorted in my head. Best, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From dridi at varni.sh Fri May 28 20:41:46 2021 From: dridi at varni.sh (Dridi Boukelmoune) Date: Fri, 28 May 2021 20:41:46 +0000 Subject: Reintroduce a req.uncacheable flag In-Reply-To: <77c07175-4e8c-c3f4-62db-ce9f2730be0d@uplex.de> References: <77c07175-4e8c-c3f4-62db-ce9f2730be0d@uplex.de> Message-ID: Hi Geoff, It's been a while, I hope you are doing well :) On Fri, May 28, 2021 at 5:22 PM Geoff Simmons wrote: > > On 5/28/21 17:50, Dridi Boukelmoune wrote: > > > > First, we already have a relationship between bereq.uncacheable and > > bereq.uncacheable: the former implies the latter. > > Presumably you meant to write that bereq.uncacheable implies > beresp.uncacheable. Correct, a tragic copy-pasta accident and yet I managed to make a silly but valid statement anyway \o/ > My quick and superficial first reaction to the proposal -- I don't quite > have my head around what you would write in VCL if you do in fact want > to return early out of vcl_recv, and you want to say that the response > will be uncacheable. > > You could set req.uncacheable to true, and also say return(pass), but it > feels like saying the same thing twice. > > VCL could also have one but not the other: req.uncacheable=false and > return(pass), or req.uncacheable=true and return(lookup). Which one > determines whether a cache lookup is attempted or bypassed? I didn't want to jump too soon into implementation details but I have to dip a toe now :) Let's ignore bereq.uncacheable since it's read-only and determined strictly by what happened on the client side. You can decide to make a beresp uncacheable but you can't undo it. My assumption is that we would want the same for req.uncacheable where assigning true takes effect and false does nothing. > The combination req.uncacheable=true and return(lookup) in particular > feels like a contradiction. But if the point-oh release eliminates > return(pass) as you considered, isn't return(lookup) the only way to > return early out of vcl_recv, unless you're going to something like pipe > or synth or fail? If so, then is req.uncacheable=true, suggesting no > lookup, and then return(lookup) the only way to accomplish what > return(pass) does now? Consider the backend transitions today: - return(deliver) - return(pass[...]) You have an explicit transition and a general one that will be influenced by beresp.uncacheable. On the client side that would be the same: - return(hash) => influenced by req.uncacheable - return(pass) > I guess this is starting to sound like I'm critical of the idea, which I > didn't intend, because there may be good answers to all of these > questions. Just trying to get it sorted in my head. Well, critical doesn't imply against, and your reply shows that my first message was lacking a bit of context. I'm not suggesting to remove the pass transition on the client side, but to add a flag to signal that a lookup attempt should be neutered. I am however suggesting that the built-in VCL replaces return(pass) transitions with raising the req.uncacheable flag. This would for example allow you to keep your cookie handling in vcl_req_cookie even if your POST request was made uncacheable earlier. Next implementation details, req.uncacheable would be read-write in vcl_recv and vcl_hash, and read-only everywhere else. If you return(pass) from vcl_recv, you can expect req.uncaheable to be true in vcl_pass, vcl_deliver and vcl_synth. The req.uncacheable flag would be reset to false after a return(restart). I hope this clarifies things a bit. Cheers, Dridi From scan-admin at coverity.com Sun May 30 12:14:11 2021 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 30 May 2021 12:14:11 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <60b3819320c60_54eb82abe6a3c799c159ac@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-3D1x7q_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je48tflUehmIPyFfpE4T5rgOlhBIeG-2B0xX1TgBhkebU45OZ9lz1PYAfeQPgPORE1mabRiOn3463dJ7EL0fws8FErJVWus6q7yfYa4PqzBCqT-2Fs-2Bsxcj3FRM7mObJzYeB8UQq-2Bi442tdxeDC3LAAPr4o-2FqveAsXQ9EmfBNbxScvsP6IbFHHzVotDgMQqqjqNiy8NQ-3D Build ID: 389144 Analysis Summary: New defects found: 1 Defects eliminated: 0 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-3DzY6X_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je48tflUehmIPyFfpE4T5rgOlhBIeG-2B0xX1TgBhkebU45Ocm9iUDqwobZlonji0LRzw-2FmjHs9IdtgLqHFwoWeQ-2B2CnDyLbLrPdsrlpyaI2K39nwyy5TgsWrSuaHcyFNlTzuUKcbGidttwjT6CiqlPDaD47jSO4aDfZN4caJOFw8YbaRh68fNA3SNU1fE0ffeS8eg-3D