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 have resumable downloads, so it's either that or retry, and I think you should leave retrying up to the user. For text, you can show what you have, and leave it to the user to decide if they got the full document or 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 |
---
Previous in thread (14 of 16): 🗣️ Solderpunk (solderpunk (a) posteo.net)
Next in thread (16 of 16): 🗣️ colecmac (a) protonmail.com (colecmac (a) protonmail.com)