dave2wave commented on issue #776:
URL:
https://github.com/apache/tooling-trusted-releases/issues/776#issuecomment-4063497893
I asked ChatGPT and received the following advice:
Yep — with Quart forms plus `flash`, there are **two different size traps**
that tend to get mixed together:
1. **Request/form parsing limits**
2. **Session cookie size limits from `flash()`**
If you have a big `<textarea>`, both can bite you.
## 1) Big textarea post body: raise the request/form limits
Quart limits request body size with `MAX_CONTENT_LENGTH`. Its docs note the
default is **16 MB**, and requests larger than that can trigger **413 Request
Entity Too Large**. ([GitHub][1])
If your form is `multipart/form-data`, modern Flask/Werkzeug also
distinguish:
* **MAX_FORM_MEMORY_SIZE**: max size of any non-file field in multipart form
data, default **500,000 bytes**
* **MAX_FORM_PARTS**: max number of multipart fields, default **1,000**
([Flask Documentation][2])
Quart sits in the same Werkzeug request-parsing world, so these are the
knobs to think about when a textarea gets large.
Typical app config:
```python
app.config.update(
MAX_CONTENT_LENGTH=8 * 1024 * 1024, # 8 MiB total request body
MAX_FORM_MEMORY_SIZE=2 * 1024 * 1024, # 2 MiB per non-file multipart
field
MAX_FORM_PARTS=2000,
)
```
### Important gotcha
If your form is a normal POST without file upload, prefer:
```html
<form method="post" enctype="application/x-www-form-urlencoded">
```
or just omit `enctype` entirely.
That avoids multipart parsing entirely for a plain textarea. A lot of “large
textarea” pain happens because the form was switched to `multipart/form-data`
unnecessarily.
## 2) `flash()` can blow up the session cookie
This one is sneakier.
Flask-style sessions are cookie-based, and cookie size is effectively around
**4 KB**; Flask documents `MAX_COOKIE_SIZE` warning defaulting to **4093
bytes**. ([Flask Documentation][2])
So if you do something like:
```python
flash(large_textarea_value)
```
or flash a giant validation error containing the whole submitted text, you
can break things even if the POST itself was accepted.
### Rule of thumb
Use `flash()` only for **small status messages**:
```python
flash("Draft saved.", "success")
flash("Description is too long.", "error")
```
Do **not** flash:
* the textarea contents
* giant error details
* serialized form state
* traceback-ish blobs
## Best practice for large text fields
For a big textarea, the safe pattern is:
* increase `MAX_CONTENT_LENGTH` enough for your real use case
* avoid `multipart/form-data` unless uploading files
* keep `flash()` messages tiny
* persist large text server-side, not in session
Example:
```python
app.config["MAX_CONTENT_LENGTH"] = 8 * 1024 * 1024
@app.post("/submit")
async def submit():
form = await request.form
body = form.get("body", "")
if len(body) > 500_000:
flash("Body is too large.", "error")
return redirect(url_for("edit"))
# Save body to DB / file / server-side store
save_text(body)
flash("Content saved.", "success")
return redirect(url_for("edit"))
```
## If you are seeing weird symptoms, they often map like this
* **413 Request Entity Too Large**
usually `MAX_CONTENT_LENGTH`, or multipart field limits
* **Flash message disappears / redirect behaves oddly / session issues /
cookie warnings**
usually oversized session cookie from `flash()` or other session data
* **Only fails when file upload is present**
likely `multipart/form-data` parsing limits
My hot take: for **really large text blobs**, HTML forms still work, but
it’s often cleaner to POST JSON to an endpoint or save drafts incrementally,
especially if users may paste multi-hundred-KB content.
If you want, I can show a **minimal Quart patch** for:
* bigger textarea support,
* safe flashing,
* and a custom `413` handler.
[1]:
https://github.com/pallets/quart/blob/main/docs/discussion/dos_mitigations.rst?utm_source=chatgpt.com
"quart/docs/discussion/dos_mitigations.rst at main · pallets/quart - GitHub"
[2]:
https://flask.palletsprojects.com/en/stable/config/?utm_source=chatgpt.com
"Configuration Handling — Flask Documentation (3.1.x)"
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
