5 ms·

> then AFAICT there's no way to tell that the server is done sending the file." This is incorrect. See https://gemini.circumlunar.space/docs/specification.html

by geocar 4y ago

> then AFAICT there's no way to tell that the server is done sending the file." This is incorrect. See https://gemini.circumlunar.space/docs/specification.html https://gemini.circumlunar.space/docs/specification.html section 4: As per RFCs 5246 and 8446, Gemini servers MUST send a TLS `close_notify` prior to closing the connection after sending a complete response. This is essential to disambiguate completed responses from responses closed prematurely due to network error or attack. > There is no version number in the protocol, and the response layout was carefully constructed to make extending it hard I think if you want HTTP, you should use HTTP.

woodruffw 4y ago
I don’t believe this addresses the point: the fact that the server sends a close notification right before hanging up doesn’t help a client determine whether a particular stream just hasn’t finished loading yet or is potentially infinite/undesireably large/hung instead of temporarily paused. You have to “want” HTTP to apply some of the basic lessons in protocol design that we’ve learned over the last 70 years. Sending payload sizes upfront (when available) is generally a great idea.
- geocar 4y ago
  > the fact that the server sends a close notification right before hanging up doesn’t help a client determine whether a particular stream just hasn’t finished or is potentially infinite/undesireably large/hung instead of temporarily paused. Of course it does. The client receives close_notify and they know the stream is complete. If they don't get it, it wasn't. Simples. You're thinking of HTTP which does have this limitation (if not using an extension like chunked-transfer, multipart, or more popularly: TLS/https). > You have to “want” HTTP to apply some of the basic lessons in protocol design that we’ve learned over the last 70 years. Nonsense. > Sending payload sizes upfront (when available) is generally a great idea. There are lots of great ideas out there, but if you implement all of them you get the Homer-mobile. Do not let yourself worry so much about the goodness of the idea and instead think about what you get and how much it costs: Requiring fixed-length payloads would cost you streaming, whilst making them optional means you have to write both code to support them and code that tolerates their absence -- back where you started. To know whether or not it would be worth it you'd need to ask the Gemini users.
  - deleted 4y ago
    [deleted]
- jl6 4y ago
  > hasn’t finished loading yet or is potentially infinite/undesireably large/hung For the case of a hung connection, is there any great cost to a client just keeping the connection open indefinitely? We’re talking a few kilobytes of memory? The user will surely close the client before it matters. I can see some value in signalling the content length in order to allow a client to display a progress bar for a large download. But I can totally live without that in exchange for a simpler design.

by geocar 4y ago

woodruffw 4y ago

I don’t believe this addresses the point: the fact that the server sends a close notification right before hanging up doesn’t help a client determine whether a particular stream just hasn’t finished loading yet or is potentially infinite/undesireably large/hung instead of temporarily paused. You have to “want” HTTP to apply some of the basic lessons in protocol design that we’ve learned over the last 70 years. Sending payload sizes upfront (when available) is generally a great idea.

geocar 4y ago
> the fact that the server sends a close notification right before hanging up doesn’t help a client determine whether a particular stream just hasn’t finished or is potentially infinite/undesireably large/hung instead of temporarily paused. Of course it does. The client receives close_notify and they know the stream is complete. If they don't get it, it wasn't. Simples. You're thinking of HTTP which does have this limitation (if not using an extension like chunked-transfer, multipart, or more popularly: TLS/https). > You have to “want” HTTP to apply some of the basic lessons in protocol design that we’ve learned over the last 70 years. Nonsense. > Sending payload sizes upfront (when available) is generally a great idea. There are lots of great ideas out there, but if you implement all of them you get the Homer-mobile. Do not let yourself worry so much about the goodness of the idea and instead think about what you get and how much it costs: Requiring fixed-length payloads would cost you streaming, whilst making them optional means you have to write both code to support them and code that tolerates their absence -- back where you started. To know whether or not it would be worth it you'd need to ask the Gemini users.
- deleted 4y ago
  [deleted]
jl6 4y ago
> hasn’t finished loading yet or is potentially infinite/undesireably large/hung For the case of a hung connection, is there any great cost to a client just keeping the connection open indefinitely? We’re talking a few kilobytes of memory? The user will surely close the client before it matters. I can see some value in signalling the content length in order to allow a client to display a progress bar for a large download. But I can totally live without that in exchange for a simpler design.