Re: Sending a largish POST request with --limit-rate delays receiving of small server response

From: Fabian Keil via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 26 Mar 2021 16:44:07 +0100

Fabian Keil via curl-library <curl-library_at_cool.haxx.se> wrote on 2021-03-26:

> Fabian Keil via curl-library <curl-library_at_cool.haxx.se> wrote on
> 2021-03-26:
>
> > Daniel Stenberg <daniel_at_haxx.se> wrote on 2021-03-26:
> >
> > > On Fri, 26 Mar 2021, Fabian Keil via curl-library wrote:
> > >
> > > > Apparently the rate limit only kicks in after the request has been
> > > > sent and as a result the (small) response is then received delayed.
> >
> > > Proposed fix: https://github.com/curl/curl/pull/6797
> >
> > Thanks for the quick fix.
>
> Looks like there's a regression.
>
> If the --limit-rate value is smaller than the CONNECT request
> curl now hangs after the first write until Privoxy's connection
> timeout is triggered:

Thanks for the update pushed to bagder/http-post-speed-limit.

With the commit 9334e4de31a added, one of my tests for Privoxy
reliably triggers a DEBUGASSERT in curl.

fk_at_t520 ~/git/curl $gdb101 src/curl tests/curl.core
[...]
Core was generated by `../src/curl --output log/curl6.out --include --trace-ascii log/trace6 --trace-ti'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00000008022e014a in thr_kill () from /lib/libc.so.7
(gdb) where
#0 0x00000008022e014a in thr_kill () from /lib/libc.so.7
#1 0x00000008022e0114 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2 0x00000008022e0089 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#3 0x0000000802359961 in __assert (func=<optimized out>, file=<optimized out>, line=<optimized out>, failedexpr=<optimized out>) at /usr/src/lib/libc/gen/assert.c:51
#4 0x000000000048698c in Curl_buffer_send (in=0x7fffffff57e0, data=0x803100808, bytes_written=0x803101bf0, included_body_bytes=35008, socketindex=0) at http.c:1271
#5 0x000000000048948b in Curl_http_bodysend (data=0x803100808, conn=0x80301dc08, r=0x7fffffff57e0, httpreq=HTTPREQ_POST) at http.c:2659
#6 0x000000000048aab4 in Curl_http (data=0x803100808, done=0x7fffffff591c) at http.c:3218
#7 0x000000000043d75d in multi_do (data=0x803100808, done=0x7fffffff591c) at multi.c:1393
#8 0x000000000043e775 in multi_runsingle (multi=0x8030e21c8, nowp=0x7fffffff5a00, data=0x803100808) at multi.c:1885
#9 0x000000000043f967 in curl_multi_perform (multi=0x8030e21c8, running_handles=0x7fffffff5a54) at multi.c:2398
#10 0x000000000042c49e in easy_transfer (multi=0x8030e21c8) at easy.c:606
#11 0x000000000042c694 in easy_perform (data=0x803100808, events=false) at easy.c:696
#12 0x000000000042c6d8 in curl_easy_perform (data=0x803100808) at easy.c:715
#13 0x00000000004226ac in serial_transfers (global=0x7fffffff5c00, share=0x803054008) at tool_operate.c:2379
#14 0x0000000000422b40 in run_all_transfers (global=0x7fffffff5c00, share=0x803054008, result=CURLE_OK) at tool_operate.c:2553
#15 0x0000000000422e8d in operate (global=0x7fffffff5c00, argc=15, argv=0x7fffffff5cd0) at tool_operate.c:2669
#16 0x0000000000418bea in main (argc=15, argv=0x7fffffff5cd0) at tool_main.c:277
(gdb) f 4
#4 0x000000000048698c in Curl_buffer_send (in=0x7fffffff57e0, data=0x803100808, bytes_written=0x803101bf0, included_body_bytes=35008, socketindex=0) at http.c:1271
1271 DEBUGASSERT((size_t)overflow < sendsize);
(gdb) p overflow
$1 = 30912
(gdb) p sendsize
$2 = 16384
(gdb) p *bytes_written
$3 = 118
(gdb) p *in
$4 = {
  bufr = 0x803224088 "POST /6 HTTP/1.1\r\nHost: 127.0.0.1:24984\r\nUser-Agent: curl/7.76.0-DEV\r\nAccept: */*\r\nContent-Length: 35008\r\nContent-Type: application/x-www-form-urlencoded\r\n\r\nblafaselpaddingpaddingpaddingpaddingpadding"..., leng = 35165, allc = 65536, toobig = 1048576, init = 200167898}

The values for overflow, sendsize and *bytes_written seem to
be stable, I tried three times and got the same ones.

The test <command> is:
--limit-rate 4k -d "blafasel%repeat[5000 x padding]%" --insecure https://%HOSTIP:%HTTPSPORT/%TESTNUMBER

Fabian


-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-03-26