curl/tests/data/test357
Dan Fandrich 2ef67901cc tests: add some --expect100-timeout to reduce timing dependencies
These tests can fail when the test machine is so slow that the test HTTP
server didn't get a chance to complete before the client's one second
100-continue timeout triggered. Increase that 1 second to 999 seconds so
this situation doesn't happen.

Ref: #11328
2023-09-13 11:26:08 -07:00

82 lines
1.4 KiB
Plaintext

<testcase>
<info>
<keywords>
HTTP
HTTP PUT
Expect
</keywords>
</info>
# Server-side
<reply>
# 417 means the server didn't like the Expect header
<data>
HTTP/1.1 417 BAD swsbounce
Date: Tue, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Content-Length: 0
</data>
<data1>
HTTP/1.1 200 OK
Date: Tue, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Content-Length: 10
blablabla
</data1>
<datacheck>
HTTP/1.1 417 BAD swsbounce
Date: Tue, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Content-Length: 0
HTTP/1.1 200 OK
Date: Tue, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Content-Length: 10
blablabla
</datacheck>
<servercmd>
no-expect
</servercmd>
</reply>
# Client-side
<client>
<server>
http
</server>
<name>
HTTP PUT with Expect: 100-continue and 417 response
</name>
<command>
http://%HOSTIP:%HTTPPORT/we/want/%TESTNUMBER -T %LOGDIR/test%TESTNUMBER.txt --expect100-timeout 999
</command>
# 1053700 x 'x', large enough to invoke the 100-continue behaviour
<file name="%LOGDIR/test%TESTNUMBER.txt">
%repeat[1053700 x x]%
</file>
</client>
# Verify data after the test has been "shot"
<verify>
<protocol>
PUT /we/want/%TESTNUMBER HTTP/1.1
Host: %HOSTIP:%HTTPPORT
User-Agent: curl/%VERSION
Accept: */*
Content-Length: 1053701
Expect: 100-continue
PUT /we/want/%TESTNUMBER HTTP/1.1
Host: %HOSTIP:%HTTPPORT
User-Agent: curl/%VERSION
Accept: */*
Content-Length: 1053701
%repeat[1053700 x x]%
</protocol>
</verify>
</testcase>