Extensionless feed paths

[sonicdoe]

For example, if you set the feed path to feed, /feed will return a Content-Type of application/octet-stream (instead of text/xml).

We could automatically place the feed in an index.xml (for example, /feed/index.xml) so the server sends the correct content type. Alternatively, we could document the index.xml workaround in the Already have a feed path? section.

See also #112 (more or less a duplicate).

[benbalter]

One concern I'd have with the "automatic" route, is that users may write /feed and want /feed (an extension-less file), or may enter /feed, but really want /feed/ (which would be /feed/index.xml). This is confusion we already see in Jekyll core. Given that plus the added complexity to implement, my vote would be the documentation route.

[sonicdoe]

Having feed generate feed/index.xml is comparable to Jekyll’s own behavior: about.md actually generates about/index.html (which is available under /about, /about/, and /about/index.html).

The only concern I have with the documentation route is that it’d (still) be possible to serve an invalid feed without really being aware of it. For example, /feed with a Content-Type of application/octet-stream might work with one feed reader but certainly won’t work with every feed reader.

[pathawks]

Alternatively, we could document the index.xml workaround in the Already have a feed path? section.

I think this might be the way to go. If I have configured my server to serve the proper mime type for /feed, then this plugin should not force me to instead use /feed/index.xml