💾 Archived View for rawtext.club › ~sloum › geminilist › 002173.gmi captured on 2020-09-24 at 01:23:05. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Jason McBrayer jmcbray at carcosa.net
Fri Jul 10 14:01:19 BST 2020
- - - - - - - - - - - - - - - - - - -
juhani <juhani at envs.net> writes:
I'm juhani, new here, and implementing an Android gemini client.
Hi, juhani!
While testing with live sites for the first time I found that some sites worked,
and on others the response handling hung. Comparison of tcp streams revealed
that on the working sites the last packet from the server had FIN flag, and on
the failing sites it didn't.
Can you tell us what server software the failing sites are running?Probably the most helpful thing is to get those servers fixed.
I changed the client so it doesn't try to read the whole response before parsing
the header. And added timeout to make sure the connection is closed.
That also sounds reasonable; just don't make the timeout *too* short.
These changes make sense to me, but what should the client do if it cant be sure
it has the complete payload? With line based content it's possible to show what
you've got. The clients I've tried, so far, seem to do that, but is it correct?
And what about binary content?
For binary files, I'd say treat it as an error; Gemini doesn't haveresumable downloads, so it's either that or retry, and I think youshould leave retrying up to the user. For text, you can show what youhave, and leave it to the user to decide if they got the full documentor not, I guess...
-- +-----------------------------------------------------------+| Jason F. McBrayer jmcbray at carcosa.net || A flower falls, even though we love it; and a weed grows, || even though we do not love it. -- Dogen |