Nils Goroll comments

Results 592 comments of


                                            Nils Goroll

cache_req_fsm: keep the cache object's Content-Length for HEAD always

I the following, I refer to a response which, by definition, does not have an HTTP body ([CONNECT or HEAD request and any response with a 1xx (Informational), 204 (No...

cache_req_fsm: keep the cache object's Content-Length for HEAD always

Re @dridi > > Also, trying to find a way to give VCL control over `Content-Length` gets messy soon because of streaming... > > We specifically made content-length and transfer-encoding...

cache_req_fsm: keep the cache object's Content-Length for HEAD always

While @dridi and me should find concensus, I think this PR could be merged. The question how to avoid sending `Content-Length` is I think separate enough.

cache_req_fsm: keep the cache object's Content-Length for HEAD always

The vtc I had added was doing all kinds of things, but not actually test for the `Content-Length`. Sorry for that. Fixed now in force-push

cache_req_fsm: keep the cache object's Content-Length for HEAD always

bugwash: the "delete C-L" option should exist Would be good to finish the discussion with @dridi

cache_req_fsm: keep the cache object's Content-Length for HEAD always

@dridi ?

cache_req_fsm: keep the cache object's Content-Length for HEAD always

OKed by bugwash

Bad chunked encoding should cause 400 error, not 503

bugwash agrees.

varnishd command line syntax for pluggable acceptors?

bugwash: phk is for not adding `-a` processing for VEXTs. He suggests a `varnish.cf` file which would allow for per-extension acceptors (which I appreciate!) and we would probably also need...

varnishd command line syntax for pluggable acceptors?

I've settled on suggesting ``` [name=][%,][listen_address[,PROTO|,option=value,...]] ``` now. Reasons: * `%` is never the first character of a valid hostname for _listen_address_ * `%` is highly unlikely as the first...