handle redirect with processors

[philippe44]

There is an issue when using "processors" (e.g. mp4 => aac) and the HTTP requests redirect. The on-the-fly created header (initialAudioBlock) is overwritten by the recursive calls in S::P::P::HTTP.pm::request.

This is a 8.1 patch that does not need to be ported to 8.2 as this PR includes it as well

[michaelherger]

My Perl isn't good enough. Please help me!

[michaelherger]

Wouldn't this only be executed if the above condition was true? Therefore could be moved up there?

[philippe44]

I'm not sure. There could be many reasons why above he initialAudioBlock could still be uninitialized and I want to make sure it does not remains undef. What am I missing?

[michaelherger]

I need some help here: what exactly does the second condition do?...

[philippe44]

It checks that is there in the hash. It is the way to know if we are the first call in a chain of redirection or not. Because we must only execute the code underneath for the actual used request, not for the redirect one. We could have 5 redirections and so that code will be called 6 times, recursively. When unfolding, the $self will always be the same but only the very inner call will be useful, and this is the only one with non-existing 'initialAudioBlockRef".

See S::F::RemoteStream::request

if (my $redir = $self->redirect) {
		# Redirect -- maybe recursively?

		# Close the existing handle and refcnt-- to avoid keeping the
		# socket in a CLOSE_WAIT state and leaking.
		$self->close();

		# some 302 location omit the protocol, take it from original url
		$redir = Slim::Utils::Misc::cloneProtocol($redir, $url);
		main::INFOLOG && $log->info("Redirect to: $redir");

		return $class->new({
			'url'     => $redir,
			'song'    => $args->{'song'},
			'infoUrl' => $self->infoUrl,
			'post'    => $post,
			'create'  => $args->{'create'},
			'client'  => $args->{'client'},
		});
	}