Willy,
Am 01.05.2018 um 06:28 schrieb Willy Tarreau:
>> It might make sense to enlarge the rewrite buffer reservation by
>> default.
>
> We used to have this a long time ago, the maxrewrite value used to
> default to half the buffer size. But it caused too many requests to
> be rejected and became absurd when users configure large buffers.
>
>> I can absolutely imagine that people put in a ton of
>> information in the times of Content-Security-Policy, Expect-{CT,Staple}
>> and whatnot.
>
> Yes but even once you put this, you hardly reach 1 kB. Most requests are
> way below 1 kB headers, at least for performance reasons.
Just to make sure that we are on the same page: My failure case is not
the requests, but rather the responses.
As another data point: GitHub adds a 812 Byte Content-Security-Policy
header to all their responses. In total they send more than 2kB of
response headers for a logged-out user:
> [timwolla@~]http --headers --follow github.com
> HTTP/1.1 200 OK
> Cache-Control: no-cache
> Content-Encoding: gzip
> Content-Security-Policy: default-src 'none'; base-uri 'self';
> block-all-mixed-content; connect-src 'self' uploads.github.com
> status.github.com collector.githubapp.com api.github.com
> www.google-analytics.com github-cloud.s3.amazonaws.com
> github-production-repository-file-5c1aeb.s3.amazonaws.com
> github-production-upload-manifest-file-7fdce7.s3.amazonaws.com
> github-production-user-asset-6210df.s3.amazonaws.com wss://live.github.com;
> font-src assets-cdn.github.com; form-action 'self' github.com
> gist.github.com; frame-ancestors 'none'; frame-src
> render.githubusercontent.com; img-src 'self' data: assets-cdn.github.com
> identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com
> *.githubusercontent.com; manifest-src 'self'; media-src 'none'; script-src
> assets-cdn.github.com; style-src 'unsafe-inline' assets-cdn.github.com
> Content-Type: text/html; charset=utf-8
> Date: Tue, 01 May 2018 15:01:16 GMT
> Expect-CT: max-age=2592000,
> report-uri="https://api.github.com/_private/browser/errors";
> Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
> Server: GitHub.com
> Set-Cookie: logged_in=no; domain=.github.com; path=/; expires=Sat, 01 May
> 2038 15:01:16 -0000; secure; HttpOnly
> Set-Cookie:
> _gh_sess=MnNIV1pEWFFXdUp5WkZCWFJDdzBRSlVXblRmTTlsVDlxaXhYWWgxMUVBVHpQYzRtNlg0aEtndTNIS29SNXA2bGFEekYydHYxaFFtd3p3TExyeW1YMG02S1YzTWMrclVxMnMzYnVJdmtIdG5pS3Y1RUtnY0xnVnpna0pITFRsZ3RxTjdQRVVjWVRjV3g3SnhvMkRyM20yVzdtVFNIRVdkYThBWkt3RitZT1QwQ0hsc2hMdXhSUEZhU0RiSlV5TUJ6dWg0UGg3cm1jOERzQldHYlFSNEtxUT09LS1EMmY5R1lidkI4V2FHWWFDaForQXN3PT0%3D--55a310a481cc921162ef33f26c91143493524be7;
> path=/; secure; HttpOnly
> Status: 200 OK
> Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
> Transfer-Encoding: chunked
> Vary: X-PJAX
> X-Content-Type-Options: nosniff
> X-Frame-Options: deny
> X-GitHub-Request-Id: C776:2053:B3DF8:14BA5E:5AE8813C
> X-Request-Id: 96a38711-e5c3-4c75-9df6-6282e43d429e
> X-Runtime: 0.046230
> X-Runtime-rack: 0.051859
> X-XSS-Protection: 1; mode=block
-
>> I don't know what issues a too-small buffer for non-rewrites would
>> cause.
>
> This limits the maximum size of accepted messages (request or response),
> which results in *some* requests to be rejected due to (for example) very
> large cookies. Overall, I'd say that the number of problem reports due to
> rejected requests or reponses due to their size has dropped to almost zero
> since we've limited the value to 1 kB. A long time ago it used to be a very
> common report.
>
>> Clearly the body must be able to span multiple buffers already,
>> otherwise I would not be able to send bodies greater than 16kB.
>> Will it need to allocate more buffers to do the same work, because every
>> single one is smaller?
>
> No, the body is simply streamed, not stored. If however you need to analyse
> it (eg for a WAF) then you need to configure a larger buffer so that more
> of the body can fit.
>
> To give you an idea about how things currently work, when we perform an
> recvfrom() call, we decide whether we read up to bufsize or up to
> (bufsize-maxrewrite) depending on whether we are forwarding data or
> still analysing the message. Thus when we receive a POST, we're not yet
> forwarding, so up to 15 kB of headers+body are placed into the buffer,
> leaving 1 kB available to add headers.
To make sure I understand that correctly (for the response case):
tune.bufsize:
Maximum size of response headers.
tune.bufsize - tune.maxrewrite:
Maximum supported size of backend generated response headers.
tune.maxrewrite:
Maximum size of response headers you are guaranteed to be able to add to
a response. You might or might not be able to add more depending on the
speed of the backend sending the body.
Is that correct?
> After the new native internal HTTP representation is implemented, I think
> that the need for the maxrewrite will disappear, at the expense of using
> one buffer for the headers and another one for the body, but we'll see.
Is this planned for 1.9? I'm aware that plans can change :-)
> Anyway we need to address the lack of error checking, and I really predict
> some breakage here :-/
>
I'd start of with *logging* when the call fails for the short term.
Users that see it failing can look into their logs to find out what
knobs to turn.
Best regards
Tim Düsterhus
