-
Notifications
You must be signed in to change notification settings - Fork 56
Open
Labels
Description
[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:
- 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.