go-swagger throws error on Windows if application path contains parentheses or blanks

[agmikhailov]

STEPS TO REPRODUCE

Run application from e.g. standard Windows path like "C:\Program Files (x86)\AppName".

ACTUAL RESULT

panic: Invalid schema provided to SchemaValidator: open c:\program files (x86)\AppName\.root: The system cannot find the file specified.
goroutine 6 [running]:
github.com/go-openapi/validate.NewSchemaValidator(0xc000422000, 0xb86960, 0xc0000ca900, 0xc000405d10, 0x4, 0xcfbba0, 0xc00015f1d0, 0x0, 0x0, 0x0, ...)
        AppName/pkg/mod/github.com/go-openapi/validate@v0.20.2/schema.go:72 +0x100a
github.com/go-openapi/runtime/middleware.newUntypedParamBinder(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
       AppName/pkg/mod/github.com/go-openapi/runtime@v0.19.26/middleware/parameter.go:47 +0x198
github.com/go-openapi/runtime/middleware.NewUntypedRequestBinder(0xc0004ab0b0, 0xc0000ca900, 0xcfbba0, 0xc00015f1d0, 0xc0004ab110)
        AppName/pkg/mod/github.com/go-openapi/runtime@v0.19.26/middleware/request.go:40 +0x14f
github.com/go-openapi/runtime/middleware.(*defaultRouteBuilder).AddRoute(0xc000079c78, 0xbf2c66, 0x4, 0xc00049dee0, 0x6, 0xc0000d5180)
       AppName/pkg/mod/github.com/go-openapi/runtime@v0.19.26/middleware/router.go:442 +0x600
github.com/go-openapi/runtime/middleware.DefaultRouter(0xc00004bc70, 0xcfdca0, 0xc0003ca4e0, 0xb69580, 0xc0004a4dc0)
        AppName/pkg/mod/github.com/go-openapi/runtime@v0.19.26/middleware/router.go:141 +0x15b
github.com/go-openapi/runtime/middleware.NewRouter(0xc0004aa900, 0xce90c0, 0xc0004a4dc0, 0xc0004a4dc0, 0xc2e890)
        AppName/pkg/mod/github.com/go-openapi/runtime@v0.19.26/middleware/router.go:73 +0xe9
github.com/go-openapi/runtime/middleware.(*Context).RoutesHandler(0xc0004aa900, 0xc2da48, 0xc2e860, 0xc2e858)
        AppName/pkg/mod/github.com/go-openapi/runtime@v0.19.26/middleware/context.go:621 +0x84
github.com/go-openapi/runtime/middleware.(*Context).APIHandler(0xc0004aa900, 0x0, 0x0, 0x0)
        AppName/pkg/mod/github.com/go-openapi/runtime@v0.19.26/middleware/context.go:612 +0x102
..........
AppName code

EXPECTED RESULT

You can place GO application in paths with parentheses or blanks.

ROOT CAUSE

Parentheses in paths are encoded in schemaLoader cache but they are compared with not encoded paths in the "func (r *schemaLoader) load(refURL *url.URL)". Possible fix is:

func (r *schemaLoader) load(refURL *url.URL) (interface{}, url.URL, bool, error) {
	debugLog("loading schema from url: %s", refURL)
	toFetch := *refURL
	toFetch.Fragment = ""

	var err error
	pth := toFetch.String()
	normalized := normalizeBase(pth)
	debugLog("loading doc from: %s", normalized)

+	unescaped, err := url.PathUnescape(normalized)
+	if err != nil {
+		return nil, url.URL{}, false, err
+	}

+	u := url.URL{Path: unescaped}

-	data, fromCache := r.cache.Get(normalized)
+	data, fromCache := r.cache.Get(u.RequestURI())
	if fromCache {
		return data, toFetch, fromCache, nil
	}

[ChandanChainani]

@agmikhailov Please can you close the ticket since the fix for the issue has been merged.

[fredbi]

I've inspected the fix (commit e8e27ff) and it is dubious. Would require another round of more thorough testing here. On it.

[fredbi]

@agmikhailov
I've attempted unsuccessfully to reproduce this issue. I am missing some context.
What I can assert is that:
* go-openapi/spec (unpatched) can load on windows (or unix) with "(" or blanks in space (or other escape characters)

• go-openapi/validate can validate a spec on such a path
• the patch from commit e8e27ff disables the cache in some cases by removing the scheme when loading documents

I understand this patch made things work for your use case, but the root cause lies in some other part of go-openapi (perhaps go-openapi/loads, perhaps go-openapi/runtime).

Could you please expose more details about the failing app mentioned above, so I get a change to understand how the failing spec got to be loaded in the first place into the runtime shown in the stack?

[fredbi]

@agmikhailov , cc: @casualjim , @ChandanChainani

I've tried to reproduce this, building a server on windows 11 with go-swagger, pinning a version of go-openapi/spec without the change that came with commit e8e27ff (with --exclude-spec) and loading it from a path just like the one suggested by the O.P.

The server starts just fine and validates the spec when starting the runtime middleware stack as expected.

I am not denying that a problem may occur, but the root cause analysis provided with this issue is not correct.

Therefore, I am proposing:

• a patch to revert the change from this commit
• a change to ensure that we never have to open the root pseudo-root document: we should never get something like : open c:\program files (x86)\AppName.root: The system cannot find the file specified.
• I assume that what is wrong in this issue is the way the spec document is being loaded. I've inspected go-openapi/loads, but nothing could trigger the aforementioned panic.