You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: