https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8101
Sidney Markowitz <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Hardware|PC |All OS|Linux |All --- Comment #1 from Sidney Markowitz <[email protected]> --- Thanks for catching the problem. On analysis, I don't think the problem is in how SpamAssassin handles parsing of the URL as in RFC 3986. The server at bitly gets it and provides a redirect result based on what it thinks the URL means, and SpamAssassin uses whatever is handed back. When it has a URL that looks like https://bit.ly//1Zmfo8z DecodeShortURL.pm gets to line 853 # Check if we are being redirected to a local page # Don't recurse in this case... and at line 864 $location = "$short_url/$location"; dbg("looks like a local redirection: $orig_short_url => $location ($orig_location)"); $pms->add_uri_detail_list($location) if !$pms->{uri_detail_list}->{$location}; return; In this case, as you can see from the output of curl -I https://bit.ly//1Zmfo8z the bitly server handles the parsing and returns a redirect to /1Zmfo8z which the above code handles as a redirect to a local page. That's the bug, as RFC 7231 says "Location = URI-reference The field value consists of a single URI-reference. When it has the form of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5)." So when the code determines that the redirect location is a relative URL like /1Zmfo8z it should change it to https://bit.ly/1Zmfo8z and recurse. I'll work up a patch and add a test case. -- You are receiving this mail because: You are the assignee for the bug.
