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

On Sun, 8 Nov 2020 00:50:18 -0500
Sean Conner <sean at conman.org> wrote:

> It was thus said that the Great khuxkm at tilde.team once stated:
> > 
> > This can't happen, though, because the first proposal breaks the
> > compatibility of <META> in response codes within a block, and the second
> > one is just debating which of the codes we should add.
> 
>   This *did* happen, back on November 3rd.  
> 
> 	gemini://gemi.dev/gemini-mailing-list/messages/003015.gmi
> 
>   And it's already received over a hundred hits.

You're mistaking the sense in which khuxkm is saying that it can't
happen. It did happen in the sense that you implemented a server for a
protocol that works like this.

It can't happen in the sense that it fundamentally breaks compatibility
with clients that only concern themselves with the first digit of the
response code. That you've implemented the resulting protocol of your
suggested change has no bearing on the argument.

The overflowing of 2x code resulting from a combinatorial hell is
entirely self-inflicted through your choice to ignore this aspect of
the existing specification.

I've already suggested to you a way to avoid this (use a different
first digit). This additionally avoids having to rewrite 3.2 of the
spec and invalidate existing clients that take for granted that "the
first digit alone provides enough information for a client to determine
how to handle the response".

Moreover, with TLS already having a mechanism to signal the intended
end of a connection, I don't think that content size is a pressing
issue. It would allow for download progress bars, but adds nothing
over TLS in terms of ensuring that the content is fully received.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201108/213b
a640/attachment.sig>

---

Previous in thread (36 of 55): 🗣️ boringcactus (boringcactus (a) gmail.com)

Next in thread (38 of 55): 🗣️ Ali Fardan (raiz (a) stellarbound.space)

View entire thread.