summaryrefslogtreecommitdiff
path: root/docs/libcurl/opts/CURLOPT_KRBLEVEL.3
diff options
context:
space:
mode:
authorDaniel Stenberg <daniel@haxx.se>2022-01-17 22:58:49 +0100
committerDaniel Stenberg <daniel@haxx.se>2022-01-17 22:58:49 +0100
commitffc939826bb05cc97168878eb596c3e5c228bd16 (patch)
tree8e06a46d969d7ce9ef6677f499ba71cd3e5b140d /docs/libcurl/opts/CURLOPT_KRBLEVEL.3
parent52826d3b791e0436a2338ed36e38a2f7e1f4e9a6 (diff)
downloadcurl-bagder/ignore-custom-request-on-redir.tar.gz
CURLOPT_FOLLOWLOCATION: add a CURLFOLLOW_NO_CUSTOMMETHOD bitbagder/ignore-custom-request-on-redir
With this change, the argument passed to the CURLOPT_FOLLOWLOCATION option is treated as a bitmask instead of just a long. If the new CURLFOLLOW_NO_CUSTOMMETHOD bit is set in the bitmask, it means that libcurl will NOT allow a custom method override the HTTP request method after a redirect is followed. As is otherwise the default behavior (that surprises many users). This change is forward compatible because CURLOPT_FOLLOWLOCATION has been documented to accept the exact value of '1' to enable redirect following and therefore the other bits were left unused and undefined. We now add value to another bit. Starting in 7.66.0, the value 1 and the first bit still enables plain redirect following but the second bit adds more meaning. This change is backward compatible in the following way: setting the CURLFOLLOW_NO_CUSTOMMETHOD bit in a program that still uses an older libcurl installation at run-tim will have no effect. This is because older libcurl code checked if the value was non-zero and then enabled redirect following. Of course older libcurl will always let the set CURLOPT_CUSTOMMETHOD string override the method, disregarding what the HTTP response code suggests. Test 1589 added to verify the functionality. Closes #8130
Diffstat (limited to 'docs/libcurl/opts/CURLOPT_KRBLEVEL.3')
0 files changed, 0 insertions, 0 deletions