URLs in request lines

[Sean Conner]

It was thus said that the Great plugd once stated:
> Hi all,
> 
> This question occurred to me when debugging some 5x error responses from
> servers: how strictly are servers expected to be when responding to
> requests?  In particular, if a client is given a URL such as
> 
> gemini://example.com
> 
> (i.e. with an empty file name) is it expected to translate it into
> 
> gemini://example.com/  ?

  Yes.  In RFC-3986, if you follow the BNF, you'll find this bit:

   URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

   hier-part     = "//" authority path-abempty
                 / path-absolute
                 / path-rootless
                 / path-empty

   path-abempty  = *( "/" segment )

  When parsing a URL like:

	gemini://example.com

we have the 'scheme' portion, then the two '//' which means we're following
the first rule in 'hier-part'.  'authority' is the host part (which I didn't
include) followed by a 'path-abempty', of which there can be 0 or more of,
so that's a perfectly cromulent URL.  It's the responsibility of the
*server* to handle the situation, not the client.

  Semantically speaking, these:

	gemini://example.com
	gemini://example.com/

are the same.

  A related problem is a relative URL like:

	/test/torture/../../test/./torture/../../../../test/./././torture/./0022

  That collapses down to:

	/test/torture/0022

but in this case, I think it would be the responsibiliy of the *client* to
collapse the first into the second (and then add the scheme, host, etc.).  I
know my own server does the collapsing, but I think I may change that.

  -spc