I agree with the gist of this, except that "414 URI Too Long" doesn't sound right, unless it was just the URI that lead to the overflow (which would really be something).

"413 Payload Too Large" appears to be the right response for this:
https://tools.ietf.org/html/rfc7231#section-6.5.11

BTW @sgran +1 for the avatar.

Hi,

Yeah, I am seeing this for the request URI (which is amazing), but it's because the query params are being programmatically generated from other request/reply events - our clients need to learn how to ask for pages instead of all things all at once.

I can see that differentiating between URI and other headers in the return code might be a good thing, so perhaps they do want different responses.

We talked about some possible approaches at bugwash today, but @bsdphk was not around and we want to get his input.

A point that was mentioned is that closing the connection causes the least amount of processing for abusive clients -- avoids Varnish getting DOSsed by a flood of oversized requests.

But that doesn't mean that we aren't open to different solutions (just not ready to decide today).

I quite understand. I got the impression from reading over the structure of things that this is on purpose, and it makes sense in many settings.

I guess I'm hoping for a way to override the default behaviour with either a config switch or in VCL.

Originally we decided to just close on abusive input, to improve DoS resistance.

That still sounds sensible to me, but if there is a need for more civilized behaviour, we could make a feature to control it (default open to discussion)

We bugwashed it, and my previous comment stands.

If we want to modulate behaviour, it has to be a featureflag, we cannot ask VCL since we cannot represent the request for inspection.

I have varnish behind nginx.
If nginx uses existing keep-alive connection to varnish then it will treat closing that connection as keep-alive problem (as described in https://trac.nginx.org/nginx/ticket/2022 ) and retry it. I had ~100k retries of one request

I will find someone to work on this.

I had ~100k retries of one request

We have a max_retries parameter in varnishd, there should be an equivalent in nginx.

edit: quick search yields proxy_next_upstream_tries

in nginx I have proxy_next_upstream_tries set to 2, but in this comment it's explained that nginx may omit counting attempts that used keep-alive connection and were brutally closed

I tightened uri length limit in nginx and avoid RX_OVERFLOW, but others can encounter it too