The following is one of the examples to reproduce.
$ go doc Net/HttP/httpTEST.DefaultRemoteAddr
What did you expect to see?
According to https://go.dev/blog/package-names, lowercase is recommended in Go,
so I think that the output should also follow it.
Thus I was expecting that the go doc will return an error(like not_found_error)
or the output which converted to lowercase.
What did you see instead?
The following is the actual output.
The import path import "Net/HttP/httpTEST" is not a recommended style.
package httptest // import "Net/HttP/httpTEST"
const DefaultRemoteAddr = "184.108.40.206"
DefaultRemoteAddr is the default remote address to return in RemoteAddr if
an explicit DefaultRemoteAddr isn't set on ResponseRecorder.
This problem seems to occur in cases where the passed arguments are passed directly to build.Import function.
I don't know if this is the intended behavior, but it is because the build.Import function treats path as case-insensitive.
I looked at the GoDoc for golang.org/x/mod which you posted and found a few things I hadn't considered.
Also, as you may already know, let me summarize the possible cases of this issue and expected behavior again as follows.
This issue is only possible with case-insensitive file systems such as macOS. For example, the following returns the correct result.
$ docker run --rm -it golang:1.17 go doc NET/HTTP
doc: package NET/HTTP is not in GOROOT (/usr/local/go/src/NET/HTTP)
exit status 1
On top of that, this issue should only occur for the following two cases:
search for standard packages (i.e., args are like NET/HTTP or STRINGS.Replace)
search for packages in relative path (i.e., args are like ./AUTH or ../GOLANG/MOCK/GOMOCK)
Based on the above, we hope that the behavior of go doc will be able to handle correct import paths by validating arguments even if the filesystem is handled case-insensitively.
For case 1, the standard library is always in lowercase as far as I know, so I think forcing the conversion to lowercase is not bad idea, but for case 2, I can't think of an appropriate way to validate...
And in this case, it should not be possible to use module#EscapePath to make a decision since it is not in GOMODCACHE and is not escaped.