Uwsgi buffer increase (48K)

[fixpoint-hasan]

when default buffer size

default_buffer_size.mov

After buffer size increase

bufer_size_increase.mov

結合テスト:
https://github.com/fixpoint/kompira-v2-integration-test/pull/41

テスト結果：
https://fixpoint.github.io/kompira-v2-integration-test/147/index.html#suites/7ae9a7d01062ff0e0832aa27c1dd6c1a/fb1861b67e958a94/

[fixpoint-hasan]

メモ:
MAX_PATH_LENGTH=1024 なら request headerの1件 は最小 1 *24K必要でした。別の valueもあるの可能性があるため、2 *24Kを設定しました。

doc: https://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers

[fixpoint-hasan]

メモ:

1. uwsgi_busy_buffers_size must be less than the size of all uwsgi_buffers minus one buffer
2. uwsgi_busy_buffers_size must be equal to or greater than the maximum of the value of uwsgi_buffer_size and one of the uwsgi_buffers

doc: https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html

[fixpoint-hasan]

メモ:
response headerの1件 は最小 24K必要でした。

[fixpoint-hasan]

メモ:
response headerの1件 は最小 24K必要でしたので全ての size は 2*24Kとしておきました。

[tichi73]

MAX_PATH_LENGTH=1024 なら request headerの1件 は最小 1 *24K必要でした。

の部分がよくわかりませんでした。以下のレベルで説明できますか？

• パスの指定が長く（例えば日本語でNNN文字）なると、
• ヘッダ XXXX が MMM バイトになるため、
• バッファサイズとして 24k 必要になる

URI エンコード方式なども関係するのかな？とも予想していますが、どうでしょうか？

あと、他にももっとヘッダが長くなる可能性はありませんか？
たとえばオブジェクト検索するときの、検索テキストには現状長さ制限がないと思いますが、長い検索テキストを指定するとやはりヘッダサイズが長くなったりしませんか？（この場合は、検索テキストに長さ制限を設けたほうがよいかもしれませんよね）

[fixpoint-hasan]

If MAX_PATH_LENGTH=1024, then one request header required a minimum of 1 * 24K.

I didn't quite understand the part. Can you explain it at the following level?

• If the path is long (for example, NNN characters in Japanese),
• Since the header XXXX is MMM bytes,
• A buffer size of 24k is required.

The maximum size for a path is calculated as MAX_PATH_LENGTH * 9 (to account for Unicode characters when URL-encoded), which equals 9 KB.

If the query string uses the same path length (e.g., focus=path), the size will double to 2 * 9 KB = 18 KB. To accommodate the maximum path length with a query string and allow for additional parameters, we add 6 KB for safety, resulting in a total of 18 KB + 6 KB = 24 KB for the path and query.

Considering other factors like cookies, redirects, and Location headers, the total required size is approximately 2 * 24 KB = 48 KB.

[tichi73]

If the query string uses the same path length

検索テキストは「パス」だけでなく、文字列型フィールドの検索にも使うと思います。
そのような場面では検索テキストの長さはパスの長さに縛られず、もっと長い文字列を検索できますよね？
そのときに 24k でもバッファが足りなくなることもあるのではないですか？
検索テキストの最大長を規定するしかないのかな？と思っています。

Considering other factors like cookies, redirects, and Location headers, the total required size is approximately 2 * 24 KB = 48 KB.

この 48KB は1つのヘッダの最大長を示していますか？それともヘッダ全体の長さでしょうか？

[fixpoint-hasan]

If the query string uses the same path length

検索テキストは「パス」だけでなく、文字列型フィールドの検索にも使うと思います。 そのような場面では検索テキストの長さはパスの長さに縛られず、もっと長い文字列を検索できますよね？ そのときに 24k でもバッファが足りなくなることもあるのではないですか？ 検索テキストの最大長を規定するしかないのかな？と思っています。

Considering other factors like cookies, redirects, and Location headers, the total required size is approximately 2 * 24 KB = 48 KB.

この 48KB は1つのヘッダの最大長を示していますか？それともヘッダ全体の長さでしょうか？

maximum length of one header 24KB.

total length of headers 48KB

[fixpoint-hasan]

search string can be any, it is difficult to decide , I considered 9KB for actual path and 15KB for search query, in total 24KB.

if you think that is not enough we can consider 32KB for one header, what do you think? for rest of the headers 32KB

in total 2 * 32KB

[fixpoint-hasan]

Increasing header size limits unnecessarily can expose the application to risks such as b̶u̶f̶f̶e̶r̶ o̶v̶e̶r̶f̶l̶o̶w̶ a̶t̶t̶a̶c̶k̶s̶ or performance issues.