go-swagger throws error on Windows if application path contains parentheses or blanks about spec HOT 4 CLOSED

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

from spec.

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

from spec.

@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?

from spec.

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

from spec.