Comment by 🚀 stack
Re: "Without headers, there is no way to detect if document…"
Hmm. That is not bad.
13 hours ago
7 Later Comments ↓
I see a lot of criticism of TLS, but it is more important for integrity than it is for confidentiality. It seems there are a lot of people here who do not remember the days that ISPs (and others) would insert stuff into html pages in the pre-TLS era. Would this happen to geminispace? Probably not because it's a small fish, but anyone sitting on the wire between you and any non-TLS server has the opportunity.
I would also like to make a note that base64-encoding can be used to largely avoid the conflicts with the URL spec without needing to percent-encode everything. It requires support from both server and client but the mechanism is there.
It seems there are a lot of people here who do not remember the days that ISPs (and others) would insert stuff into html pages in the pre-TLS era.
hm, you have a point - I definitively forgot about this..
Never happened to me.
I agree that TLS should be optional instead of mandatory. I also agree that the header should have an optional size (it should not be mandatory, since sometimes it might not be known e.g. in case of dynamic files). Spartan uses the file format of Gemini but it is a different protocol (although it is probably not a problem if you do not have any dynamic files). I made up the Scorpion which avoids these problems.
About Kepler: One thing I think that Unicode should not be the only character set and that it is not a very good character set, but there are other things to mention.\
3.4: I think that it should not be recommended to redirect from the non-TLS to the TLS or vice-versa (although it might if a client certificate is required; Scorpion instead implicitly does when a 6x response is received but you might prefer to do it differently, especially since the port number might be different for Kepler).
4.1: I agree with 4.1.2. About 4.1.3, I think the MANDATORY warning is unnecessary if the user knows what they are doing (although your intention might be that they don't know, I would think it is better otherwise).
4.2, 4.3, and 4.4 are good.
4.5.2: There might sometimes be situations where this does not work, e.g. if the request must be forwarded to multiple servers (which might or might not be on the same computer), or where the server might have different certificates for different domain names, etc. One possible consequence of this is that client certificates cannot be accepted if the SNI is incorrect. Some servers won't need to care about SNI, but some will need to care for the reasons I specified.
4.5.3: This section is incorrectly numbered as 4.5.2. Maybe it should say SHOULD instead of MAY, although I am not sure and I might be wrong.
4.2.2: I have another comment I forgot to mention. Some files on some servers might potentially require certificates issued by a specific authority, such as the server itself. However, this is not always the case; often, self-signed certificates are good enough. For clients accepting server certificates, this is also sometimes the case, although it would have to depend on an agreement made ahead of time, which usually is not the case.
🚀 lars_the_bear · 3 hours ago:
@zzo38: Thank you. It would be great if you could add your remarks to the GitHub repository, or give me permission to do it myself. I'd like to track these things in a central place.
@fstfabi : I'm not sure I'd go along with that. The problem is that it amounts to extending the specification by stealth. You could add anything in the position you suggest including, Heavens forefend, cookies.
@lars_the_bear What I am writing is public domain, so you are free to copy it (or a part of it) to the GitHub repository if you want to do.
@fstfabi I think you are not supposed to use MIME parameters like that, even though it might work (and in my opinion, MIME type is not that good anyways and has some problems, which is why I made ULFI (although ULFI is a bit more complicated in some ways, I think it is not too complicated (especially compared with WWW, etc)); they tried to solve some of these issues in MIME too but it doesn't work so well in my opinion).
I think it's time to use Gopher in multi-network context (such as ygg, i2p, etc.) where the traffic already encrypted and I'm not worrying about ISP injections.
Original Post
Without headers, there is no way to detect if document exist: for example, zip archive is always downloading with 9 bytes of size. Yet another problem: even the protocol is Unicode oriented, URL-encoded links are unuseful. Madness! I need Gemini without TLS just.