Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: 8.3.0: test1474 fails every time
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 17 Sep 2023 14:05:51 -0700
On Sun, Sep 17, 2023 at 10:43:17PM +0200, Christian Weisgerber via curl-library wrote:
> The comment for test1474 says "This test is quite timing dependent and
> tricky to set up." On OpenBSD, it fails every time for me. And this
> is not an overloaded machine.
I've noticed failures on the NetBSD autobuilds as well, but I've been unable to
successfully install NetBSD in a VM to test it. Maybe I'll have more luck with
OpenBSD. What I noticed in the NetBSD logs is that rather than receiving an
initial 64 KiB block of data, it looks like on NetBSD it's only receiving
closer to 48 KiB. I wanted to try this patch on NetBSD to see if it's related
to Nagle's algorithm, but couldn't get to the point where I could try it:
diff --git a/tests/data/test1474 b/tests/data/test1474
index 848f15211..24b349b19 100644
--- a/tests/data/test1474
+++ b/tests/data/test1474
_at__at_ -82,7 +82,7 _at__at_ http
HTTP PUT with Expect: 100-continue and 417 response during upload
</name>
<command>
-http://%HOSTIP:%HTTPPORT/we/want/%TESTNUMBER -T %LOGDIR/test%TESTNUMBER.txt --limit-rate 64K --expect100-timeout 0.001
+http://%HOSTIP:%HTTPPORT/we/want/%TESTNUMBER -T %LOGDIR/test%TESTNUMBER.txt --limit-rate 64K --expect100-timeout 0.001 --tcp-nodelay
</command>
# Must be large enough to trigger curl's automatic 100-continue behaviour
<file name="%LOGDIR/test%TESTNUMBER.txt">
It's a finicky test (which is why it's marked flaky) but it should work fine on
an unloaded system.
Dan
Date: Sun, 17 Sep 2023 14:05:51 -0700
On Sun, Sep 17, 2023 at 10:43:17PM +0200, Christian Weisgerber via curl-library wrote:
> The comment for test1474 says "This test is quite timing dependent and
> tricky to set up." On OpenBSD, it fails every time for me. And this
> is not an overloaded machine.
I've noticed failures on the NetBSD autobuilds as well, but I've been unable to
successfully install NetBSD in a VM to test it. Maybe I'll have more luck with
OpenBSD. What I noticed in the NetBSD logs is that rather than receiving an
initial 64 KiB block of data, it looks like on NetBSD it's only receiving
closer to 48 KiB. I wanted to try this patch on NetBSD to see if it's related
to Nagle's algorithm, but couldn't get to the point where I could try it:
diff --git a/tests/data/test1474 b/tests/data/test1474
index 848f15211..24b349b19 100644
--- a/tests/data/test1474
+++ b/tests/data/test1474
_at__at_ -82,7 +82,7 _at__at_ http
HTTP PUT with Expect: 100-continue and 417 response during upload
</name>
<command>
-http://%HOSTIP:%HTTPPORT/we/want/%TESTNUMBER -T %LOGDIR/test%TESTNUMBER.txt --limit-rate 64K --expect100-timeout 0.001
+http://%HOSTIP:%HTTPPORT/we/want/%TESTNUMBER -T %LOGDIR/test%TESTNUMBER.txt --limit-rate 64K --expect100-timeout 0.001 --tcp-nodelay
</command>
# Must be large enough to trigger curl's automatic 100-continue behaviour
<file name="%LOGDIR/test%TESTNUMBER.txt">
It's a finicky test (which is why it's marked flaky) but it should work fine on
an unloaded system.
Dan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-09-17