initial commit
This commit is contained in:
commit
d9e5170676
11 changed files with 968 additions and 0 deletions
2
.gitattributes
vendored
Normal file
2
.gitattributes
vendored
Normal file
|
|
@ -0,0 +1,2 @@
|
||||||
|
.gitattributes export-ignore
|
||||||
|
.gitignore export-ignore
|
||||||
1
.gitignore
vendored
Normal file
1
.gitignore
vendored
Normal file
|
|
@ -0,0 +1 @@
|
||||||
|
/target
|
||||||
98
Cargo.lock
generated
Normal file
98
Cargo.lock
generated
Normal file
|
|
@ -0,0 +1,98 @@
|
||||||
|
# This file is automatically @generated by Cargo.
|
||||||
|
# It is not intended for manual editing.
|
||||||
|
[[package]]
|
||||||
|
name = "autocfg"
|
||||||
|
version = "1.0.0"
|
||||||
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||||
|
checksum = "f8aac770f1885fd7e387acedd76065302551364496e46b3dd00860b2f8359b9d"
|
||||||
|
|
||||||
|
[[package]]
|
||||||
|
name = "bitflags"
|
||||||
|
version = "1.2.1"
|
||||||
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||||
|
checksum = "cf1de2fe8c75bc145a2f577add951f8134889b4795d47466a54a5c846d691693"
|
||||||
|
|
||||||
|
[[package]]
|
||||||
|
name = "cc"
|
||||||
|
version = "1.0.53"
|
||||||
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||||
|
checksum = "404b1fe4f65288577753b17e3b36a04596ee784493ec249bf81c7f2d2acd751c"
|
||||||
|
|
||||||
|
[[package]]
|
||||||
|
name = "cfg-if"
|
||||||
|
version = "0.1.10"
|
||||||
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||||
|
checksum = "4785bdd1c96b2a846b2bd7cc02e86b6b3dbf14e7e53446c4f54c92a361040822"
|
||||||
|
|
||||||
|
[[package]]
|
||||||
|
name = "foreign-types"
|
||||||
|
version = "0.3.2"
|
||||||
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||||
|
checksum = "f6f339eb8adc052cd2ca78910fda869aefa38d22d5cb648e6485e4d3fc06f3b1"
|
||||||
|
dependencies = [
|
||||||
|
"foreign-types-shared",
|
||||||
|
]
|
||||||
|
|
||||||
|
[[package]]
|
||||||
|
name = "foreign-types-shared"
|
||||||
|
version = "0.1.1"
|
||||||
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||||
|
checksum = "00b0228411908ca8685dba7fc2cdd70ec9990a6e753e89b6ac91a84c40fbaf4b"
|
||||||
|
|
||||||
|
[[package]]
|
||||||
|
name = "lazy_static"
|
||||||
|
version = "1.4.0"
|
||||||
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||||
|
checksum = "e2abad23fbc42b3700f2f279844dc832adb2b2eb069b2df918f455c4e18cc646"
|
||||||
|
|
||||||
|
[[package]]
|
||||||
|
name = "libc"
|
||||||
|
version = "0.2.70"
|
||||||
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||||
|
checksum = "3baa92041a6fec78c687fa0cc2b3fae8884f743d672cf551bed1d6dac6988d0f"
|
||||||
|
|
||||||
|
[[package]]
|
||||||
|
name = "openssl"
|
||||||
|
version = "0.10.29"
|
||||||
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||||
|
checksum = "cee6d85f4cb4c4f59a6a85d5b68a233d280c82e29e822913b9c8b129fbf20bdd"
|
||||||
|
dependencies = [
|
||||||
|
"bitflags",
|
||||||
|
"cfg-if",
|
||||||
|
"foreign-types",
|
||||||
|
"lazy_static",
|
||||||
|
"libc",
|
||||||
|
"openssl-sys",
|
||||||
|
]
|
||||||
|
|
||||||
|
[[package]]
|
||||||
|
name = "openssl-sys"
|
||||||
|
version = "0.9.56"
|
||||||
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||||
|
checksum = "f02309a7f127000ed50594f0b50ecc69e7c654e16d41b4e8156d1b3df8e0b52e"
|
||||||
|
dependencies = [
|
||||||
|
"autocfg",
|
||||||
|
"cc",
|
||||||
|
"libc",
|
||||||
|
"pkg-config",
|
||||||
|
"vcpkg",
|
||||||
|
]
|
||||||
|
|
||||||
|
[[package]]
|
||||||
|
name = "pkg-config"
|
||||||
|
version = "0.3.17"
|
||||||
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||||
|
checksum = "05da548ad6865900e60eaba7f589cc0783590a92e940c26953ff81ddbab2d677"
|
||||||
|
|
||||||
|
[[package]]
|
||||||
|
name = "sheldon_director"
|
||||||
|
version = "0.1.0"
|
||||||
|
dependencies = [
|
||||||
|
"openssl",
|
||||||
|
]
|
||||||
|
|
||||||
|
[[package]]
|
||||||
|
name = "vcpkg"
|
||||||
|
version = "0.2.8"
|
||||||
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||||
|
checksum = "3fc439f2794e98976c88a2a2dafce96b930fe8010b0a256b3c2199a773933168"
|
||||||
9
Cargo.toml
Normal file
9
Cargo.toml
Normal file
|
|
@ -0,0 +1,9 @@
|
||||||
|
[package]
|
||||||
|
name = "sheldon_director"
|
||||||
|
version = "0.1.0"
|
||||||
|
authors = ["Klockenschooster <slartibartfast@klockenschooster.de>"]
|
||||||
|
edition = "2018"
|
||||||
|
|
||||||
|
[dependencies]
|
||||||
|
openssl = { version = "0.10" }
|
||||||
|
|
||||||
20
LICENSE.md
Normal file
20
LICENSE.md
Normal file
|
|
@ -0,0 +1,20 @@
|
||||||
|
Copyright (c) 2020 Jan Wolff
|
||||||
|
|
||||||
|
This software is provided 'as-is', without any express or implied warranty. In
|
||||||
|
no event will the authors be held liable for any damages arising from the use
|
||||||
|
of this software.
|
||||||
|
|
||||||
|
Permission is granted to anyone to use this software for any purpose, including
|
||||||
|
commercial applications, and to alter it and redistribute it freely, subject to
|
||||||
|
the following restrictions:
|
||||||
|
|
||||||
|
1. The origin of this software must not be misrepresented; you must not claim
|
||||||
|
that you wrote the original software. If you use this software in a product,
|
||||||
|
an acknowledgment in the product documentation would be appreciated but is
|
||||||
|
not required.
|
||||||
|
|
||||||
|
2. Altered source versions must be plainly marked as such, and must not be
|
||||||
|
misrepresented as being the original software.
|
||||||
|
|
||||||
|
3. This notice may not be removed or altered from any source distribution.
|
||||||
|
|
||||||
10
README.md
Normal file
10
README.md
Normal file
|
|
@ -0,0 +1,10 @@
|
||||||
|
Sheldon Director
|
||||||
|
================
|
||||||
|
|
||||||
|
A Gemini Server written in Rust.
|
||||||
|
|
||||||
|
Why "Sheldon Director"?
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
Because it is the real name of that villain in _Kim Possible_ who went by the
|
||||||
|
pseudonym "Gemini". (https://kimpossible.fandom.com/wiki/Gemini)
|
||||||
32
doc/cert.pem
Normal file
32
doc/cert.pem
Normal file
|
|
@ -0,0 +1,32 @@
|
||||||
|
-----BEGIN CERTIFICATE-----
|
||||||
|
MIIFlTCCA32gAwIBAgIUPqRiFp5Gc1b2Frbab/WcQ4Xdg74wDQYJKoZIhvcNAQEL
|
||||||
|
BQAwWTELMAkGA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoM
|
||||||
|
GEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDESMBAGA1UEAwwJbG9jYWxob3N0MCAX
|
||||||
|
DTIwMDUxNDE4NDI0NVoYDzIxMjAwNDIwMTg0MjQ1WjBZMQswCQYDVQQGEwJBVTET
|
||||||
|
MBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQ
|
||||||
|
dHkgTHRkMRIwEAYDVQQDDAlsb2NhbGhvc3QwggIiMA0GCSqGSIb3DQEBAQUAA4IC
|
||||||
|
DwAwggIKAoICAQCqDaso0s8+Rt9fILlF7koLcYJCjs+MjB0kpS7itdJj1YXW6a5l
|
||||||
|
zIRP9bMSSftVmHGR1qFo6suKbVEayCkTrw3PU6w7iW7CMiRK6XL1Ix4B5BYEymKx
|
||||||
|
ihA1geRQZkKL8UHfudnpq7+yTqwKXdOu4KrRUbMdIiOlaIhhK4/DZk8gxmZpiv81
|
||||||
|
xqohtyVsr7Z8yKkSoX7TySPvn3qx83BgeoGSqe/pX4quKVKj8ylkfdyKlaVPLGvS
|
||||||
|
ktTfr2rUYtRz1+xOEEYxUdaZBRZ2/G1QaeELWimwPTAmg9KWCfA0/6TWMDvh2Btq
|
||||||
|
J0qJtcu43QVFf4AxoUQ/S/Mf4Zmc/3gfOcEHrjnNube0xaUfMdjErhwPmXKc0E78
|
||||||
|
hd9jlkJaICdGSEC19DZBt8LinyTMr6+2E/YyD+bl+LUL8uI7m9zFgJYlLXUeZvab
|
||||||
|
PvcxUq72pP6/j+9fGlT2JXSZ6bIDXyDbgz0QmZ5Rh+q5fwSAtfkSE16cx87aOM48
|
||||||
|
iI98c4joN9FXAVwNT53ga/dxwCqQZH4Sd024DEeo2Gk5dWyPTUnENcl4vW1Twa70
|
||||||
|
1gY60YqHw5UgH9DnBN+8yWjFHlbL4aZvbLdTsQOCkHMxoTt5vGP2e5XHh0Etk1oK
|
||||||
|
5E7FtXOFJ125PcPZ9BlyyyaKxR9ykpMYNtHJjScQPTlMhku/8aK3sb3eRwIDAQAB
|
||||||
|
o1MwUTAdBgNVHQ4EFgQUWrJXR3N6gnEkBQHACPj0Db+TtoAwHwYDVR0jBBgwFoAU
|
||||||
|
WrJXR3N6gnEkBQHACPj0Db+TtoAwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0B
|
||||||
|
AQsFAAOCAgEAKLhG4+kNvoVCyByrcSUU9rhUZxn1ezAQJcUO3ETZIE1lU1Z46rMk
|
||||||
|
9he4+sPTDxEEoynL8wseAStn+CVVd8Leer5QZEWqwaM+LkcjicYr+U8CNQ1p28Gy
|
||||||
|
oiSH0rK7RzkhRDwmnMYAx9skpem/nLj21RH4gPBUYaW5mU05O4F3vZvWZfwfGJi8
|
||||||
|
MSvPOVUZVUIJZFqNAECKxGbzneO3iKLETnDdAnw2VgLwTcvLfkbtBxbNwEgTgV8+
|
||||||
|
sWbmgTlPX1ToRdL2Gz5pp0hz6B94H0HoUO4yH2Afzb5O6+sKxLoIBq7S8PBURP0A
|
||||||
|
F+mtnU/VWJBNf52KRVHLWApdtieaqHIrHt9qbWsJ2bx+P3z5SkjOJbLDo06pAp4h
|
||||||
|
uYZuRiykUW+bMfv5Ec+qKUJVidG2J7YKpq3ghzdmebnZ+d/D/5KkEl22EnXw48Mj
|
||||||
|
r+ynJlq+EK5jQc0Y3CRt/ggjrqvmtE5Mqb6ltoVG4/yNa8z0tjza/B17tmYaCC/W
|
||||||
|
L7I/2KY7tKUuOk9JjWbTikTpGccn496QZlcpNWxiiK3qDOeah1iRLBqIm6HQeg5B
|
||||||
|
Vz3YWRir/L2QbkDFy6Lxy/28C0hbEljYV5rvuKjx5a4o8nUUcOPhiDTrpCpGKLZ8
|
||||||
|
uQ/9hYrLWWDYAREeNyuUHyyDyWGObqBr8W/vbQder2t8cSUZBhHR69k=
|
||||||
|
-----END CERTIFICATE-----
|
||||||
52
doc/key.pem
Normal file
52
doc/key.pem
Normal file
|
|
@ -0,0 +1,52 @@
|
||||||
|
-----BEGIN PRIVATE KEY-----
|
||||||
|
MIIJQgIBADANBgkqhkiG9w0BAQEFAASCCSwwggkoAgEAAoICAQCqDaso0s8+Rt9f
|
||||||
|
ILlF7koLcYJCjs+MjB0kpS7itdJj1YXW6a5lzIRP9bMSSftVmHGR1qFo6suKbVEa
|
||||||
|
yCkTrw3PU6w7iW7CMiRK6XL1Ix4B5BYEymKxihA1geRQZkKL8UHfudnpq7+yTqwK
|
||||||
|
XdOu4KrRUbMdIiOlaIhhK4/DZk8gxmZpiv81xqohtyVsr7Z8yKkSoX7TySPvn3qx
|
||||||
|
83BgeoGSqe/pX4quKVKj8ylkfdyKlaVPLGvSktTfr2rUYtRz1+xOEEYxUdaZBRZ2
|
||||||
|
/G1QaeELWimwPTAmg9KWCfA0/6TWMDvh2BtqJ0qJtcu43QVFf4AxoUQ/S/Mf4Zmc
|
||||||
|
/3gfOcEHrjnNube0xaUfMdjErhwPmXKc0E78hd9jlkJaICdGSEC19DZBt8LinyTM
|
||||||
|
r6+2E/YyD+bl+LUL8uI7m9zFgJYlLXUeZvabPvcxUq72pP6/j+9fGlT2JXSZ6bID
|
||||||
|
XyDbgz0QmZ5Rh+q5fwSAtfkSE16cx87aOM48iI98c4joN9FXAVwNT53ga/dxwCqQ
|
||||||
|
ZH4Sd024DEeo2Gk5dWyPTUnENcl4vW1Twa701gY60YqHw5UgH9DnBN+8yWjFHlbL
|
||||||
|
4aZvbLdTsQOCkHMxoTt5vGP2e5XHh0Etk1oK5E7FtXOFJ125PcPZ9BlyyyaKxR9y
|
||||||
|
kpMYNtHJjScQPTlMhku/8aK3sb3eRwIDAQABAoICAQCfIx9zmqQasZRDn4oCaVad
|
||||||
|
kuHFi4OrEUwMiRBxVJnIl38ieZic52FCurmTeexcU8akJejzGBbWOirWF05pfz47
|
||||||
|
MSBSrvAZh3bzK7hKs0xXlK0OWp81afB1QlL48lmAQIvW5EOLKxC/umPBZ8C7PMBe
|
||||||
|
Fki6EMKu/j3yQSPORiXyk/gu+MaP+pQn7Q52wZDTAa1HJB5d7zNUATh+40Pc5Yfw
|
||||||
|
SlubV6+eAEm358xqoGYMwrHqf7V/X60ajzw3+Sy8I+qduxkU+nMKy/oT63IY+JyD
|
||||||
|
VSMCLKCsylv90NsbnckSMB054lT1aEOWz6wQGbXfLcw3paUKXvbsdOCeTWyKPC/o
|
||||||
|
iytVCTaTrdNlRvEvyFICIjt1hW9db8lRrVuIkJvlRNeJPKwLozlVYASGlbx+gXPA
|
||||||
|
aqnh67nAwYQEzJt569PrwvOkXw7zjeHx7VoAaAxhc8dmDINh3bhXqijQrTi0rN8Y
|
||||||
|
3wwQFUZyR0YzWUk742owTXVU2FJRqJ/gIiJxWyCoWibsNIONWcaIRZZtYOQL2KQ7
|
||||||
|
O4JzjPdV5iDmM6TudUFlECnjvmYHQraGScMHIjU77n13RMhfsgMFuacSlLfmvfcB
|
||||||
|
7wLwMEhY/kM3yjAuZItlGHxUTbbsUe5WVtwVKMjNWLkz/5a7/7WR8EA8r/ZMKAwd
|
||||||
|
rbcMQ0LgyRmlLcxFQNrJIQKCAQEA2tsrpe0AyNsxW/N+LX1LmNxxvZuTcJSC3eVp
|
||||||
|
dVTx4TAdz8cliPQr5655m848zcteFarry9IE8sMUjI9V4XqjLJM4r6xcPpZTg0pN
|
||||||
|
mHv06rAztkYun9tuaFXI3+60bcc5iG+kKsUj0WqYwl3NyRsdeiyxsW5d9/RUJGhY
|
||||||
|
ttXltvtqgkPAYeFMHmtBCNJ09W1xEGXNVF69IhmYTVFS4MtLnxqYRRcTxlL5tbOd
|
||||||
|
9cgZ6UYefnhF44Aj5Bg16Ozvpqs/a+U9NyQvmpWC7WW5OfQVHZceje3mCOlsPdiW
|
||||||
|
+z4IGv8rRMjo2f1M/Xa8d5pILxNOu1FO6MEMqpAyfHss9SAHPwKCAQEAxuofqIBX
|
||||||
|
Wm9v+9px1QFmDt9IlJrN8TmKaa8N2i3xuQzHYELDQpBVOESqm7gun75GoYp5Q0lg
|
||||||
|
EB9CgZ1EttnCLEvDwraarcY0/oC6cCk5l+19muZjicvwOv2Y5ihm/d54XRbfHTA9
|
||||||
|
K7u9MZ+aW6+qyFaFidc5jqNJF74HJzaM78j0XgDzC4O58EKMnL1AibtC8+k1OHGO
|
||||||
|
6TbQJQx+rhyDN1KB4eJHysteSwslDgoTHL+al3x5njXvm1CgH7vuQ39xyY9gcTll
|
||||||
|
sYuIgVZpUMjeWam89zvMh1WWOJLsna+D+2D50OevqF/OobT/AG/d7+IvvooAxGpX
|
||||||
|
TOZtnHxKDtau+QKCAQAQ0T6tZWTmClHkqvVLMZGZkXb8BvRxdjgILRTJe1mK4FOq
|
||||||
|
H7d2qqylBPc7TcHGXpZAO/4aj2zp6qutkWYcCXx4dGequCfud0a7k/4adYwAbMHM
|
||||||
|
g+AZUJdPVSg2bPVYajK1lT6cOsHh2bsbVHH3vimptb2B0OVPpGrC0XHfutgIE5G/
|
||||||
|
qM0juFhNDhjVQLbUFTDW/bulfBI0iJr3dgRUWcrZ0wVYacmPN9kQaVj+Bf5Xupel
|
||||||
|
SEC2lqYrZODfoTVZLVeWRutJTXKLAmopK+Pr3CGzQGWMqnc+wBEdP4N6ku20hV8h
|
||||||
|
zf52ocxEvdcFqclaNLWcF0dlA1Ch2qrGfgCaZXepAoIBAANcIwrCmDcj2L1lVDTn
|
||||||
|
4CRyKxSvhLkFYswkM9Syn/mjOJ7socW3EGlx53vX4Zm7KhBCeYfkbmX3UTVFRcrc
|
||||||
|
5MXAxd69HOHAjlaaMAwC9kEVtuBt8dJ7CmTEsdd5aTvyjQ/teflRPkdF1Y1IB+By
|
||||||
|
mCzoITtR0lwRcAOhpxdHeZv3RgFsfK5+HB7t0Ng47iUlb50VHFwGtwZDccKecmlY
|
||||||
|
e/LsRttc6h+HzeDwoECbdPUwW1khtiAxAwoZk4rVrtGfDnn8HQHsmUYleDnPDtpZ
|
||||||
|
ekADePioHu1OScpM2QhU1aLiYXXg4/uxGplqqEAGo7YQmQPb6uVmcnEPF1zkUI/t
|
||||||
|
mmkCggEAGgNF6D0eSSb9muKwxzoYH6SeFsP6gXDJcLGRvD6nLdO70tK8R5H3EWAj
|
||||||
|
68FTlYhn5n4ljbPcHfOI8yxNgeQj/G4w9LX5MvqzxIgphiYk9D/NH99aaxX/JFuM
|
||||||
|
X6ZlpZLoNKpYJPWYoDxuGWhp3k66W/Rnfby7k5L/wh5c/zt4Q8OCW1mFwRXBXcS9
|
||||||
|
I6Z9jK72M8L7jp6hZELRTDfuMNv2Wj9BLoHu5wF66LsK5bw9zhcIgRUWUF+M1FqD
|
||||||
|
DafTiG+aLvDTNor/PDirYsLpHNW0j0uN4NC4jcIFiKXsgks8v3pgOJylnkxtgsRn
|
||||||
|
Qdcfj82isy1JR/mZp2t+sasS1DGxNg==
|
||||||
|
-----END PRIVATE KEY-----
|
||||||
649
doc/spec-spec.txt
Normal file
649
doc/spec-spec.txt
Normal file
|
|
@ -0,0 +1,649 @@
|
||||||
|
-----------------------------
|
||||||
|
Project Gemini
|
||||||
|
"Speculative specification"
|
||||||
|
v0.11.0, March 1st 2020
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
This is an increasingly less rough sketch of an actual spec for
|
||||||
|
Project Gemini. Although not finalised yet, further changes to the
|
||||||
|
specification are likely to be relatively small. You can write code
|
||||||
|
to this pseudo-specification and be confident that it probably won't
|
||||||
|
become totally non-functional due to massive changes next week, but
|
||||||
|
you are still urged to keep an eye on ongoing development of the
|
||||||
|
protocol and make changes as required.
|
||||||
|
|
||||||
|
This is provided mostly so that people can quickly get up to speed on
|
||||||
|
what I'm thinking without having to read lots and lots of old phlog
|
||||||
|
posts and keep notes.
|
||||||
|
|
||||||
|
Feedback on any part of this is extremely welcome, please email
|
||||||
|
solderpunk@sdf.org.
|
||||||
|
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
1. Overview
|
||||||
|
|
||||||
|
Gemini is a client-server protocol featuring request-response
|
||||||
|
transactions, broadly similar to gopher or HTTP. Connections are
|
||||||
|
closed at the end of a single transaction and cannot be reused. When
|
||||||
|
Gemini is served over TCP/IP, servers should listen on port 1965 (the
|
||||||
|
first manned Gemini mission, Gemini 3, flew in March '65). This is an
|
||||||
|
unprivileged port, so it's very easy to run a server as a "nobody"
|
||||||
|
user, even if e.g. the server is written in Go and so can't drop
|
||||||
|
privileges in the traditional fashion.
|
||||||
|
|
||||||
|
1.1 Gemini transactions
|
||||||
|
|
||||||
|
There is one kind of Gemini transaction, roughly equivalent to a
|
||||||
|
gopher request or a HTTP "GET" request. Transactions happen as
|
||||||
|
follows:
|
||||||
|
|
||||||
|
C: Opens connection
|
||||||
|
S: Accepts connection
|
||||||
|
C/S: Complete TLS handshake (see 1.4)
|
||||||
|
C: Validates server certificate (see 1.4.2)
|
||||||
|
C: Sends request (one CRLF terminated line) (see 1.2)
|
||||||
|
S: Sends response header (one CRFL terminated line), closes connection
|
||||||
|
under non-success conditions (see 1.3.1, 1.3.2)
|
||||||
|
S: Sends response body (text or binary data) (see 1.3.3)
|
||||||
|
S: Closes connection
|
||||||
|
C: Handles response (see 1.3.4)
|
||||||
|
|
||||||
|
1.2 Gemini requests
|
||||||
|
|
||||||
|
Gemini requests are a single CRLF-terminated line with the following
|
||||||
|
structure:
|
||||||
|
|
||||||
|
<URL><CR><LF>
|
||||||
|
|
||||||
|
<URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes.
|
||||||
|
If the scheme of the URL is not specified, a scheme of gemini:// is
|
||||||
|
implied.
|
||||||
|
|
||||||
|
Sending an absolute URL instead of only a path or selector is
|
||||||
|
effectively equivalent to building in a HTTP "Host" header. It
|
||||||
|
permits virtual hosting of multiple Gemini domains on the same IP
|
||||||
|
address. It also allows servers to optionally act as proxies.
|
||||||
|
Including schemes other than gemini:// in requests allows servers to
|
||||||
|
optionally act as protocol-translating gateways to e.g. fetch gopher
|
||||||
|
resources over Gemini. Proxying is optional and the vast majority of
|
||||||
|
servers are expected to only respond to requests for resources at
|
||||||
|
their own domain(s).
|
||||||
|
|
||||||
|
1.3 Responses
|
||||||
|
|
||||||
|
Gemini response consist of a single CRLF-terminated header line,
|
||||||
|
optionally followed by a response body.
|
||||||
|
|
||||||
|
1.3.1 Response headers
|
||||||
|
|
||||||
|
Gemini response headers look like this:
|
||||||
|
|
||||||
|
<STATUS><whitespace><META><CR><LF>
|
||||||
|
|
||||||
|
<STATUS> is a two-digit numeric status code, as described below in
|
||||||
|
1.3.2 and in Appendix 1.
|
||||||
|
|
||||||
|
<whitespace> is any non-zero number of consecutive spaces or tabs.
|
||||||
|
|
||||||
|
<META> is a UTF-8 encoded string of maximum length 1024, whose meaning
|
||||||
|
is <STATUS> dependent.
|
||||||
|
|
||||||
|
If <STATUS> does not belong to the "SUCCESS" range of codes, then the
|
||||||
|
server MUST close the connection after sending the header and MUST NOT
|
||||||
|
send a response body.
|
||||||
|
|
||||||
|
If a server sends a <STATUS> which is not a two-digit number or a
|
||||||
|
<META> which exceeds 1024, the client SHOULD close the connection and
|
||||||
|
disregard the response header, informing the user of an error.
|
||||||
|
|
||||||
|
1.3.2 Status codes
|
||||||
|
|
||||||
|
Gemini uses two-digit numeric status codes. Related status codes share
|
||||||
|
the same first digit. Importantly, the first digit of Gemini status
|
||||||
|
codes do not group codes into vague categories like "client error" and
|
||||||
|
"server error" as per HTTP. Instead, the first digit alone provides
|
||||||
|
enough information for a client to determine how to handle the
|
||||||
|
response. By design, it is possible to write a simple but feature
|
||||||
|
complete client which only looks at the first digit. The second digit
|
||||||
|
provides more fine-grained information, for unambiguous server logging,
|
||||||
|
to allow writing comfier interactive clients which provide a slightly
|
||||||
|
more streamlined user interface, and to allow writing more robust and
|
||||||
|
intelligent automated clients like content aggregators, search engine
|
||||||
|
crawlers, etc.
|
||||||
|
|
||||||
|
The first digit of a response code unambiguously places the response
|
||||||
|
into one of six categories, which define the semantics of the <META>
|
||||||
|
line.
|
||||||
|
|
||||||
|
1 INPUT
|
||||||
|
|
||||||
|
The requested resource accepts a line of textual user input.
|
||||||
|
The <META> line is a prompt which should be displayed to the
|
||||||
|
user. The same resource should then be requested again with
|
||||||
|
the user's input included as a query component. Queries are
|
||||||
|
included in requests as per the usual generic URL definition
|
||||||
|
in RFC3986, i.e. separated from the path by a ?. There is no
|
||||||
|
response body.
|
||||||
|
|
||||||
|
2 SUCCESS
|
||||||
|
|
||||||
|
The request was handled successfully and a response body will
|
||||||
|
follow the response header. The <META> line is a MIME media
|
||||||
|
type which applies to the response body.
|
||||||
|
|
||||||
|
3 REDIRECT
|
||||||
|
|
||||||
|
The server is redirecting the client to a new location for the
|
||||||
|
requested resource. There is no response body. The header
|
||||||
|
text is a new URL for the requested resource. The URL may be
|
||||||
|
absolute or relative. The redirect should be considered
|
||||||
|
temporary, i.e. clients should continue to request the
|
||||||
|
resource at the original address and should not performance
|
||||||
|
convenience actions like automatically updating bookmarks.
|
||||||
|
There is no response body.
|
||||||
|
|
||||||
|
4 TEMPORARY FAILURE
|
||||||
|
|
||||||
|
The request has failed. There is no response body. The
|
||||||
|
nature of the failure is temporary, i.e. an identical request
|
||||||
|
MAY succeed in the future. The contents of <META> may provide
|
||||||
|
additional information on the failure, and should be displayed
|
||||||
|
to human users.
|
||||||
|
|
||||||
|
5 PERMANENT FAILURE
|
||||||
|
|
||||||
|
The request has failed. There is no response body. The
|
||||||
|
nature of the failure is permanent, i.e. identical future
|
||||||
|
requests will reliably fail for the same reason. The contents
|
||||||
|
of <META> may provide additional information on the failure,
|
||||||
|
and should be displayed to human users. Automatic clients
|
||||||
|
such as aggregators or indexing crawlers should should not
|
||||||
|
repeat this request.
|
||||||
|
|
||||||
|
6 CLIENT CERTIFICATE REQUIRED
|
||||||
|
|
||||||
|
The requested resource requires client-certificate
|
||||||
|
authentication to access. If the request was made without a
|
||||||
|
certificate, it should be repeated with one. If the request
|
||||||
|
was made with a certificate, the server did not accept it and
|
||||||
|
the request should be repeated with a different certificate.
|
||||||
|
The contents of <META> may provide additional information on
|
||||||
|
certificate requirements or the reason a certificate was
|
||||||
|
rejected.
|
||||||
|
|
||||||
|
Note that for basic interactive clients for human use, errors 4 and 5
|
||||||
|
may be effectively handled identically, by simply displaying the
|
||||||
|
contents of <META> under a heading of "ERROR". The
|
||||||
|
temporary/permanent error distinction is primarily relevant to
|
||||||
|
well-behaving automated clients. Basic clients may also choose not to
|
||||||
|
support client-certificate authentication, in which case only four
|
||||||
|
distinct status handling routines are required (for statuses beginning
|
||||||
|
with 1, 2, 3 or a combined 4-or-5).
|
||||||
|
|
||||||
|
The full two-digit system is detailed in Appendix 1. Note that for
|
||||||
|
each of the six valid first digits, a code with a second digit of zero
|
||||||
|
corresponds is a generic status of that kind with no special
|
||||||
|
semantics. This means that basic servers without any advanced
|
||||||
|
functionality need only be able to return codes of 10, 20, 30, 40 or
|
||||||
|
50.
|
||||||
|
|
||||||
|
The Gemini status code system has been carefully designed so that the
|
||||||
|
increased power (and correspondingly increased complexity) of the
|
||||||
|
second digits is entirely "opt-in" on the part of both servers and
|
||||||
|
clients.
|
||||||
|
|
||||||
|
1.3.3 Response bodies
|
||||||
|
|
||||||
|
Response bodies are just raw content, text or binary, ala gopher.
|
||||||
|
There is no support for compression, chunking or any other kind of
|
||||||
|
content or transfer encoding. The server closes the connection after
|
||||||
|
the final byte, there is no "end of response" signal like gopher's
|
||||||
|
lonely dot.
|
||||||
|
|
||||||
|
Response bodies only accompany responses whose header indicates a
|
||||||
|
SUCCESS status (i.e. a status code whose first digit is 2). For such
|
||||||
|
responses, <META> is a MIME media type as defined in RFC 2046.
|
||||||
|
|
||||||
|
If a MIME type begins with "text/" and no charset is explicitly given,
|
||||||
|
the charset should be assumed to be UTF-8. Compliant clients MUST
|
||||||
|
support UTF-8-encoded text/* responses. Clients MAY optionally
|
||||||
|
support other encodings. Clients receiving a response in a charset
|
||||||
|
they cannot decode SHOULD gracefully inform the user what happened
|
||||||
|
instead of displaying garbage.
|
||||||
|
|
||||||
|
If <META> is an empty string, the MIME type MUST default to
|
||||||
|
"text/gemini; charset=utf-8".
|
||||||
|
|
||||||
|
1.3.4 Response body handling
|
||||||
|
|
||||||
|
Response handling by clients should be informed by the provided MIME
|
||||||
|
type information. Gemini defines one MIME type of its own
|
||||||
|
(text/gemini) whose handling is discussed below in 1.3.5. In all
|
||||||
|
other cases, clients should do "something sensible" based on the MIME
|
||||||
|
type. Minimalistic clients might adopt a strategy of printing all
|
||||||
|
other text/* responses to the screen without formatting and saving
|
||||||
|
all non-text responses to the disk. Clients for unix systems may
|
||||||
|
consult /etc/mailcap to find installed programs for handling non-text
|
||||||
|
types.
|
||||||
|
|
||||||
|
1.3.5 text/gemini responses
|
||||||
|
|
||||||
|
1.3.5.1 Overview
|
||||||
|
|
||||||
|
In the same sense that HTML is the "native" response format of HTTP
|
||||||
|
and plain text is the native response format of gopher, Gemini defines
|
||||||
|
its own native response format - though of course, thanks to the
|
||||||
|
inclusion of a MIME type in the response header Gemini can be used to
|
||||||
|
serve plain text, rich text, HTML, Markdown, LaTeX, etc.
|
||||||
|
|
||||||
|
Response bodies of type "text/gemini" are a kind of lightweight
|
||||||
|
hypertext format, which takes inspiration from gophermaps and from
|
||||||
|
Markdown. The format permits richer typographic possibilities than
|
||||||
|
the plain text of Gopher, but remains extremely easy to parse. The
|
||||||
|
format is line-oriented, and a satisfactory rendering can be achieved
|
||||||
|
with a single pass of a document, processing each line independently.
|
||||||
|
As per gopher, links can only be displayed one per line, encouraging
|
||||||
|
neat, list-like structure.
|
||||||
|
|
||||||
|
Similar to how the two-digit Gemini status codes were designed so that
|
||||||
|
simple clients can function correctly while ignoring the second digit,
|
||||||
|
the text/gemini format has been designed so that simple clients can
|
||||||
|
ignore the more advanced features and still remain very usable.
|
||||||
|
|
||||||
|
1.3.5.2 Line-orientation
|
||||||
|
|
||||||
|
As mentioned, the text/gemini format is line-oriented. Each line of a
|
||||||
|
text/gemini document has a single "line type". It is possible to
|
||||||
|
unambiguously determine a line's type purely by inspecting its first
|
||||||
|
three characters. A line's type determines the manner in which it
|
||||||
|
should be presented to the user. Any details of presentation or
|
||||||
|
rendering associated with a particular line type are strictly limited
|
||||||
|
in scope to that individual line.
|
||||||
|
|
||||||
|
There are 6 different line types in total. However, a fully
|
||||||
|
functional and specification compliant Gemini client need only
|
||||||
|
recognise and handle 4 of them - these are the "core line types",
|
||||||
|
(see 1.3.5.3). Advanced clients can also handle the additional
|
||||||
|
"advanced line types" (see 1.3.5.4). Simple clients can treat all
|
||||||
|
advanced line types as one of the core line types and still offer an
|
||||||
|
adequate user experience.
|
||||||
|
|
||||||
|
1.3.5.3 Core line types
|
||||||
|
|
||||||
|
The four core line types are:
|
||||||
|
|
||||||
|
1.3.5.3.1 Text lines
|
||||||
|
|
||||||
|
Text lines are the most fundamenal line type - any line which does
|
||||||
|
not match the definition of another line type defined below defaults
|
||||||
|
to being a text line. The majority of lines in a typical text/gemini
|
||||||
|
document will be text lines.
|
||||||
|
|
||||||
|
Text lines should be presented to the user, after being wrapped to
|
||||||
|
the appropriate width for the client's viewport (see below). Text
|
||||||
|
lines may be presented to the user in a visually pleasing manner
|
||||||
|
for general reading, the precise meaning of which is at the
|
||||||
|
client's discretion. For example, variable width fonts may be used,
|
||||||
|
spacing may be normalised, with spaces between sentences being made
|
||||||
|
wider than spacing between words, and other such typographical
|
||||||
|
niceties may be applied. Clients may permit users to customise the
|
||||||
|
appearance of text lines by altering the font, font size, text and
|
||||||
|
background colour, etc. Authors should not expect to exercise any
|
||||||
|
control over the precise rendering of their text lines, only of their
|
||||||
|
actual textual content. Content such as ASCII art, computer source
|
||||||
|
code, etc. which may appear incorrectly when treated as such should
|
||||||
|
be enclosed beween preformatting toggle lines (see 1.3.5.3.3).
|
||||||
|
|
||||||
|
Blank lines are instances of text lines and have no special meaning.
|
||||||
|
They should be rendered individually as vertical blank space each
|
||||||
|
time they occur. In this way they are analogous to <br/> tags in HTML.
|
||||||
|
Consecutive blank lines should NOT be collapsed into a fewer blank
|
||||||
|
lines. Note also that consecutive non-blank text lines do not form
|
||||||
|
any kind of coherent unit or block such as a "paragraph": all text
|
||||||
|
lines are independent entities.
|
||||||
|
|
||||||
|
Text lines which are longer than can fit on a client's display device
|
||||||
|
SHOULD be "wrapped" to fit, i.e. long lines should be split (ideally
|
||||||
|
at whitespace or at hyphens) into multiple consecutive lines of a
|
||||||
|
device-appropriate width. This wrapping is applied to each line of
|
||||||
|
text independently. Multiple consecutive lines which are shorter
|
||||||
|
than the client's display device MUST NOT be combined into fewer,
|
||||||
|
longer lines.
|
||||||
|
|
||||||
|
In order to take full advantage of this method of text formatting,
|
||||||
|
authors of text/gemini content SHOULD avoid hard-wrapping to a
|
||||||
|
pecific fixed width, in contrast to the convention in Gopherspace
|
||||||
|
where text is typically wrapped at 80 characters or fewer. Instead,
|
||||||
|
text which should be displayed as a contiguous block should be written
|
||||||
|
as a single long line. Most text editors can be configured to
|
||||||
|
"soft-wrap", i.e. to write this kind of file while displaying the long
|
||||||
|
lines wrapped to fit the author's display device.
|
||||||
|
|
||||||
|
Authors who insist on hard-wrapping their content MUST be aware that
|
||||||
|
the content will display neatly on clients whose display device is as
|
||||||
|
wide as the hard-wrapped length or wider, but will appear with
|
||||||
|
irregular line widths on narrower clients.
|
||||||
|
|
||||||
|
1.3.5.3.2 Link lines
|
||||||
|
|
||||||
|
Lines beginning with the two characters "=>" are link lines, which
|
||||||
|
have the following syntax:
|
||||||
|
|
||||||
|
=>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]<CR><LF>
|
||||||
|
|
||||||
|
where:
|
||||||
|
|
||||||
|
* <whitespace> is any non-zero number of consecutive spaces or
|
||||||
|
tabs
|
||||||
|
* Square brackets indicate that the enclosed content is
|
||||||
|
optional.
|
||||||
|
* <URL> is a URL, which may be absolute or relative. If the URL does
|
||||||
|
not include a scheme, a scheme of gemini:// is implied.
|
||||||
|
|
||||||
|
All the following examples are valid link lines:
|
||||||
|
|
||||||
|
=> gemini://example.org/
|
||||||
|
=> gemini://example.org/ An example link
|
||||||
|
=> gemini://example.org/foo Another example link at the same host
|
||||||
|
=>gemini://example.org/bar Yet another example link at the same host
|
||||||
|
=> foo/bar/baz.txt A relative link
|
||||||
|
=> gopher://example.org:70/1 A gopher link
|
||||||
|
|
||||||
|
Note that link URLs may have schemes other than gemini://. This means
|
||||||
|
that Gemini documents can simply and elegantly link to documents
|
||||||
|
hosted via other protocols, unlike gophermaps which can only link to
|
||||||
|
non-gopher content via a non-standard adaptation of the `h` item-type.
|
||||||
|
|
||||||
|
Clients can present links to users in whatever fashion the client
|
||||||
|
author wishes.
|
||||||
|
|
||||||
|
1.3.5.3.3 Preformatting toggle lines
|
||||||
|
|
||||||
|
Any line whose first three characters are "```" (i.e. three
|
||||||
|
consecutive back ticks with no leading whitespace) are preformatted
|
||||||
|
toggle lines. These lines should NOT be included in the rendered
|
||||||
|
output shown to the user. Instead, these lines toggle the parser
|
||||||
|
between preformatted mode being "on" or "off". Preformatted mode
|
||||||
|
should be "off" at the beginning of a document. The current status
|
||||||
|
of preformatted mode is the only internal state a parser is required
|
||||||
|
to maintain. When preformatted mode is "on", the usual rules for
|
||||||
|
identifying line types are suspended, and all lines should be
|
||||||
|
identified as preformatted text lines (see 1.3.5.3.4).
|
||||||
|
|
||||||
|
Preformatting toggle lines can be thought of as analogous to <pre> and
|
||||||
|
</pre> tags in HTML.
|
||||||
|
|
||||||
|
1.3.5.3.4 Preformatted text lines
|
||||||
|
|
||||||
|
Preformatted text lines should be presented to the user in a "neutral",
|
||||||
|
monowidth font without any alteration to whitespace or stylistic
|
||||||
|
enhancements. Graphical clients should use scrolling mechanisms to
|
||||||
|
present preformatted text lines which are longer than the client
|
||||||
|
viewport, in preference to wrapping. In displaying preformatted text
|
||||||
|
lines, clients should keep in mind applications like ASCII art and
|
||||||
|
computer source code: in particular, source code in langugaes with
|
||||||
|
significant whitespace (e.g. Python) should be able to be copied and
|
||||||
|
pasted from the client into a file and interpreted/compiled without
|
||||||
|
any problems arising from the client's manner of displaying them.
|
||||||
|
|
||||||
|
1.3.5.4 Advanced line types
|
||||||
|
|
||||||
|
The following advanced line types MAY be recognised by advanced
|
||||||
|
clients. Simple clients may treat them all as text lines as per
|
||||||
|
1.3.5.3.1 without any loss of essential function.
|
||||||
|
|
||||||
|
1.3.5.4.1 Heading lines
|
||||||
|
|
||||||
|
Lines beginning with "#" are heading lines. Heading lines consist of
|
||||||
|
one, two or three consecutive "#" characters, followed by optional
|
||||||
|
whitespace, followed by heading text. The number of # characters
|
||||||
|
indicates the "level" of header; #, ## and ### can be thought of as
|
||||||
|
analogous to <h1>, <h2> and <h3> in HTML.
|
||||||
|
|
||||||
|
Heading text should be presented to the user, and clients MAY use
|
||||||
|
special formatting, e.g. a larger or bold font, to indicate its
|
||||||
|
status as a header (simple clients may simply print the line,
|
||||||
|
including its leading #s, without any styling at all). However, the
|
||||||
|
main motivation for the definition of heading lines is not stylistic
|
||||||
|
but to provide a machine-readable representation of the internal
|
||||||
|
structure of the document. Advanced clients can use this information
|
||||||
|
to, e.g. display an automatically generated and hierarchically
|
||||||
|
formatted "table of contents" for a long document in a side-pane,
|
||||||
|
allowing users to easily jump to specific sections without excessive
|
||||||
|
scrolling. CMS-style tools automatically generating menus or
|
||||||
|
Atom/RSS feeds for a directory of text/gemini files can use first
|
||||||
|
heading in the file as a human-friendly title.
|
||||||
|
|
||||||
|
1.3.5.4.2 Unordered list items
|
||||||
|
|
||||||
|
Lines beginning with a * are unordered list items. This line type
|
||||||
|
exists purely for stylistic reasons. The * may be replaced in
|
||||||
|
advanced clients by a bullet symbol. Any text after the * character
|
||||||
|
should be presented to the user as if it were a text line, i.e.
|
||||||
|
wrapped to fit the viewport and formatted "nicely". Advanced clients
|
||||||
|
can take the space of the bullet symbol into account when wrapping
|
||||||
|
long list items to ensure that all lines of text corresponding to
|
||||||
|
the item are offset an equal distance from the left of the screen.
|
||||||
|
|
||||||
|
1.4 TLS
|
||||||
|
|
||||||
|
1.4.1 Version requirements
|
||||||
|
|
||||||
|
Use of TLS for Gemini transactions is mandatory.
|
||||||
|
|
||||||
|
Servers MUST use TLS version 1.2 or higher and SHOULD use TLS version
|
||||||
|
1.3 or higher. Clients MAY refuse to connect to servers using TLS
|
||||||
|
version 1.2 or lower.
|
||||||
|
|
||||||
|
1.4.2 Server certificate validation
|
||||||
|
|
||||||
|
Clients can validate TLS connections however they like (including not
|
||||||
|
at all) but the strongly RECOMMENDED approach is to implement a
|
||||||
|
lightweight "TOFU" certificate-pinning system which treats self-signed
|
||||||
|
certificates as first- class citizens. This greatly reduces TLS
|
||||||
|
overhead on the network (only one cert needs to be sent, not a whole
|
||||||
|
chain) and lowers the barrier to entry for setting up a Gemini site
|
||||||
|
(no need to pay a CA or setup a Let's Encrypt cron job, just make a
|
||||||
|
cert and go).
|
||||||
|
|
||||||
|
TOFU stands for "Trust On First Use" and is public-key security model
|
||||||
|
similar to that used by OpenSSH. The first time a Gemini client
|
||||||
|
connects to a server, it accepts whatever certificate it is presented.
|
||||||
|
That certificate's fingerprint and expiry date are saved in a
|
||||||
|
persistent database (like the .known_hosts file for SSH), associated
|
||||||
|
with the server's hostname. On all subsequent connections to that
|
||||||
|
hostname, the received certificate's fingerprint is computed and
|
||||||
|
compared to the one in the database. If the certificate is not the
|
||||||
|
one previously received, but the previous certificate's expiry date
|
||||||
|
has not passed, the user is shown a warning, analogous to the one web
|
||||||
|
browser users are shown when receiving a certificate without a
|
||||||
|
signature chain leading to a trusted CA.
|
||||||
|
|
||||||
|
This model is by no means perfect, but it is not awful and is vastly
|
||||||
|
superior to just accepting self-signed certificates unconditionally.
|
||||||
|
|
||||||
|
1.4.3 Transient client certificate sessions
|
||||||
|
|
||||||
|
Self-signed client certificates can optionally be used by Gemini
|
||||||
|
clients to permit servers to recognise subsequent requests from the
|
||||||
|
same client as belonging to a single "session". This facilitates
|
||||||
|
maintaining state in server-side applications. The functionality is
|
||||||
|
very similar to HTTP cookies, but with important differences.
|
||||||
|
|
||||||
|
Whereas HTTP cookies are originally created by a webserver and given
|
||||||
|
to a client via a response header, client certificates are created by
|
||||||
|
the client and given to the server as part of the TLS handshake:
|
||||||
|
Client certificates are fundamentally a client-centric means of
|
||||||
|
identification. Further, whereas HTTP cookies can be "resurrected" by
|
||||||
|
webservers after a client deletes them if the server recognises the
|
||||||
|
client by means of browser finger-printing or some other tracking
|
||||||
|
technology (leading to unkillable "super cookies"), if a client
|
||||||
|
deletes a client certificate and also the accompanying private key
|
||||||
|
(which the server has never seen), then the session ID can never be
|
||||||
|
recreated. Thus clients not only need to opt in to a certificate
|
||||||
|
session, but once they have done so they retain a guaranteed ability
|
||||||
|
to opt out of it at any point and the server cannot defeat this
|
||||||
|
ability.
|
||||||
|
|
||||||
|
Gemini requests typically will be made without a client certificate
|
||||||
|
being sent to the server. If a requested resource is part of a
|
||||||
|
server-side application which requires persistent state, a Gemini
|
||||||
|
server can return a status code of 61 (see Appendix 1 below) to
|
||||||
|
request that the client repeat the request with a "transient
|
||||||
|
certificate" to initiate a client certificate section.
|
||||||
|
|
||||||
|
Interactive clients for human users MUST inform users that such a
|
||||||
|
session has been requested and require the user to approve generation
|
||||||
|
of such a certificate. Transient certificates MUST NOT be generated
|
||||||
|
automatically.
|
||||||
|
|
||||||
|
Transient certificates are limited in scope to a particular domain.
|
||||||
|
Transient certificates MUST NOT be reused across different domains.
|
||||||
|
|
||||||
|
Transient certificates MUST be permanently deleted when the matching
|
||||||
|
server issues a response with a status code of 21 (see Appendix 1
|
||||||
|
below).
|
||||||
|
|
||||||
|
Transient certificates MUST be permanently deleted when the client
|
||||||
|
process terminates.
|
||||||
|
|
||||||
|
Transient certificates SHOULD be permanently deleted after not having
|
||||||
|
been used for more than 24 hours.
|
||||||
|
|
||||||
|
Appendix 1. Full two digit status codes
|
||||||
|
|
||||||
|
10 INPUT
|
||||||
|
|
||||||
|
As per definition of single-digit code 1 in 1.3.2.
|
||||||
|
|
||||||
|
20 SUCCESS
|
||||||
|
|
||||||
|
As per definition of single-digit code 2 in 1.3.2.
|
||||||
|
|
||||||
|
21 SUCCESS - END OF CLIENT CERTIFICATE SESSION
|
||||||
|
|
||||||
|
The request was handled successfully and a response body will
|
||||||
|
follow the response header. The <META> line is a MIME media
|
||||||
|
type which applies to the response body. In addition, the
|
||||||
|
server is signalling the end of a transient client certificate
|
||||||
|
session which was previously initiated with a status 61
|
||||||
|
response. The client should immediately and permanently
|
||||||
|
delete the certificate and accompanying private key which was
|
||||||
|
used in this request.
|
||||||
|
|
||||||
|
30 REDIRECT - TEMPORARY
|
||||||
|
|
||||||
|
As per definition of single-digit code 3 in 1.3.2.
|
||||||
|
|
||||||
|
31 REDIRECT - PERMANENT
|
||||||
|
|
||||||
|
The requested resource should be consistently requested from
|
||||||
|
the new URL provided in future. Tools like search engine
|
||||||
|
indexers or content aggregators should update their
|
||||||
|
configurations to avoid requesting the old URL, and end-user
|
||||||
|
clients may automatically update bookmarks, etc. Note that
|
||||||
|
clients which only pay attention to the initial digit of
|
||||||
|
status codes will treat this as a temporary redirect. They
|
||||||
|
will still end up at the right place, they just won't be able
|
||||||
|
to make use of the knowledge that this redirect is permanent,
|
||||||
|
so they'll pay a small performance penalty by having to follow
|
||||||
|
the redirect each time.
|
||||||
|
|
||||||
|
40 TEMPORARY FAILURE
|
||||||
|
|
||||||
|
As per definition of single-digit code 4 in 1.3.2.
|
||||||
|
|
||||||
|
41 SERVER UNAVAILABLE
|
||||||
|
|
||||||
|
The server is unavailable due to overload or maintenance.
|
||||||
|
(cf HTTP 503)
|
||||||
|
|
||||||
|
42 CGI ERROR
|
||||||
|
|
||||||
|
A CGI process, or similar system for generating dynamic
|
||||||
|
content, died unexpectedly or timed out.
|
||||||
|
|
||||||
|
43 PROXY ERROR
|
||||||
|
|
||||||
|
A proxy request failed because the server was unable to
|
||||||
|
successfully complete a transaction with the remote host.
|
||||||
|
(cf HTTP 502, 504)
|
||||||
|
|
||||||
|
44 SLOW DOWN
|
||||||
|
|
||||||
|
Rate limiting is in effect. <META> is an integer number of
|
||||||
|
seconds which the client must wait before another request is
|
||||||
|
made to this server.
|
||||||
|
(cf HTTP 429)
|
||||||
|
|
||||||
|
50 PERMANENT FAILURE
|
||||||
|
|
||||||
|
As per definition of single-digit code 5 in 1.3.2.
|
||||||
|
|
||||||
|
51 NOT FOUND
|
||||||
|
|
||||||
|
The requested resource could not be found but may be available
|
||||||
|
in the future.
|
||||||
|
(cf HTTP 404)
|
||||||
|
(struggling to remember this important status code? Easy:
|
||||||
|
you can't find things hidden at Area 51!)
|
||||||
|
|
||||||
|
52 GONE
|
||||||
|
|
||||||
|
The resource requested is no longer available and will not be
|
||||||
|
available again. Search engines and similar tools should
|
||||||
|
remove this resource from their indices. Content aggregators
|
||||||
|
should stop requesting the resource and convey to their human
|
||||||
|
users that the subscribed resource is gone.
|
||||||
|
(cf HTTP 410)
|
||||||
|
|
||||||
|
53 PROXY REQUEST REFUSED
|
||||||
|
|
||||||
|
The request was for a resource at a domain not served by the
|
||||||
|
server and the server does not accept proxy requests.
|
||||||
|
|
||||||
|
59 BAD REQUEST
|
||||||
|
|
||||||
|
The server was unable to parse the client's request,
|
||||||
|
presumably due to a malformed request.
|
||||||
|
(cf HTTP 400)
|
||||||
|
|
||||||
|
60 CLIENT CERTIFICATE REQUIRED
|
||||||
|
|
||||||
|
As per definition of single-digit code 6 in 1.3.2.
|
||||||
|
|
||||||
|
61 TRANSIENT CERTIFICATE REQUESTED
|
||||||
|
|
||||||
|
The server is requesting the initiation of a transient client
|
||||||
|
certificate session, as described in 1.4.3. The client should
|
||||||
|
ask the user if they want to accept this and, if so, generate
|
||||||
|
a disposable key/cert pair and re-request the resource using it.
|
||||||
|
The key/cert pair should be destroyed when the client quits,
|
||||||
|
or some reasonable time after it was last used (24 hours?
|
||||||
|
Less?)
|
||||||
|
|
||||||
|
62 AUTHORISED CERTIFICATE REQUIRED
|
||||||
|
|
||||||
|
This resource is protected and a client certificate which the
|
||||||
|
server accepts as valid must be used - a disposable key/cert
|
||||||
|
generated on the fly in response to this status is not
|
||||||
|
appropriate as the server will do something like compare the
|
||||||
|
certificate fingerprint against a white-list of allowed
|
||||||
|
certificates. The client should ask the user if they want to
|
||||||
|
use a pre-existing certificate from a stored "key chain".
|
||||||
|
|
||||||
|
63 CERTIFICATE NOT ACCEPTED
|
||||||
|
|
||||||
|
The supplied client certificate is not valid for accessing the
|
||||||
|
requested resource.
|
||||||
|
|
||||||
|
64 FUTURE CERTIFICATE REJECTED
|
||||||
|
|
||||||
|
The supplied client certificate was not accepted because its
|
||||||
|
validity start date is in the future.
|
||||||
|
|
||||||
|
65 EXPIRED CERTIFICATE REJECTED
|
||||||
|
|
||||||
|
The supplied client certificate was not accepted because its
|
||||||
|
expiry date has passed.
|
||||||
45
src/main.rs
Normal file
45
src/main.rs
Normal file
|
|
@ -0,0 +1,45 @@
|
||||||
|
use openssl::ssl::{SslMethod, SslAcceptor, SslStream, SslFiletype};
|
||||||
|
use std::net::{TcpListener, TcpStream, SocketAddr};
|
||||||
|
use std::sync::Arc;
|
||||||
|
use std::thread;
|
||||||
|
mod response;
|
||||||
|
|
||||||
|
fn build_acceptor() -> std::sync::Arc<SslAcceptor> {
|
||||||
|
let mut acceptor = SslAcceptor::mozilla_intermediate_v5(SslMethod::tls()).unwrap();
|
||||||
|
acceptor.set_private_key_file("doc/key.pem", SslFiletype::PEM).unwrap();
|
||||||
|
acceptor.set_certificate_chain_file("doc/cert.pem").unwrap();
|
||||||
|
acceptor.check_private_key().unwrap();
|
||||||
|
return Arc::new(acceptor.build());
|
||||||
|
}
|
||||||
|
|
||||||
|
fn handle_client(mut stream: SslStream<TcpStream>) {
|
||||||
|
let mut buffer = [0; 1026];
|
||||||
|
stream.ssl_read(&mut buffer);
|
||||||
|
let request = String::from_utf8(buffer.to_vec()).unwrap();
|
||||||
|
|
||||||
|
let header = response::Header::new(response::Status::Success, "text/gemini".to_string());
|
||||||
|
let response = response::Response::new(header, [].to_vec());
|
||||||
|
|
||||||
|
stream.ssl_write(&response.format());
|
||||||
|
}
|
||||||
|
|
||||||
|
fn main() {
|
||||||
|
let addrs = [
|
||||||
|
SocketAddr::from(([127, 0, 0, 1], 1965)),
|
||||||
|
];
|
||||||
|
let acceptor = build_acceptor();
|
||||||
|
let listener = TcpListener::bind(&addrs[..]).unwrap();
|
||||||
|
|
||||||
|
for stream in listener.incoming() {
|
||||||
|
match stream {
|
||||||
|
Ok(stream) => {
|
||||||
|
let acceptor = acceptor.clone();
|
||||||
|
thread::spawn(move || {
|
||||||
|
let stream = acceptor.accept(stream).unwrap();
|
||||||
|
handle_client(stream);
|
||||||
|
});
|
||||||
|
}
|
||||||
|
Err(e) => { /* connection failed */ }
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
50
src/response.rs
Normal file
50
src/response.rs
Normal file
|
|
@ -0,0 +1,50 @@
|
||||||
|
use std::vec;
|
||||||
|
|
||||||
|
#[derive(Copy, Clone)]
|
||||||
|
pub enum Status {
|
||||||
|
Input = 1,
|
||||||
|
Success = 2,
|
||||||
|
Redirect = 3,
|
||||||
|
TemporaryFailure = 4,
|
||||||
|
PermanentFailure = 5,
|
||||||
|
ClientCertificateRequired = 6,
|
||||||
|
}
|
||||||
|
|
||||||
|
pub struct Header {
|
||||||
|
status: Status,
|
||||||
|
meta: String,
|
||||||
|
}
|
||||||
|
|
||||||
|
pub struct Response {
|
||||||
|
header: Header,
|
||||||
|
data: std::vec::Vec<u8>,
|
||||||
|
}
|
||||||
|
|
||||||
|
impl Header {
|
||||||
|
pub fn new(status: Status, meta: String) -> Header {
|
||||||
|
return Header{
|
||||||
|
status: status,
|
||||||
|
meta: meta,
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
pub fn format(&self) -> String {
|
||||||
|
let status: u8 = self.status as u8;
|
||||||
|
return format!("{} {}\r\n", status * 10, self.meta)
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
impl Response {
|
||||||
|
pub fn new(header: Header, data: std::vec::Vec<u8>) -> Response {
|
||||||
|
return Response{
|
||||||
|
header: header,
|
||||||
|
data: data,
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
pub fn format(&self) -> std::vec::Vec<u8> {
|
||||||
|
let mut resp: std::vec::Vec<u8> = self.header.format().as_bytes().to_vec();
|
||||||
|
resp.extend(&self.data);
|
||||||
|
return resp;
|
||||||
|
}
|
||||||
|
}
|
||||||
Loading…
Reference in a new issue