Pål Hermunn Johansen
Pål Hermunn Johansen
beresp 304 header merging makes impossible to distinguish between headers set by varnish and backend
> * What happens if it doesn't get called? We have to choose if the default behavior is to remain in the core or be moved to the builtin VCL....
beresp 304 header merging makes impossible to distinguish between headers set by varnish and backend
> ```varnish-vcl > set beresp.http.new_xkey = beresp.http.xkey; > ``` Well, a `std.collect` is in order here, and this illustrates a maybe sore point in all of this - Varnish does...
> @hermunn where is this (very surprising, in my mind) requirement to preserve header ordering coming from? I am not aware of anything like this in anything I ever read....
If you also set the `vsl_buffer` to 4k in the same test case, then this test should pass. We need to fail much earlier if the workspace is smaller than...
I resolving this before the freeze (mid Febuary?) on the table? I think it is time to change the behavior here and merge it in good time before the March...
The problem with this PR is that it does not do what the title says. In the event of a waiting list, and there is a queue of clients waiting...
> This is waiting list serialization once again Yeah, you are right, my comment does not add much, and I think we should simply go with the PR as it...
Sorry, strike that, I still think we need a test case demonstrating how you can get a hit, even when the request set both `req.ttl` and `req.grace` to `0s` because...
I would prefer to have a separate VMOD for `math.h` functions, maybe called VMOD `math`. Starting off with a few functions makes sense to me, for example, ``` math.pow(a, b)...
@fwsGonzo and me discussed this a while ago, and we agreed that maybe an open source VMOD `math` is the answer, and that we can consider moving it to Varnish...