You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My read of the spec for 307/308 is that we must not redirect automatically with the same method without the user doing something non-default to allow this.
Here are various considerations and thoughts in response:
User sends POST to https, but 307/308 redirect says redirect to http (i.e. non TLS secure). We must not do that by default.
We could add an "allow_unsafe_redirect" config argument that does always redirect 307/308 verbatim, but it must default to off.
If the user provided a content callback, we can't redirect 307/308 as we have no way to rewind/restart the callback.
We could add a 'continue_redirect' method that takes a response object and continues a 307/308. This would be indicative of a user agreeing to the redirection risk and would allow the user to provide a new, refreshed content callback (or other request options).
I lean towards that last approach as it puts "safety" in the hands of the user and solves the callback problem at the same time.
it might look something like this:
my $client = HTTP::Tiny->new;
my $response = $client->post( 'http://example.com/', { content => get_callback() } );
while ( $response->{status} == 307 || $response->{status} == 308 ) {
last unless redirect_is_safe( $response );
$response = $client->continue_redirect( $response, { content => get_callback() } )
}
die "Failed!\n" unless $response->{success};
# do stuff with response
...
That might require including more request data in the response object in order to be able to continue where it left off. That might or might not be good from a memory/lifetime perspective, but might be fine if limited to redirection cases.
The text was updated successfully, but these errors were encountered:
[This is reposted from a comment on #99]
My read of the spec for 307/308 is that we must not redirect automatically with the same method without the user doing something non-default to allow this.
Here are various considerations and thoughts in response:
I lean towards that last approach as it puts "safety" in the hands of the user and solves the callback problem at the same time.
it might look something like this:
That might require including more request data in the response object in order to be able to continue where it left off. That might or might not be good from a memory/lifetime perspective, but might be fine if limited to redirection cases.
The text was updated successfully, but these errors were encountered: