In my opinion, a minimal proposition would not even contain the implementation of the {Put,Get,Delete}BucketWebsite endpoints, and only allow configuration using the command line interface. This is currently what we are doing to create buckets and configure access keys (we don't have PutBucket or such). This requires manual intervention for the configuration of every new website, however given the small numbers of website hosted on Deuxfleurs, this is probably an acceptable cost to begin with.
Exposing API endpoints that allowe the user to create or configure buckets should be a separate issue. We probably need more thought as to what permission model we want to implement before we do that.
So my plan for a minimal implementation would only be:
- add a bit in the bucket table that says whether that bucket is exposed as a website
- add a CLI command to set that bit
- create an endpoint for public website access for buckets that have that bit enabled, using the Host: header to read from the correct bucket, if we decide that our convention is that the bucket name must match the domain name of the website
Alternatively, a 1-indirection-layer option exists: use a separate table to store website configuration, so that website host names do not need to match bucket names, and several website host names can be served by the same bucket.
Suggested architecture: open a third end point (HTTP server) only for anonymous/public access to buckets configured to serve as static websites. This would allow to clearly distinguish the semantics of the S3 API (read/write/list files/etc, authentified) and of the public website access (read only, no auth).