CURLOPT_DEFAULT_PROTOCOL: added

- Add new option CURLOPT_DEFAULT_PROTOCOL to allow specifying a default
protocol for schemeless URLs.

- Add new tool option --proto-default to expose
CURLOPT_DEFAULT_PROTOCOL.

In the case of schemeless URLs libcurl will behave in this way:

When the option is used libcurl will use the supplied default.

When the option is not used, libcurl will follow its usual plan of
guessing from the hostname and falling back to 'http'.
This commit is contained in:
Nathaniel Waisbrot 2015-08-22 21:49:26 -04:00 committed by Jay Satiro
parent 22cb631198
commit 9756d1da76
21 changed files with 287 additions and 36 deletions

View file

@ -166,4 +166,4 @@ test2008 test2009 test2010 test2011 test2012 test2013 test2014 test2015 \
test2016 test2017 test2018 test2019 test2020 test2021 test2022 test2023 \
test2024 test2025 test2026 test2027 test2028 test2029 test2030 test2031 \
test2032 test2033 test2034 test2035 test2036 test2037 test2038 test2039 \
test2040 test2041 test2042 test2043
test2040 test2041 test2042 test2043 test2044 test2045

33
tests/data/test2044 Normal file
View file

@ -0,0 +1,33 @@
<testcase>
<info>
<keywords>
--proto-default
</keywords>
</info>
#
# Client-side
<client>
<features>
none
</features>
<server>
none
</server>
<name>
Attempt to set a default protocol that does not exist
</name>
<command>
--proto-default DOESNOTEXIST
</command>
</client>
#
# Verify data after the test has been "shot"
<verify>
# CURLE_UNSUPPORTED_PROTOCOL is error code 1
<errorcode>
1
</errorcode>
</verify>
</testcase>

54
tests/data/test2045 Normal file
View file

@ -0,0 +1,54 @@
<testcase>
<info>
<keywords>
FTP
--proto-default
</keywords>
</info>
#
# Server-side
<reply>
<!--
The purpose of this test is to make sure the --proto-default option works
properly. We specify a default protocol of FTP and if the option works properly
curl will use the FTP protocol. If the option is broken however curl will use
the HTTP protocol.
In the broken scenario curl would use HTTP to talk to our FTP server. We handle
that by replying with something that both protocols can understand. Our FTP
server allows a custom welcome message, so we use that feature to make an HTTP
reply that contains an FTP reply (think polyglot). In the case of FTP we expect
curl will return CURLE_FTP_WEIRD_SERVER_REPLY so we test for that return code.
-->
<servercmd>
REPLY welcome HTTP/1.1 200 OK\r\nContent-Length: 21\r\n\r\n500 Weird FTP Reply
</servercmd>
</reply>
#
# Client-side
<client>
<features>
none
</features>
<server>
ftp
</server>
<name>
Set the default protocol to ftp for a schemeless URL
</name>
<command>
-H "User-Agent:" -H "Host:" -H "Accept:" --proto-default ftp %HOSTIP:%FTPPORT
</command>
</client>
#
# Verify data after the test has been "shot"
<verify>
# CURLE_FTP_WEIRD_SERVER_REPLY is error code 8
<errorcode>
8
</errorcode>
</verify>
</testcase>