1<testcase> 2# This test is quite timing dependent and tricky to set up. The time line of 3# test operations looks like this: 4# 5# 1. curl sends a PUT request with Expect: 100-continue and waits only 1 msec 6# for a 100 response. 7# 2. The HTTP server accepts the connection but waits 500 msec before acting 8# on the request. 9# 3. curl doesn't receive the expected 100 response before its timeout expires, 10# so it starts sending the body. It is throttled by a --limit-rate, so it 11# sends the first 64 KiB then stops for 1000 msec due to this 12# throttling. 13# 4. The server sends its 417 response while curl is throttled. 14# 5. curl responds to this 417 response by closing the connection (because it 15# has a half-completed response outstanding) and starting a new one. This 16# new request does not have an Expect: header so it is sent without delay. 17# It's still throttled, however, so it takes about 16 seconds to finish 18# sending. 19# 6. The server receives the response and this time acks it with 200. 20# 21# Because of the timing sensitivity (scheduling delays of 500 msec can cause 22# the test to fail), this test is marked flaky to avoid it being run in the CI 23# builds which are often run on overloaded servers. 24# Increasing the --limit-rate would decrease the test time, but at the cost of 25# becoming even more sensitive to delays (going from 500 msec to 250 msec or 26# less of accepted delay before failure). Adding a --speed-time would increase 27# the 1 second delay between writes to longer, but it would also increase the 28# total time needed by the test, which is already quite high. 29# 30# The assumption in step 3 is also broken on NetBSD 9.3, OpenBSD 7.3 and 31# Solaris 10 as they only usually send about half the requested amount of data 32# (see https://curl.se/mail/lib-2023-09/0021.html). 33<info> 34<keywords> 35HTTP 36HTTP PUT 37Expect 38flaky 39timing-dependent 40</keywords> 41</info> 42# Server-side 43<reply> 44# 417 means the server didn't like the Expect header 45<data> 46HTTP/1.1 417 BAD swsbounce 47Date: Tue, 09 Nov 2010 14:49:00 GMT 48Server: test-server/fake 49Content-Length: 0 50 51</data> 52<data1> 53HTTP/1.1 200 OK 54Date: Tue, 09 Nov 2010 14:49:00 GMT 55Server: test-server/fake 56Content-Length: 10 57 58blablabla 59</data1> 60<datacheck> 61HTTP/1.1 417 BAD swsbounce 62Date: Tue, 09 Nov 2010 14:49:00 GMT 63Server: test-server/fake 64Content-Length: 0 65 66HTTP/1.1 200 OK 67Date: Tue, 09 Nov 2010 14:49:00 GMT 68Server: test-server/fake 69Content-Length: 10 70 71blablabla 72</datacheck> 73<servercmd> 74no-expect 75delay: 500 76connection-monitor 77</servercmd> 78</reply> 79 80# Client-side 81<client> 82<server> 83http 84</server> 85<name> 86HTTP PUT with Expect: 100-continue and 417 response during upload 87</name> 88<command> 89http://%HOSTIP:%HTTPPORT/we/want/%TESTNUMBER -T %LOGDIR/test%TESTNUMBER.txt --limit-rate 64K --expect100-timeout 0.001 90</command> 91<precheck> 92perl -e "print 'Test does not work on this BSD system' if ( $^O eq 'netbsd' || $^O eq 'openbsd' || ($^O eq 'solaris' && qx/uname -r/ * 100 <= 510));" 93</precheck> 94# Must be large enough to trigger curl's automatic 100-continue behaviour 95<file name="%LOGDIR/test%TESTNUMBER.txt"> 96%repeat[132 x S]%%repeat[16462 x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx%0a]% 97</file> 98</client> 99 100# Verify data after the test has been "shot" 101<verify> 102<protocol> 103PUT /we/want/%TESTNUMBER HTTP/1.1 104Host: %HOSTIP:%HTTPPORT 105User-Agent: curl/%VERSION 106Accept: */* 107Content-Length: 1053701 108Expect: 100-continue 109 110%repeat[132 x S]%%repeat[1021 x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx%0a]%%repeat[60 x x]%[DISCONNECT] 111PUT /we/want/%TESTNUMBER HTTP/1.1 112Host: %HOSTIP:%HTTPPORT 113User-Agent: curl/%VERSION 114Accept: */* 115Content-Length: 1053701 116 117%repeat[132 x S]%%repeat[16462 x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx%0a]% 118[DISCONNECT] 119</protocol> 120</verify> 121</testcase> 122