Deployed a demo: https://datasette-optional-hash-demo.now.sh/

datasette publish now \
    ../demo-databses/russian-ads.db \
    ../demo-databses/polar-bears.db \
    --branch=optional-hash \
    -n datasette-optional-hash \
    --alias datasette-optional-hash-demo \
    --install=datasette-cluster-map \
    --install=datasette-json-html

Still TODO: need to figure out what to do about cache TTL. Defaulting to 365 days no longer makes sense without the hash_urls setting.

Maybe drop that setting default to 0?

Here's the setting:

And here's where it takes affect:

Also: if the option is False and the user visits a URL with a hash in it, should we redirect them?

I'm inclined to say no: furthermore, I'd be OK continuing to serve a far-future cache header for that case.

This also needs extensive tests to ensure that with the option turned on all of the redirects behave as they should.

See #418

I'm going to introduce a new config setting: default_cache_ttl_hashed - and set the default value for default_cache_ttl to 10s (to protect against dog-piling).

The code for this has got a bit tricky. I need to make a decision at some point as to if the current request is a hashed_url request (if it includes a DB hash in the URL which is the current correct hash). I then need to be able to use that fact to decide which default TTL value to apply when returning the response.

Since this feature is now controlled by a config setting, I'm inclined to make it also available via a URL parameter.

If you hit this URL:

/fixtures/table.json?_hash=1

We can redirect to:

/fixtures-c2342/table.json

In this way developers can opt-in to a hashed (and hence far-future cached) response on a per-query basis.

This option won't be available against mutable databases though, which are coming in #419

This means that the hash_urls:1 config basically has the effect of assuming ?_hash=1 on all URLs to mutable databases.