Nils Goroll
Nils Goroll
beresp 304 header merging makes impossible to distinguish between headers set by varnish and backend
bugwash: @Dridi and myself agree that `sub vcl_backend_refresh` preferred
beresp 304 header merging makes impossible to distinguish between headers set by varnish and backend
Discussed with @Dridi and @bsdphk * We agree that a new `sub vcl_backend_refresh` is the best option * return values: ok/retry/abandon/fail * The 304 handling should move to vcl, by...
beresp 304 header merging makes impossible to distinguish between headers set by varnish and backend
FYI, working on the promised VCL mockup proposal made me realize that not even [the current master version of the cache rfc](https://github.com/httpwg/http-core/blob/master/draft-ietf-httpbis-cache-latest.html) can possibly work: > For each stored response...
beresp 304 header merging makes impossible to distinguish between headers set by varnish and backend
TODO also: consider https://cache-tests.fyi/#conditional when writing the VIP
Though not directly related, I would also like to point out [`std.late_100_continue()`](https://varnish-cache.org/docs/trunk/reference/vmod_std.html#std-late-100-continue) which controls when we motivate the client to send the request body.
powwow: @nigoroll to propose an implementation without the timeout
FTR, /me feels bad about not having got to this todo item
rebased onto master here https://github.com/nigoroll/varnish-cache/tree/transit_buffering for the rebase I renamed all test cases by incrementing the test case number by one now working on the proposed change
`tests/c00110.vtc` (formally `tests/c0009.vtc`) is not reliable on the rebased but otherwise onmodified a2ca25fc658afe0d6d69d010ff5bfb0b647887a0 ``` $ ./varnishtest -in 1000 -j50 tests/c00110.vtc ... ---- v1 Not true: VBE.vcl1.s1.conn (1) == 0 (0)...