Middleware only redirecting one level deep about connect-history-api-fallback

[bripkens]

Interesting issue. You can start debugging this issue by enabling logging via the verbose option:

history({
  verbose: true
})

This will print redirect reasons to the console.

Thanks @bripkens. I did try this and this is the relevant line that I get:

Rewriting GET /practice/1 to /index.html

Not sure where to go from there, however..

[bripkens]

This is the correct behavior for the history API fallback. See the following section from the README.

• The request is a GET request
• which accepts text/html,
• is not a direct file request, i.e. the requested path does not contain a . (DOT) character and
• does not match a pattern provided in options.rewrites (see options below)

Right, that makes sense.

What I'm wondering is, given this behavior, why /practice is preserved but /practice/1 is not. Is there anything I can do with this library to preserve the rest of the path? Or, if this concern has nothing to do with this library, I'd still love to be pointed in the right direction if you have any ideas.

It seems strange to me that being unable to directly access any path beyond one level deep would be expected behavior, which makes me think I must be missing something.

So, I took a look at my S3 rewrite rules as I'm getting the desired behavior there.

<RoutingRules>
    <RoutingRule>
        <Condition>
            <HttpErrorCodeReturnedEquals>403</HttpErrorCodeReturnedEquals>
        </Condition>
        <Redirect>
            <HostName>practice-staging.pollinate.life</HostName>
            <ReplaceKeyPrefixWith>#/</ReplaceKeyPrefixWith>
        </Redirect>
    </RoutingRule>
</RoutingRules>

So I'm realizing that what I'm asking for is that I would like /practice/1 to redirect to /#/practice/1.

Is that out of the scope of this library or is there configuration I can pass to get that same behavior?

I'm going to close this out, on investigating this further I don't think it has probably has much to do with this middleware. I figured out the correct rewrite rule, but it's still not working. Probably something with my setup. Thanks!

Sure enough, this was some routing code I had in my Angular app. Sorry about that.