5 ms·

I think it's unfortunate to not have headers as part of the client request and/or server response. I think headers can add a lot of extensibility and future pro

I think it's unfortunate to not have headers as part of the client request and/or server response. I think headers can add a lot of extensibility and future proofing for use cases that can't be anticipated now. Especially when the culture and/or inspiration of the protocol is oriented to hobbyists. e.g. Using spartan protocol as inspiration [1], a client upload request could potentially be: example.com /upload/africa.mp3 3145728 1 <CRLF> Content-Type: audio/mp3 <CRLF> <binary stream> Where the "1" in the request line stands for one header to follow. Or maybe it's just not needed at all, assuming you like HTTP's line break between headers and message body. This borrows from HTTP a bit, but other approaches could be viable of course. But this would give the protocol much more extensibility and allow more freedom for inspired implementations. [1] http://portal.mozz.us/gemini/spartan.mozz.us/examples.gmi http://portal.mozz.us/gemini/spartan.mozz.us/examples.gmi

zzo38computer 2y ago
Molerat protocol allows headers too; it is intended to be another "small web" protocol, but with headers and with a much more complicated file format. However, I think it is badly designed in many ways.
geocar 2y ago
I don't know how I feel about other headers, but I don't like using a Content-Type header since it can disagree with the binary stream, and this has historically been a place to hide bugs.
- teddyh 2y ago
  A binary stream can be multiple formats at once. An out-of-band content-type is the only workable solution; auto-detection of file formats (a.k.a. ”sniffing”) has has a terrible security record.
  - geocar 2y ago
    > A binary stream can be multiple formats at once So what? If Spartan doesn't do anything with them, it can save them to the disk: It doesn't need to know the difference between a zipfile and an xlsx sheet in order to do so. > An out-of-band content-type is the only workable solution Solution to what? I don't think "more metadata" solves anything, let alone security problems. An "out-of-band content type" declaration is just that: an unsubstantiated claim as to a valid interpretation of the bytes-in-question. Using a buggy png parser just because some other layer said it was "image/png" is where the security problems are. > auto-detection of file formats (a.k.a. ”sniffing”) has has a terrible security record. The single biggest source of security problems is code you don't need: Fix whatever program you've got that can't tolerate random bytes from the Internet, or don't give those programs random bytes you get from the Internet.
    - immibis 2y ago
      Do you never want to see a file in the browser?
    - teddyh 2y ago
      > Using a buggy png parser just because some other layer said it was "image/png" is where the security problems are. If your PNG parser is buggy, you have bigger problems. > Fix whatever program you've got that can't tolerate random bytes from the Internet Like your PNG parser?
    - thephyber 2y ago
      The underlying problem you are describing is the spirit of the web browser. It has been designed to be extremely resilient to sloppy / wrong coding. This is the reason JavaScript has weird features like Automatic Semicolon Insertion and why every browser tolerates sloppy HTML markup (even though they don’t clean it up in the same ways).

zzo38computer 2y ago

Molerat protocol allows headers too; it is intended to be another "small web" protocol, but with headers and with a much more complicated file format. However, I think it is badly designed in many ways.

geocar 2y ago

I don't know how I feel about other headers, but I don't like using a Content-Type header since it can disagree with the binary stream, and this has historically been a place to hide bugs.

teddyh 2y ago
A binary stream can be multiple formats at once. An out-of-band content-type is the only workable solution; auto-detection of file formats (a.k.a. ”sniffing”) has has a terrible security record.
- geocar 2y ago
  > A binary stream can be multiple formats at once So what? If Spartan doesn't do anything with them, it can save them to the disk: It doesn't need to know the difference between a zipfile and an xlsx sheet in order to do so. > An out-of-band content-type is the only workable solution Solution to what? I don't think "more metadata" solves anything, let alone security problems. An "out-of-band content type" declaration is just that: an unsubstantiated claim as to a valid interpretation of the bytes-in-question. Using a buggy png parser just because some other layer said it was "image/png" is where the security problems are. > auto-detection of file formats (a.k.a. ”sniffing”) has has a terrible security record. The single biggest source of security problems is code you don't need: Fix whatever program you've got that can't tolerate random bytes from the Internet, or don't give those programs random bytes you get from the Internet.
  - immibis 2y ago
    Do you never want to see a file in the browser?
  - teddyh 2y ago
    > Using a buggy png parser just because some other layer said it was "image/png" is where the security problems are. If your PNG parser is buggy, you have bigger problems. > Fix whatever program you've got that can't tolerate random bytes from the Internet Like your PNG parser?
  - thephyber 2y ago
    The underlying problem you are describing is the spirit of the web browser. It has been designed to be extremely resilient to sloppy / wrong coding. This is the reason JavaScript has weird features like Automatic Semicolon Insertion and why every browser tolerates sloppy HTML markup (even though they don’t clean it up in the same ways).