path: root/contrib/fcfsd/fcfsd-notfound.html
diff options
authorAlessio Vanni <>2021-05-02 19:02:26 +0200
committerAlessio Vanni <>2021-05-07 22:38:02 +0200
commit2bca4006c49c7b3875034f6fd6530cbcfe20bcb1 (patch)
tree391f0b63a81385b8ad7fabd7cb120c4de9a86ef6 /contrib/fcfsd/fcfsd-notfound.html
parenta5082240f035f1851715771b0265e25088bb687c (diff)
[FCFSD] Provide a better user experience
The motivations behind these changes are as following. To begin with, at the most superficial level, the form is given a better appearance, instead of some plain XHTML. Additionally, the served pages can be substituted with something else by using an entry in the configuration value, altough with some limitations. The page listing all the registered zones has been removed in favour of a search function. A configuration entry could've been used to let service operators choose between showing the full listing or not, but at the same time, being presented with a (possibly) giant list of names is not that great from a usability point of view. Having a search function is, at the very least, faster than having to wait for the full list to be displayed before being able to use the user agent's page search feature. Other than the above, people registering names with the service might not want to be known by everyone. Even though checking if a certain name or key was registered already can be known simply by querying the service, it's not straightforward to associate a name with a specific key (or viceversa). Last but not least, the service was restructured to be more "route-oriented" instead of the traditional (X)HTML document format. The main purpose of this change is to decouple usage of the service from the tools used to access it. With a traditional document, users are pretty much forced to use a web browsers as data submission is carried through the standard HTML form handling. Now, it is possible to access the service using any tool capable of speaking HTTP, regardless of wether it's a web browser, cURL or even a custom tool specific for this service. Another advantage of this approach is that it allows adding "layers" to the service, for example an authentication check before letting users register a name. As long as the layer immediately on top of the service is able to send some JSON using HTTP, there is no need to have users access the service itself: just put a "proxy" inbetween and run the service locally, while the proxy handles other administrative tasks before a name can be registered. By using layers, the service can keep being small feature-wise (i.e. provide only searching and registering), while everything else is provided by other applications, including access through protocols other than HTTP.
Diffstat (limited to 'contrib/fcfsd/fcfsd-notfound.html')
1 files changed, 11 insertions, 0 deletions
diff --git a/contrib/fcfsd/fcfsd-notfound.html b/contrib/fcfsd/fcfsd-notfound.html
new file mode 100644
index 000000000..676bf4a9a
--- /dev/null
+++ b/contrib/fcfsd/fcfsd-notfound.html
@@ -0,0 +1,11 @@
+<!DOCTYPE html>
+<html lang="en">
+ <head>
+ <meta charset="utf-8"/>
+ <meta name="viewport" content="width=device-width, initial-scale=1.0">
+ <title>Not Found - GNUnet FCFS Authority Name Registration Service</title>
+ </head>
+ <body>
+ <h1>The requested resource could not be found</h1>
+ </body>