I can now say that the problem indeed is that LWP was following redirects (as it should). But also myself was also following redirects by issuing another request via LWP.

So how I solved it was to set

$ua->requests_redirectable([]);
[download]

which tells LWP::UserAgent not to follow any redirects for any request.

(setting

$ua->requests_redirectable(['GET']);
[download]

would allow only GET to be followed by LWP).

I have also discovered that there is another problem with allowing UA to follow redirects. In a redirect the server sends a Location header which contains the url of the redirect and issues a 302 status (or 30X something). UA extracts this Location url and issues another request to there.

The problem lies in the server sometimes sending a relative url back. And UA tries to make it absolute. In my case, UA failed to do that. So even if I allowed UA to follow redirect, it would have failed in sending a malformed url to the server.

UA has the following code to convert the url:

        my $referral_uri = $response->header('Location');
        {
            # Some servers erroneously return a relative URL for redir
+ects,
            # so make it absolute if it not already is.
            local $URI::ABS_ALLOW_RELATIVE_SCHEME = 1;
            my $base = $response->base;
            $referral_uri = "" unless defined $referral_uri;
            $referral_uri
                = $HTTP::URI_CLASS->new($referral_uri, $base)->abs($ba
+se);
        }
        $referral->uri($referral_uri);
[download]

In my case:

base='http://server.com/ABC/afilename1?op=678'
referral='../../ABC/XYZ/KLM/afilename2?aa=123'
[download]

and the calculated new referral came out as:

http://server.com/../ABC/XYZ/KLM/afilename2?aa=123
[download]

instead of the correct one of:

http://server.com/ABC/XYZ/KLM/afilename2?aa=123
[download]

may be this is expected behaviour from URI->abs()?< I will send a bug report just in case.

Thanks Monks