CURLOPT_FOLLOWLOCATION: add a CURLFOLLOW_NO_CUSTOMMETHOD bit #8130
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bagder
added
HTTP
feature-window
|
|
I read that and it looks like cacheable database search results. So then the resource (database) changes and it's invalidated? I wonder how it will work in practice. |
bagder
added a commit
that referenced
this pull request
Jan 9, 2022
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
bagder
force-pushed
the
bagder/ignore-custom-request-on-redir
branch
from
38a0c0a
to
760c140
Compare
bagder
changed the title
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
bagder
force-pushed
the
bagder/ignore-custom-request-on-redir
branch
from
760c140
to
ffc9398
Compare
jay
reviewed
Jan 30, 2022
| \fIenable\fP is a bitmask. If you set the \fICURLFOLLOW_NO_CUSTOMMETHOD\fP | ||
| bit, it will tell libcurl that the method set with | ||
| \fICURLOPT_CUSTOMREQUEST(3)\fP will not be used after a redirect if the HTTP | ||
| response says so. |
There was a problem hiding this comment.
Rather than have the user set curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, CURLFOLLOW_NO_CUSTOMMETHOD | CURLFOLLOW_ENABLE); , you could instead define CURLFOLLOW_NO_CUSTOMMETHOD as 3 and get rid of CURLFOLLOW_ENABLE. If you feel the bitfield really is the way to go then you should add CURLFOLLOW_DISABLE as well, and document them both.
|
I'm not sensing any particular interest from users for this so I'll close this again for this time and maybe bring it back at a later time. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(This is a re-run. This change was already proposed for inclusion in 7.66.0 in #3803 but due to lack of interest I retracted it back then. Since this change would allow us to make a
-Xfrom curl that is "less bad", which also might be interesting when considering a coming QUERY method, I think/hope it might get some more interest this time around!?)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_CUSTOMREQUEST 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_CUSTOMREQUEST 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_CUSTOMREQUEST string override the method, disregarding what the
HTTP response code suggests.
Test 1589 added to verify the functionality.