Reporting the original error code to the client even when the request is aborted
- Dominant language
- C#
- Stars
- 9.6k
- Forks
- 933
- Avg merge
- 12d 18h
- Merged PRs (30d)
- 2
Description
### Describe the bug
App coded to reject large POSTs with 400 BAD Request. (App also sends a FIN soon after).
Client using POSTMAN uploads a large file (larger than the value coded.)
There are two proxies chained here.
What is happening today:
• App returns error 400 almost immediately with a FIN
• Front Proxy is still reading payload from the client.
• Back Proxy turns around and sends TCP RESET to the Frontend.
• Front end on receiving the RESET sends back a 502 to the client.
Customer expectation:
The client receives the HTTP status returned by the APP
When using nginx instead for the second proxy, resets are delayed by ~30s so the response makes it through.
Current:

Desired:

Note the default behavior will vary depending on if the 400 has a response body with it. That is more likely to cause the original response status to be flushed to the client before any upload errors are noticed. The scenario tested above did not include a response body.
Contributor guide
Assessment
This issue has not been assessed yet.