Best practices in Gemini servers

1. Sean Conner (sean (a) conman.org)


  To get away from the text formatting argument (which I think comprises
over half the messages so far) I thought I might ask for some guidelines as
to the best practice for Gemini servers.  I came up with these as I was
reworking my Gemini server (getting ready to release it, as I've had one
person already request a copy).  So here we go:

  I have this bit of code to check the request:

	  if loc.scheme ~= 'gemini'
	  or loc.host   ~= CONF.network.host
	  or loc.port   ~= CONF.network.port then
	    log(ios,59,"",reply(ios,"59\t",MSG[59],"\r\n"))
	    ios:close()
	    return
	  end

  I'm currently returning a "Bad Request" for this, if the protocol, host
and port don't match what is currently configured on my server.  The other
possible status is "Proxy Request Refused".  My server doesn't do proxy
requests.  What should the proper status code be?  Is "Bad Request" fine
here?

  Next.  Each request is run through a series of checks to see if a resource
has moved or is gone:

	redirect =
	{
	  permanent = { ... } -- list of permenent redirects
	  temporary = { ... } -- list of tempoarary redirects
	  gone      = { ... } -- list of gone items
	}

  For any given list, it's checked in the order presented, but the ordering
of the major sections is currently defined as: temporary, permanent then
gone.  I keep going back and forth if this shouldn't be: gone, permanent,
temporary or even if it matters.

  Next.  The actual order of things is:

	read request
	check redirects
	check authorization
	check handlers

  Each of the checks consist of the path matched against a pattern, and the
