Reading larger POST data with enabled tls fails
jcorporation opened this issue · comments
- My goal is: Read post requests from a https socket issued by javascript
- My actions were: read the data in
MG_EV_HTTP_MSGwithstruct mg_http_message *hm = (struct mg_http_message *) ev_data;as used in your examples - My expectation was: mongoose reads the complete post data
- The result I saw:
Mongoose does not read the complete post data from the socket. I checked with wireshark and the browser sends the complete message.
The problem occurs only with enabled ssl (openssl in my case)
The issue is reproduceable with your http-restful-server example. Attached are the mongoose logfile with hexdumping enabled, the tcpdump and the keylog file. Code is the same as in #2603 but only with a larger body.
Environment
- mongoose version: latest master
- Compiler/IDE and SDK:
gcc version 13.2.0 (Ubuntu 13.2.0-4ubuntu3) - Target hardware/board:
Linux t14 6.5.0-15-generic #15-Ubuntu SMP PREEMPT_DYNAMIC Tue Jan 9 17:03:36 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
@cpq I see Content-Lenght is present, I see POST data is apparently complete, it is larger than an Ethernet frame but since this is the loopback it has been transferred on a single frame. I see Mongoose buffer is 2048, content-length is smaller, frame size is larger. I see Mongoose logs 2048, looks like it stops collecting after that, once it needs to enlarge its buffer.
@jcorporation Can you try with a client on a different host ? If that is no burden to you, I'd like to see how it works on regular wire.
Sure, no problem: Same test with a iPhone as client.
Still using some capture mode I don't know or jumbo frames. Anyway:
@cpq Headers arrive on the first frame, immediately arrives the second frame containing the POST. The POST is complete, content-length is present.
According to the log, Mongoose buffers up to its buffer size, the rest remains in limbo, hence eom is never detected.
3bd260 3 sock.c:295:read_conn 6 0x5 snd 0/2048 rcv 0/2048 n=562 err=0
3bd260 2 sock.c:102:iolog
-- 6 0.0.0.0:8443 <- 192.168.88.144:64133 562
0000 50 4f 53 54 20 2f 61 70 69 2f 73 74 61 74 73 20 POST /api/stats
0110 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a .Content-Length:
0120 20 31 39 35 32 0d 0a 55 73 65 72 2d 41 67 65 6e 1952..User-Agen
0230 0d 0a ..
3bd261 3 sock.c:295:read_conn 6 0x5 snd 0/2048 rcv 562/2048 n=1486 err=0
3bd261 2 sock.c:102:iolog
-- 6 0.0.0.0:8443 <- 192.168.88.144:64133 1486
0000 7b 22 6a 73 6f 6e 72 70 63 22 3a 22 32 2e 30 22 {"jsonrpc":"2.0"
05c0 22 3a 22 37 30 32 66 65 64 66 65 2d 37 39 ":"702fedfe-79
562 + 1486 = 2048
Any news on this?
@jcorporation not yet
looking at it.