Should I use URL encoding for doi links, or does it matter?

Question

I summarize research articles of interest to my readers, for example at https://www.ptsdexams.net/disability-exams-research.html .

I usually include the Digital Object Identifier (doi), either by itself, e.g., doi:10.1007/s12207-019-09367-5 or as a link, e.g., https://doi.org/doi:10.1007/s12207-019-09367-5.

I noticed today that a link contained unusual characters (for a doi link), that I learned is URL encoding to a valid ASCII format, specifically %2F instead of a forward slash (/).

I also noticed that if I use the URL without the URL encoding, it still works, although Chrome converted the URL, as did Microsoft Edge.

https://doi.org/10.1007/s12207-019-09349-7 → https://doi.org/10.1007%2Fs12207-019-09349-7

Firefox and Opera did not convert the URL, although either URL worked on those browsers.

It seems to my less-knowledgeable mind that it does not make a difference which URL I use on my website, but I want to ask the experts to make sure. Thus, my question: Should I use URL encoding for doi links, or does it matter?

Notes

(1) I did search for other posts about this topic. The two most similar posts were How to remove %2F from the URL? and How to get rid of crawling errors due to the URL Encoded Slashes (%2F) problem in Apache

(2) Browser versions I used:

Chrome 84.0.4147.125 (Official Build) (64-bit)

Microsoft Edge 84.0.522.59 (Official build) (64-bit)

Firefox 79.0 (64-bit)

Opera 70.0.3728.106

Answer 1

In general, slashes in the URL path don't need to be encoded. Depending on the server configuration, a slash could have a different meaning than %2F in the file path. The Apache web server by default serves a 404 if directory slashes in the URL are converted to %2F.

It is really up to the web site itself whether or not the URL path should have / or %2F. So let us look at doi.org:

• The example URL on their home page (https://doi.org/10.1109/5.771073) uses a slash

• Fetching either the version of the URL with the slash or the %2F works

• When the URL is redirected it is redirected to a URL with a slash, regardless of whether the requested URL has the slash encoded:

   curl --head https://doi.org/10.1007%2Fs12207-019-09349-7
   HTTP/2 302 
   location: http://link.springer.com/10.1007/s12207-019-09349-7
  

While that site has configured their servers to work regardless of whether or not the slash is encoded, it it clear that the unencoded slash is the preferred, intended canonical URL. I would link to them with the literal slash rather than the encoded version.