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 _______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev