Caching and sizes, the explosion of responise codes (was Re: Caching and status codes)

On Mon, Nov 9, 2020 at 4:33 PM Sean Conner <sean at conman.org> wrote:


> The major problem here is timezones.  Time zone information is
> complicated, and from what I've seen, operating system specific (the C
> standard doesn't mention it; POSIX does it one way; Windows another) so
> that's a complication for both servers and clients.
>

ISO 8601 doesn't use named timezones, only offsets, but the best policy is
to do everything in UTC, which is pretty universally available on all
operating systems now.  It's perfectly fine to just write
"2020-11-09T22:14:05Z".


> Also, does the concept apply to each path component?  Or only the end?
>

I would say "The end", but I would write it as a query term:  gemini://
example.com/test?since=2020-11-09T22:14:05Z.  After all, the path elements
aren't necessarily actual objects with modification dates (in Amazon S3,
for example, they are just part of the name).

In addition, you could use the "inode/x-empty" MIME-type instead of a
different protocol response.

But, like you, I doubt this is worth doing.  Servers should advise clients
about whether the author thinks the result should be cached, and clients
can do what they like about it.  (There are any number of ways for the
author to communicate this intent; it doesn't have to be part of the
content.)



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
I am expressing my opinion.  When my honorable and gallant friend is
called, he will express his opinion.  This is the process which we
call Debate.                   --Winston Churchill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/e355
08dc/attachment.htm>

---

Previous in thread (53 of 55): 🗣️ Sean Conner (sean (a) conman.org)

Next in thread (55 of 55): 🗣️ Jason McBrayer (jmcbray (a) carcosa.net)

View entire thread.