Limiting header & URI size

[Nils Goroll]

Hi,

I am referring to Paul-Henning's closing comment in
http://varnish-cache.org/ticket/701 :

> We already have a length check on the total request: half the workspace. That
> should probably become a parameter.

Currently, this is enforced by HTC_Rx checking the available space on the ws
with respect to the original reservation for half the workspace size made in
HTC_Init, so if we wanted to properly enforce limits at that point (including a
good HTTP response), we would either need to generate responses from within
HTC_Rx or do additional checks wherever HTC_Rx is called (in center, fetch and
all waiters), so I didn't find this option particularly attractive.

My main motivation to suggest these parameters in this particular way was that
someone had used statements like

	set req.http.someheader = req.http.someheader req.somethingelse

multiple times, which makes it hard to control workspace usage (consider
restarts, too). In particular, without any limitation of header/uri lengths
significantly lower than half the workspace, varnish will easily crash with
failed assertions on WS_Alloc() [because increasing the workspace doesn't help
much as long as it implicitly increases the limits too].

I thought it was a good idea to make these limits generic parameters because

- their existence might help raise awareness that those limits should be
  something to take note of,

- there are specific http response codes (413, 414) to be generated when those
  limits are exceeded so I thought a generic implementation would be preferable
  over (user written) VCL code,

- in the VCL, these generic checks should be the first thing to run in vcl_recv
  and vcl_fetch (because backend URI/, so they can't go into the default vcl and

- backends will (or at least should) enforce these limits anyway, so it might
  be possible to make some general recommendations on how to set them or use
  good default values later.

If there are good reasons why not to accept this suggested change, that's fine
for me, but I wanted to explain the reasons for my particular approach.

> I have moved this to the PostTwoShoppingList wiki page.
> (We only use tickets to track actual bugs, not feature requests).

I had thorught the best place for suggested patches was trac, so should I prefer
the mailing list?

Thank you, Nils