Is streaming a normative protocol expectation? (was Re: Documents with mixed languages)

[Sean Conner]

It was thus said that the Great Luke Emmet once stated:
> Hello
> 
> On 13-Dec-2021 19:10, Sean Conner wrote:
> >
> >   If you receive a MIME type of "audio/*", "video/*" or 
> >   "text/event-stream"
> >[1], then you probably would want to stream the data or expect to spend
> >some time downloading the entire content (or abort entirely if you get
> >"text/event-stream").
> 
> Although strictly speaking according to the workflow described in the 
> spec, you might validly not know the media type until *after* you have 
> received the response, the connection is closed, then you have processed 
> the response :)

  I think you are talking about this from the specification: [1]

C:   Opens connection
S:   Accepts connection
C/S: Complete TLS handshake (see section 4)
C:   Validates server certificate (see 4.2)
C:   Sends request (one CRLF terminated line) (see section 2)
S:   Sends response header (one CRLF terminated line), closes connection
     under non-success conditions (see 3.1 and 3.2)
S:   Sends response body (text or binary data) (see 3.3)
S:   Closes connection (including TLS close_notify, see section 4)
C:   Handles response (see 3.4)

  Yes, it's easier for a client to implement this as shown above---read all
the input, then handle it.  But things can go wrong for a variety of reasons
(bugs, malicious intent) so clients should be able to deal with a server
that doesn't close the connection (or the connection is so slow that it's
preferrable for the client to abort the transaction) and the server should
be able to deal with a client that closes the connection before it does. 

  Now strictly speaking, the client knows the MIME type as soon as it gets
the response header.  How the client deals with the response body (see 3.3
and 3.4) is up to the client.

  Yes, I get the complaint about having to read anciliary sources to
"properly" implement the protocol (my biggest beef---not many bot writers
have bothered reading the "best practices" document sitting along side the
specification [2]), but as I mentioned above, there are a ton of corner
cases that need to be considered when implementing the protocol that aren't
mentioned in either document (like text with no whitespace---how do you deal
with formatting?).  

  -spc

[1]	gemini://gemini.circumlunar.space/docs/specification.gmi

[2]	gemini://gemini.circumlunar.space/docs/best-practices.gmi