URL Rewrite rule fails when using cleanblog theme

[darrelmiller]

https://github.com/statiqdev/statiqdev.github.io/blob/91f859804f6eafdc1ebe0a574d65f7c25dca58bf/input/web/deployment/azure-app-service.md#L50

As the cleanblog created summary HTML files with the same name as folders, the above redirect rules failed to rewrite to the posts.html and the tags.html. I'm not sure if the right option is to change the cleanblog theme to create the posts.html as index.html in the posts folder and tags folder, but for the moment, the redirects below solved my problems.

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="html">
          <match url="(.+)/?" />
          <conditions logicalGrouping="MatchAny">
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" />
          </conditions> 
          <action type="Rewrite" url="{R:1}.html" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

[daveaglick]

That's some impressive redirect hacking!

😬

So I've confirmed the behavior (not much doubt there) and I'm conflicted on where the problem is and what should be done to fix it:

• This could be considered "by design" and to the extent a host doesn't do a great job of supporting extensionless file URLs combined with folders, that's a host problem. In that perspective, the above changes to the canonical redirects file for IIS in the documentation will certainly help. My only reservation to changing it at all is that it took a long time to get it just right in the first place and I'm not sure how to test this now version to make sure none of the behavior breaks (any thoughts here? was this already run through some paces?).
• On the other hand, "deal with it" isn't really the experience I want for Statiq and this seems like a pretty bad behavior anyway. For example, what happens if the similarly named folder also has an index.html? Is it clear which one "wins"? How would you get to the other one? If we start from is perspective, a couple other mitigations seem like good ideas:
  • Adjust the CleanBlog theme to not do this. It's an official theme, so that certainly seems in-scope. We'd have to be careful though because there are already lots of folks using it and I don't want to suddenly break all their URLs. The best approach would probably be to produce the /posts.html under /posts/index.html instead (and likewise for tags.html).
  • We obviously don't have control over every theme, so an analyzer could help here too. I can write one that checks for output files with the same name as output folders and (warn? error?) when this situation is identified.

[darrelmiller]

I don't know what the answer is. The rewrite rules do seem to be working for me at the moment but I have not tested extensively. I do think that having index.html in the posts folder rather than a posts.html and a posts folder would likely be a more resilient design for cleanblog. On the other hand, this is a funky issue caused by IIS insisting on putting a trailing slash on paths that point to folders even before the rewrite rules hit. I think it would probably be sufficient to have an issue in the cleanblog repo that warns people of the issue when hosting on IIS and suggests the alternative rewrite rules.

[daveaglick]

Cool - that's how I'll proceed for now if for no other reason than it's easy and I've been trying to focus on shipping Statiq Docs with what little time I've got. I'll leave this issue open to remind me to add something to the main docs as well.

I also opened issues for changing the CleanBlog files and implementing an analyzer for this situation - I think both are good ideas as time allows.

Thanks!

[chucker]

The rewrite rules do seem to be working for me at the moment but I have not tested extensively.

Hm, interesting. On my machine (Windows Server 2019 / IIS 10), your changed web.config showed the same phenomenon for me. Individual posts work, but the tags and posts URLs throw a 404.

Shoving the posts.html/tags.html inside their folder as index.html each did the trick.

[darrelmiller]

Yeah, I also discovered the issue with tags. Although for some strange reason posts are working for me.