Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need to handle "Payload too large" errors reasonably #1

Open
jennifer-richards opened this issue Jun 19, 2024 · 0 comments
Open

Need to handle "Payload too large" errors reasonably #1

jennifer-richards opened this issue Jun 19, 2024 · 0 comments
Assignees
Labels
bug Something isn't working

Comments

@jennifer-richards
Copy link
Member

If a message is large enough that the API request is refused with a 400 or 413 error (gunicorn seems to do the former, nginx the latter), this is not handled well. The LMTP response falls to the generic 451, which causes retransmission later even though it's doomed to fail.

In testing, I see:

app-1  | ERROR:emposter:Error processing message from jennifer@birb to ipr-response: <urlopen error [Errno 32] Broken pipe>

and similar occurs on production, though the reason is HTTP Error 400: Bad Request. (I suspect the difference is due to CloudFlare accepting the large request and returning a clean 400 to emposter, vs gunicorn simply closing the socket in a way that urlopen doesn't deal with)

We should handle this error properly. It should be a permanent error - if we can convince gunicorn / Django to return a 413 instead of a 400, we can just handle that specially. In addition or alternatively, we should probably add a size limit to emposter above which it won't even attempt API delivery.

@jennifer-richards jennifer-richards added the bug Something isn't working label Jun 19, 2024
@jennifer-richards jennifer-richards self-assigned this Jun 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant