How to diagnose Redirect infinite loop - servicestack

Question

We had to downgrade from servicestack v5.4 free edition back to v4.5.14 paid edition. The only change needed to make the downgrade compile was one line in the Service code:
v5.4 code:
[FallbackRoute("/{PathInfo*}", Matches="AcceptsHtml")]
v4.5.14 code:
[FallbackRoute("/{PathInfo*}")]
I have not yet figured out how to implement the 'matches' portion in 4.5.14, however the code still seems to run and when launched from VS2017 where the service runs as a command line webservice, however intermittently a infinite-redirect occurs. In prod where the app runs as a windows service, the infinite redirect happens 100% of the time.
The result is when I visit the url:
https://server.domain.com:port
Which should simply redirect to:
https://server.domain.com:port/login
What happens is this:
https://server.domain.com:9797/login?redirect=https%3a%2f%2fserver.domain.com%3a9797%2flogin%3fredirect%3dhttps%253a%252f%252fserver.domain.com%253a9797%252flogin%253fredirect%253dhttps%25253a%25252f%25252fserver.domain.com%25253a9797%25252flogin%25253fredirect%25253dhttps%2525253a%2525252f%2525252fserver.domain.com%2525253a9797%2525252flogin%2525253fredirect%2525253dhttps%252525253a%252525252f%252525252fserver.domain.com%252525253a9797%252525252flogin%252525253fredirect%252525253dhttps%25252525253a%25252525252f%25252525252fserver.domain.com%25252525253a9797%25252525252flogin%25252525253fredirect%25252525253dhttps%2525252525253a%2525252525252f%2525252525252fserver.domain.com%2525252525253a9797%2525252525252flogin%2525252525253fredirect%2525252525253dhttps%252525252525253a%252525252525252f%252525252525252fserver.domain.com%252525252525253a9797%252525252525252flogin%252525252525253fredirect%252525252525253dhttps%25252525252525253a%25252525252525252f%25252525252525252fserver.domain.com%25252525252525253a9797%25252525252525252flogin%25252525252525253fredirect%25252525252525253dhttps%2525252525252525253a%2525252525252525252f%2525252525252525252fserver.domain.com%2525252525252525253a9797%2525252525252525252flogin%2525252525252525253fredirect%2525252525252525253dhttps%252525252525252525253a%252525252525252525252f%252525252525252525252fserver.domain.com%252525252525252525253a9797%252525252525252525252flogin%252525252525252525253fredirect%252525252525252525253dhttps%25252525252525252525253a%25252525252525252525252f%25252525252525252525252fserver.domain.com%25252525252525252525253a9797%25252525252525252525252flogin%25252525252525252525253fredirect%25252525252525252525253dhttps%2525252525252525252525253a%2525252525252525252525252f%2525252525252525252525252fserver.domain.com%2525252525252525252525253a9797%2525252525252525252525252flogin%2525252525252525252525253fredirect%2525252525252525252525253dhttps%252525252525252525252525253a%252525252525252525252525252f%252525252525252525252525252fserver.petersc
Has anyone seen this before? Any suggestions for where to start debugging this would be appreciated.
More Info
So I tried removing the Authenticate attribute from my service to see if the loop was being caused by Authentication or something else. Turns out it's the authentication that's causing the loop. Once I commented out the attribute, everything worked as expected.
Update
I this loop is definitely caused by the AuthenticateAttribute.
I commented out the line 'url = url.AddQueryParam(...' so that I would not get a huge query string of garbage in the hopes that would fix something. But it looks like something else is not right. Below is the headers from the initial request.
GET https://myServer.myDomain.com:9797/ HTTP/1.1
Host: myServer.myDomain.com:9797
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: ss-pid=qt9Lqb2YvWUu9RzLBlfr
Here are the response headers
HTTP/1.1 302 Found
Transfer-Encoding: chunked
Location: https://myServer.myDomain.com:9797/login
Vary: Accept
Server: Microsoft-HTTPAPI/2.0
Set-Cookie: ss-pid=kczdbSouUzx6aURug3ZU;path=/;expires=Fri, 01 Apr 2039 21:24:01 GMT;HttpOnly
Set-Cookie: ss-id=nAQeqGptASLQ1fZj4xs7;path=/;HttpOnly
X-Powered-By: ServiceStack/4.514 NET45 Win32NT/.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
Access-Control-Allow-Headers: Content-Type
Date: Mon, 01 Apr 2019 21:24:01 GMT
After the first request, there are about 60 redirects which all look like:
Request:
GET https://myServer.myDomain.com:9797/login HTTP/1.1
Host: myServer.myDomain.com:9797
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: ss-pid=kczdbSouUzx6aURug3ZU; ss-id=nAQeqGptASLQ1fZj4xs7
Response:
HTTP/1.1 302 Found
Transfer-Encoding: chunked
Location: https://windows7vm1.petersco.com:9797/login
Vary: Accept
Server: Microsoft-HTTPAPI/2.0
X-Powered-By: ServiceStack/4.514 NET45 Win32NT/.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
Access-Control-Allow-Headers: Content-Type
Date: Mon, 01 Apr 2019 21:24:01 GMT
I'm not seeing anything to indicate why this should loop. The only thing that changed was the version of ServiceStack, why would one version find the html page and the other not? Is there something special I need to add to v4.5.14 to get it to respond with index.html?

Answer 1

So I could not believe that the AuthenticateAttribute would have such a glaring problem, ServiceStack is far too mature and far too awesome for this to be a bug. So using that assumption (it is usually safe to assume you are the problem and not the genius who found the one bug that everyone else missed), I started to look at the routes and compare them to some old samples for SPA's available on github and noticed that none of them had a FallbackRoute defined.
This seemed odd to me, but seeing as how I don't know the history of how this feature came to become part of the v5.* template in the first place, I thought removing these lines may work. It did.
Removing this:
[FallbackRoute("/{PathInfo*}"]
public class FallbackForClientRoutes
{
public string PathInfo { get; set; }
}
And this:
public object Any(FallbackForClientRoutes request) =>
new PageResult(Request.GetPage("/"));
Made everything go back to normal, navigating to the base url redirects to ~login and all the api methods are back to being authenticated. I have lost the ability to navigate directly to a URL like http://myServer.myDomain.com:port/ListCompanies... but my guess is that has something to do with Routing as well (so more homework to do).