first match wins.  So for instance (the path fields, for instance, are Lua
patterns---think regex):

	redirect =
	{
	  permanent =
	  {
	    { '^/source%-code


     , "/sourcecode/"   } ,
	    { '^/source%-code/(.*)' , "/sourcecode/$1" } ,
	  }
	},

	authorization =
	{
	  {
	    path   = '^/private/',
	    status = 61,
	    check  = function(issuer,subject,url) ... end,
	  },
	
	  {
	    path   = '^/conman%-labs%-private/',
	    status = 62,
	    check  = function(issuer,subject,url) ... end,
	  },
	},

	handler =
	{
	  {
	    path   = '^(/hilo/)(.*)',
	    module = "hilo",
	  },
	
	  {
	    path   = '^/test/wrap(%;?(%d*))',
	    module = "wrap",
	  },
	
	  {
	    path      = ".*",
	    module    = "filesystem",
	    directory = "gemini.conman.org",
	    no_access =
	    {
	      "^%.",  -- no to any dot files
	      "%~$",  -- no to any backup files
	    },
	  },

  So given a path like "/private/Welcome.txt", there are no redirects that
match, so it's not redirected.  It does match one of the authorization
patterns, so a check for the certificate is made, and if it passes that
(it's done that way so that the individual handlers don't have to handle
authentication themselves), then it goes through the handlers to match the
last one, pointing to the "filename" handler.  My question here, or more of
a concern really, is I think I have the ordering wrong---I think I should
check authorization first before redirection checking, because not doing so
may lead to leaking of protected resource names.

  So my question here, does it make sense to have the order be:

	check request
	check authorization
	check redirection
	check handlers

to prevent possible leaking of data?  I'm thinking yes, but wouldn't mind
seeing a discussion.

  -spc (So anyway, back to our regularly schedule talk on text formatting ... )

Link to individual message.

2. Jason McBrayer (jmcbray (a) carcosa.net)

Sean Conner <sean at conman.org> writes:

>   I'm currently returning a "Bad Request" for this, if the protocol, host
> and port don't match what is currently configured on my server.  The other
> possible status is "Proxy Request Refused".  My server doesn't do proxy
> requests.  What should the proper status code be?  Is "Bad Request" fine
> here?

In my opinion, the Most Correct response to return would be "Proxy
Request Refused". If they had made the same request to a the right
server or if this server had been configured differently, it would have
succeeded, so the request isn't malformed or anything. But Bad Request
is probably the next-best response; Not Found would also make a kind of
sense. 

>   So my question here, does it make sense to have the order be:
>
> 	check request
> 	check authorization
> 	check redirection
> 	check handlers
>
> to prevent possible leaking of data?  I'm thinking yes, but wouldn't mind
> seeing a discussion.
>

I think this is good. I don't know that there's an equivalent best
practices in HTTP; I think this is all pretty implementation-defined. 

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

Link to individual message.

3. Sean Conner (sean (a) conman.org)

It was thus said that the Great Jason McBrayer once stated:
> Sean Conner <sean at conman.org> writes:
> 
> >   I'm currently returning a "Bad Request" for this, if the protocol, host
> > and port don't match what is currently configured on my server.  The other
> > possible status is "Proxy Request Refused".  My server doesn't do proxy
> > requests.  What should the proper status code be?  Is "Bad Request" fine
> > here?
> 
> In my opinion, the Most Correct response to return would be "Proxy
> Request Refused". If they had made the same request to a the right
> server or if this server had been configured differently, it would have
> succeeded, so the request isn't malformed or anything. But Bad Request
> is probably the next-best response; Not Found would also make a kind of
> sense. 

  Hmmm ... if my sever did any proxying, then yes, "Proxy Request Refused"
would make sense.  "Not found" doesn't, because the resource could be found,
not just through me.  

  I suppose I could serve up "Proxy Request Refused" ... 

> >   So my question here, does it make sense to have the order be:
> >
> > 	check request
> > 	check authorization
> > 	check redirection
> > 	check handlers
> >
> > to prevent possible leaking of data?  I'm thinking yes, but wouldn't mind
> > seeing a discussion.
> >
> 
> I think this is good. I don't know that there's an equivalent best
> practices in HTTP; I think this is all pretty implementation-defined. 

  I only thought of that as I refactoring my server code.  I think I will
make that change as it feels right to me as well.  Thanks.

  -spc

Link to individual message.

4. Michael Lazar (lazar.michael22 (a) gmail.com)

On Tue, Sep 10, 2019 at 3:35 PM Sean Conner <sean at conman.org> wrote:
> It was thus said that the Great Jason McBrayer once stated:
> > Sean Conner <sean at conman.org> writes:
> >
> > >   I'm currently returning a "Bad Request" for this, if the protocol, host
> > > and port don't match what is currently configured on my server.  The other
> > > possible status is "Proxy Request Refused".  My server doesn't do proxy
> > > requests.  What should the proper status code be?  Is "Bad Request" fine
> > > here?
> >
> > In my opinion, the Most Correct response to return would be "Proxy
> > Request Refused". If they had made the same request to a the right
> > server or if this server had been configured differently, it would have
> > succeeded, so the request isn't malformed or anything. But Bad Request
> > is probably the next-best response; Not Found would also make a kind of
> > sense.
>
>   Hmmm ... if my sever did any proxying, then yes, "Proxy Request Refused"
> would make sense.  "Not found" doesn't, because the resource could be found,
> not just through me.
>
>   I suppose I could serve up "Proxy Request Refused" ...

On Tue, Sep 10, 2019 at 3:35 PM Sean Conner <sean at conman.org> wrote:
> It was thus said that the Great Jason McBrayer once stated:
> > Sean Conner <sean at conman.org> writes:
> >
> > >   I'm currently returning a "Bad Request" for this, if the protocol, host
> > > and port don't match what is currently configured on my server.  The other
> > > possible status is "Proxy Request Refused".  My server doesn't do proxy
> > > requests.  What should the proper status code be?  Is "Bad Request" fine
> > > here?
> >
> > In my opinion, the Most Correct response to return would be "Proxy
> > Request Refused". If they had made the same request to a the right
> > server or if this server had been configured differently, it would have
> > succeeded, so the request isn't malformed or anything. But Bad Request
> > is probably the next-best response; Not Found would also make a kind of
> > sense.
>
>   Hmmm ... if my sever did any proxying, then yes, "Proxy Request Refused"
> would make sense.  "Not found" doesn't, because the resource could be found,
> not just through me.
>
>   I suppose I could serve up "Proxy Request Refused" ...

My server returns NOT FOUND only because it made the implementation simpler &
cleaner to use the same response code for all unmatched URLs. Either the server
can locate the resource specified by the given URL, or it can't. It feels
arbitrary to make a distinction on whether it's the path component or the
hostname or the scheme that doesn't match. Perhaps I should be using PERMANENT
FAILURE instead since it's the more general 5x error code.

Link to individual message.

---

Previous Thread: Defining sections in Gemini maps?

Next Thread: Fwd: elpher now supports gemini