Nils Goroll

Suggestion for `100-continue` handling from pow-wow: * remove `std.late_100_continue()` * revisit 100-handling code from C-Code * make 100-handling explicit in VCL, such that it can be changed/removed builtin.vcl mockup: ```...

I think @Dridi 's suggestion makes sense. The only drawback I can see is lack of symmetry due to `vcl_backend_begin` and `vcl_tunnel_begin` missing.

yes, that was not meant as an argument against your suggestion.

> We should only attempt to read the next chunked header if we have read-ahead bytes. This is implemented with the last force-push as of 24b97764bdffb41c37cfe11918214a12c9f790b2. Regarding the possible reduction...

I have updated this PR with a readahead implementation for chunked encoding. First things first, for [s00003.vtc](https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishtest/tests/s00003.vtc), this brings down the number of `read()` calls from `v1f_read()` from 76 in...

Note on the last force-push 3573c3349f964f30a508c1baf89abd5e86526355: While working on #3798 together with this PR, I noticed that we can not put the V1F chunked state on any workspace. See commit...

> While this looks overall correct, it also complicates chunked parsing a great deal. I doubt a generic receive buffer, while useful, would change this in any relevant way. We...

> I'm still thinking we may be taking this problem from the wrong end. The last couple commits in particular drastically increase in complexity despite attempts at containing it. I...

Bugwash: * can trailer handling be extracted from VFP in any sane way? * Show how trailer support in VCL could look like, ideas: * explicit body fetch? * vcl_backend_end...

TODO from bugwash: review existing vmods and compile a wishlist of interfaces for addition to VRT from Dridi: HTTP_* functions maybe?