You act like "no access" can't happen because other things break. If that was the only choice, I'd consider it, but I'm not going to give up everything in tiny incremental bits to maximize access in every edge case.

Also you could disable expiration as a much safer measure.

There are many reasons something can break. I'm not sure how you got the impression I believe otherwise.

There are many reasons someone may not be able to access.

Furthermore, some of those reasons can be known ahead of time, and some cannot even be predicted before they happen.

But the ones I do know of, I try to accommodate, just like i try to accommodate visually impaired, those with slow devices, etc.

And I have found that the more known scenarios I accommodate, the more unknown scenarios are also accommodated, just from raising the accessibility bar.

Of course, this is not something everyone cares about. You probably won't gain many profitable customers with deep pockets accommodating the edge cases. They're all using the latest and greatest.

But if you care about allowing access to as many as possible to your resource, serving both HTTP and HTTPS is the way.

> I'm not sure how you got the impression I believe otherwise.

It's the impression your post gives. Either I pick insecurity -or- it breaks.

The real version is I pick insecurity -or- the number of ways it can break goes from 73 to 74.

And I care about accessibility too. That doesn't mean I indiscriminately want to increase access. The downsides of certain methods are important.