From scan-admin at coverity.com Sun Dec 6 12:02:00 2020 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Sun, 06 Dec 2020 12:02:00 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <5fccc8383a3d2_22a9f52af266728f5c144c4@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-3DZ15Z_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je4-2Fl3O77szL2gfVj-2BBAMKmmJa2SLJJPVbpThsdYjW8FSLzUAuwHTg2VGeA8iXXdmIw9EmUjnZXbFRA7mqJwawZCWPCGDQ6hCXOxlaGZQVkVJ-2FFv4JEE5WmCA9FOGXbw-2Fx-2BxmXDtOs-2FKn23nAXy0yJq7G3lPSbZTyB63ak8MwjnAMtF2sSAHA2hmKNL-2Bp3svXwTM-3D Build ID: 356275 Analysis Summary: New defects found: 0 Defects eliminated: 0 From phk at phk.freebsd.dk Tue Dec 8 10:11:23 2020 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 08 Dec 2020 10:11:23 +0000 Subject: allocating backend attributes to layers Message-ID: <29861.1607422283@critter.freebsd.dk> I'm working on the "backend-clone" thing for dynamic directors and I have run into something I could surprisningly not answer: Which backend attributes lives at which levels ? So roughly speaking our backend stack looks like this: Director | +-----> [CGI] | v Backend probe, hosthdr | +-----> [Http2, QUIC] | v Http1 | v | Endpoint | +---------+ | | | proxyhdr prefix, proxy_header v | +<--------+ | +------> TCP ipv4, ipv6, port | +------> UDS path | +------> [TLS] ipv4, ipv6, port, [clientcert, pubkey] I have added the obvious extension-points in [....] I have allocated the some of the backend attributes in the right column. But now I need help: proxy_header ------------ Can one send a PROXY header over a TLS connection ? If not, it needs to go to the TCP and UDS levels {connect|first_byte|between_bytes}_timeout ------------------------------------------ I dont think these would apply to [CGI], they would have their own separate timeouts. I lean that they belong at the Backend level, but does that make sense ? What would first_byte and between_bytes refer to in H2 or QUIC context ? Payload bytes or overhead bytes ? Same question for TLS ? max_connections --------------- Does it go to the Backend level or the Endpoint level ? Endpoints pool and serve multiple backends, so if we put it in at the Backend level, you have to summ all the backends limits to get the limit at the Endpoint level. Maybe we need to be able to set limits both at the Backend and Endpoint levels ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From slink at schokola.de Tue Dec 8 15:51:07 2020 From: slink at schokola.de (Nils Goroll) Date: Tue, 8 Dec 2020 16:51:07 +0100 Subject: allocating backend attributes to layers In-Reply-To: <29861.1607422283@critter.freebsd.dk> References: <29861.1607422283@critter.freebsd.dk> Message-ID: <92b811b3-2854-266c-35ff-b1de03f74c40@schokola.de> Hi, my 2?: On 08/12/2020 11:11, Poul-Henning Kamp wrote: > proxy_header > ------------ > > Can one send a PROXY header over a TLS connection ? Yes. With a hypothetical TLS backend (or tls onload with a preamble), we would still want to be able to send (a second) PROXY header if the backend has the proxy_header attribute. This implies that we might use the same format (PROXY) for different purposes ("connect-to" vs. "client socket" info). > {connect|first_byte|between_bytes}_timeout > ------------------------------------------ > > I dont think these would apply to [CGI], they would have > their own separate timeouts. > > I lean that they belong at the Backend level, but does that make sense ? > > What would first_byte and between_bytes refer to in H2 or QUIC > context ? Payload bytes or overhead bytes ? > > Same question for TLS ? I think your leaning makes sense. While we might need additional timeouts for specific protocols, I think the existing timeouts are so generic that they should have sensible translations to the payload of any protocol. IMHO, including CGI, so I would tend to see CGI hat the same level as [Http2, QUIC]. But at any rate having it only at the director level would not be a show stopper. > max_connections > --------------- > > Does it go to the Backend level or the Endpoint level ? Either backend or both. - it is vital to be able to set limits on something "virtual" like a vhost or application by defining a backend with a max_connection limits. - adding limits at the endpoint level could make sense, but we would also need to consider sharing of endpoints across vcls Off topoc, yet related: - For use with routing directors, we could make good use of some kind of "reservation ticket" such that a routing director can make it more likely to get a connection once the fetch starts. - When we added the connection stats, we put them at the backend level as, at the time, we did not want to introduce another user-visible layer. Should we change that, we should also move the connection stats to the endpoint layer. Nils From phk at phk.freebsd.dk Wed Dec 9 10:13:09 2020 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 09 Dec 2020 10:13:09 +0000 Subject: allocating backend attributes to layers In-Reply-To: <92b811b3-2854-266c-35ff-b1de03f74c40@schokola.de> References: <29861.1607422283@critter.freebsd.dk> <92b811b3-2854-266c-35ff-b1de03f74c40@schokola.de> Message-ID: <46312.1607508789@critter.freebsd.dk> -------- Nils Goroll writes: > - For use with routing directors, we could make good use of some kind of > "reservation ticket" such that a routing director can make it more likely > to get a connection once the fetch starts. And what happens when VCL takes an entirely different path, how does the reservation gets released ? vmod_priv ? > - When we added the connection stats, we put them at the backend level as, at > the time, we did not want to introduce another user-visible layer. Should we > change that, we should also move the connection stats to the endpoint layer. 'move' or 'also implement' ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From slink at schokola.de Fri Dec 11 14:36:37 2020 From: slink at schokola.de (Nils Goroll) Date: Fri, 11 Dec 2020 15:36:37 +0100 Subject: allocating backend attributes to layers In-Reply-To: <46312.1607508789@critter.freebsd.dk> References: <29861.1607422283@critter.freebsd.dk> <92b811b3-2854-266c-35ff-b1de03f74c40@schokola.de> <46312.1607508789@critter.freebsd.dk> Message-ID: On 09/12/2020 11:13, Poul-Henning Kamp wrote: >> - For use with routing directors, we could make good use of some kind of >> "reservation ticket" such that a routing director can make it more likely >> to get a connection once the fetch starts. > And what happens when VCL takes an entirely different path, how does the > reservation gets released ? vmod_priv ? > Something like that maybe, I have not looked into the details. >> - When we added the connection stats, we put them at the backend level as, at >> the time, we did not want to introduce another user-visible layer. Should we >> change that, we should also move the connection stats to the endpoint layer. > 'move' or 'also implement' ? I think the implementation should be consistent with the user view, so yes, both. -------------- next part -------------- An HTML attachment was scrubbed... URL: