Static site hosting hurdles

> fasthttp doesn't implement HTTP/1 correctly

Could you point to an issue describe such an improper behavior?

> doesn't implement HTTP/2 at all

Or HTTP/3; and most likely it won't implement HTTP/4 (after the HTTP/3 fashion dies out). There is an issue about this on `fasthttp`'s repository: https://github.com/valyala/fasthttp/issues/144>

And I'll quote here what I've said there:

> Having experimented in my kawipiko static server based on fasthttp with both HTTP/2 (based on the Go's implementation) and HTTP/3 (based on an experimental available library), I continue to believe that perhaps HTTP/2 and HTTP/3 is a job for some other component of the infrastructure, be it a CDN or even a local HTTP router / load-balancer such as HAProxy.

Thus if one needs HTTP/2 or HTTP/3 in order to reap their performance benefits, then using a CDN that actually supports these is the best approach.

If you're ok with using Cloudflare's free plan for your DNS, you can stop paying for each hosted zone.

>It's like some UI designer didn't understand folders,

He probably didn't.

[the author here] Indeed didn't mention anything about the shared webhosting solutions, just as I didn't mention anything about S3 + CloudFront, or Backblaze B2 + a CDN in front, or Cloudflare + WebWorkers, or AWS Lambda, or any other thousand ways to do it... (Like for example there is https://redbean.dev/> which I find just so intriguing, and not far from my own https://github.com/volution/kawipiko> proposal.)

Although shared webhosting is part of our web history -- and still a viable choice especially if you have something in PHP or something that requires a little-bit of dynamic content -- I don't think it's still a common choice for today.

It's somewhere in between dedicated cloud-hosting, because although you have an actual HTTP server (usually Apache or Nginx) that you can't configure it much because it's managed by the provider, thus it gives you the same features (and limitations) as an a proper cloud-hosted static site solution (such as Netlify); and between self-hosting because of the same reasons, having an actual full-blown HTTP server, but one you can't fully control, thus it gives you fewer features than a self-managed VM in a cloud provider or self-hosted machine. Thus unless you need PHP, or `htaccess`, I think the other two alternatives make a better choice.

The issue with "static sites", due to the de-facto requirements in 2022 imposed by the the internet "gatekeepers" (mainly search engines), is that they aren't "just a bunch of files on disk that we can just serve with proper `Content-Type`, `Last-Modified` or `ETag`, and perhaps compressed"; we now need (in order to meet the latest hoops the gatekeepers want us to jump through) to also do a bunch of things that aren't quite possible (or certainly not easily) with current web servers. For example:

* minification (which I've cited in my article) -- besides compression, one should also employ HTML / CSS / JS and other asset minification; none of the classical web servers support this; there is something like https://www.modpagespeed.com/>, but it's far from straightforward to deploy (let alone on a shared web-host;)

* when it comes to headers (be it the ones for CSP and other security related ones) or even `Link` headers for preloading, these aren't easy to configure, especially if you need those `Link` headers only for some HTML pages and not all resources; in this regard I don't know how many shared webhosts actually allow you to tinker with these;

The point I was trying to make is that if you want to deploy a professional (as in performant) static web site, just throwing some files in a folder and pointing Apache or Nginx at them isn't enough. If the performance you are getting by default from such a setup is enough for you, then perfect! If not there is a lot of pain getting everything to work properly.

> Strong disagree. You do not want both URLs to return the same content; you can have alternatives redirect to the canonical URL; but think through why you’re doing it: who is benefited by the redirect?

At least with regard the with/without slash redirects there is value in these: sometimes the user copy-pastes the URL but forgets the final slash, sometimes the application he is using for bookmarking, sharing, etc. drops the slash; sometimes even the site owner forgets be consistent. Thus having those redirects in place means not having dead links pointing to your site.

With regard the `.html`, with and without, it's a matter of taste... However, the same point applies, perhaps you've been inconsistent along the years, thus having redirects saves the dead links...

However you are right about the "canonical" URL: for search engine purposes, having a single page serving the content, and the rest being redirects, is kind of essential. (Or at least having a `` if not a redirect.)

> Supporting more things for the sake of it is not a virtue. There is value in failing early on incorrect input. Postel was wrong.

It is when you don't want dead links. :)