Working around implementation quirks

[coleman]

Even with a simple protocol, clients will need to make decisions around
handling things gracefully to give users a good experience. The network
is fundamentally unreliable, after all!

Maybe in these early days client authors can help the community by
exposing debug logs. Kind of like when you open dev tools in a browser
and you can see warnings for protocol violations or errors.

Coleman

On Wed, Jun 24, 2020 at 10:21:12PM +0000, Case Nelson wrote:
> I worked around it, I found that mozz.us closed the connection properly if I sent a no_write shutdown signal from my side. But doing that on tilde.black caused them to close the connection and not send a response. It happened regardless of redirects as far as I paid attention to that aspect.
> 
> So, I send the signal, and if I get no response I make the request again without the signal and wait for a timeout... Pretty gross and I'll need to change it eventually since it's no fair to the operators.
> 
> As implementers tho, I wonder if we shouldn't be working around problems like this (assuming it's on the other side). Should we be strict with out of spec implementations? I feel that the attitude of trying to parse bad html and weird headers is partially what led to the mess in the web early on... But if some clients start working around that stuff, then ones that don't will be considered broken.
> 
> Jun 24, 2020 2:26:12 PM Sean Conner <sean at conman.org>:
> 
> > It was thus said that the Great colecmac at protonmail.com once stated:
> >> Happy to see an update!
> >> 
> >> I may have had a related issue, I remember having trouble with redirects
> >> on tilde.black and gemini.conman.org. In the end the issue was that they
> >> were closing *right after* sending the redirect, I think, and I wasn't
> >> capturing the last few bytes. But I was using Go, not Flutter, so I'm not
> >> sure how much this helps.
> > 
> > How did you fix the issue?  Or did you?
> > 
> > -spc
> > 

-- 

~coleman