Weird behavior when return response without consume multipart

[momozahara]

Summary

I have encounter a weird behavior when I send a request with multipart using javascript on webbrowser and return 413 status code without consuming multipart consume-body-in-extractor-or-middleware on linux its return 413 as expect and fall into then(response) but on windows its throw an error net::ERR_CONNECTION_RESET and skip then and goes into catch(error) I can fix this by following the example that I mention before but when I upload a large file its do take some time before return response which I dont like it compared to when working with node express res.end() is there a way to work around for this problem? also I try send request via postman and its return 413 normally on windows.

axum version

0.7.2

[davidpdrsn]

I'm afraid I have no idea what could cause that.

[CmdrMoozy]

I also have this problem. I haven't yet found any solution, but perhaps some more details can help.

I have the same basic setup as the OP describes. An Axum router accepts multipart form data, file uploads. The idea is, if the file is too big I want to stop reading request data, and immediately reject it with an error. This is to protect against DoS type behavior from random clients sending me massive files.

I have a simple JavaScript (webpage) client which sends the uploads via XHR.

Both Firefox and Chrome, when this error happens, see this as a "connection reset". Firefox seems to do some weird thing where it actually tries resending the request several times, before eventually giving up with a "NS_ERROR_NET_RESET". Chrome seems to mostly just try the one time, but it too sees net::ERR_CONNECTION_RESET.

Curl, on the other hand, seems to behave exactly the way I would expect:

$ curl -v -X POST -F "[email protected]" localhost:3030/api/jobs/29fb2b5b-a04b-4537-a3d5-ced6ac89626d
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying [::1]:3030...
* connect to ::1 port 3030 failed: Connection refused
*   Trying 127.0.0.1:3030...
* Connected to localhost (127.0.0.1) port 3030
> POST /api/jobs/29fb2b5b-a04b-4537-a3d5-ced6ac89626d HTTP/1.1
> Host: localhost:3030
> User-Agent: curl/8.4.0
> Accept: */*
> Content-Length: 20971732
> Content-Type: multipart/form-data; boundary=------------------------Sn2oO9koYADY5uEoLAxXTL
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 400 Bad Request
< content-type: text/plain; charset=utf-8
< content-length: 46
< date: Wed, 10 Jan 2024 06:01:21 GMT
* HTTP error before end of send, stop sending
<
* Closing connection
file upload too large, limit is 10485760 bytes

My gut feeling is simply that browsers don't consider "HTTP error before end of send" a valid thing to do, unlike curl. So they treat this as a connection reset, or retry, or other weird things.

It's not clear to me there is any way to fix this other than to have the server actually continue reading (and I guess throwing away?) the form data bytes until the client stops sending, and then send it an error. This is dumb, of course, because it means there's no way to "gracefully" (i.e., with an HTTP status code and a helpful error message or whatever) "hang up on" a misbehaving client... In order to do so the server has to sit there streaming bytes until the client decides to be done?

Then again, perhaps there is some easy solution I haven't yet discovered. I'm mostly speculating at this point. :)

[CmdrMoozy]

For what it's worth, I confirmed if I changed the server to always iterate over all multipart fields, and all chunks within those fields, even if it does nothing with them, and then returns the error, things behave as I expect. But of course this isn't a great solution, as I described here (a misbehaving client could "tie up" the server with useless work).

[fs-99]

I'm writing up a repro about this. Honestly if this is a HTTP/browser problem, it's pretty weird, because then nobody would ever reply with "FileTooLarge", as the server would have to buffer the whole, too large body including the file and only then reply, vs. aborting the send.

[CmdrMoozy]

Well, technically you don't have to buffer the whole large file, you can just read the bytes off the connection in chunks and discard them.

For what it's worth, this answer: https://stackoverflow.com/questions/14250991/is-it-acceptable-for-a-server-to-send-a-http-response-before-the-entire-request/14483857#14483857 states that responding before reading the whole request is allowed by the HTTP spec, but in practice browsers don't actually support this.

[fs-99]

@CmdrMoozy thank you, that answer is pretty valuable. Then the question is how to do this in axum / why doesn't axum do this when validating Request/Body length?

Here's the issue+repro: #2850 😄