URLs in request lines

[plugd]

Sean Conner writes:
> 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:

[snip]

Great, thank you for the explanation.  (I should have RTFM, sorry!)

>
> 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.

Converting to this canonical form actually makes several things easier
on the client side too.

>   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.

Fair enough.  The URL library elpher uses doesn't automatically do this,
but it seems simple enough to do (famous last words)..

Thanks for the help,

plugd