When it comes to situations where URLs need to be redirected with a trailing slash added, there are instances where servers have flawed configurations that hardcode 'http:' in the redirect—even if the server has other settings redirecting all 'http' URLs to 'https' afterwards.
For instance, in the scenario mentioned, a URL like https://tithe.ly/give?c=1401851 (without a trailing slash) was being directed to http://tithe.ly/give/?c=1401851 (with 'http' instead of 'https'). This discrepancy caused a mixed-content error in the browser.
The URL http://tithe.ly/give/?c=1401851 eventually redirected to https://tithe.ly/give/?c=1401851 ('https') in this case. To resolve the issue highlighted in the question, the request URL in the original source should be changed to https://tithe.ly/give/?c=1401851 (including the trailing slash).
If you were to directly access https://tithe.ly/give?c=1401851 (without the trailing slash), the series of redirects mentioned in this explanation would occur seamlessly, making it appear as though the initial URL is correct. This can be confusing when trying to pinpoint why it isn't functioning correctly.
Furthermore, inspecting the Network panel in browser developer tools will not easily display the redirect chain, as browsers typically handle redirects behind the scenes—unless there is a non-https URL in the chain, which causes the browser to halt and disrupt the sequence.
Therefore, a key troubleshooting and debugging suggestion for such issues is: Utilize a command-line HTTP client like curl to verify the request URL and navigate through each redirect reported, paying close attention to the values in the Location response header; similar to the example below:
$ curl -i https://tithe.ly/give?c=1401851
…
location: http://tithe.ly/give/?c=1401851
…
$ curl -i http://tithe.ly/give/?c=1401851
…
Location: https://tithe.ly/give/?c=1401851