Improved relative path checking based on file existence

[NoahLerner]

If the file exists at the relative path, then use it. If not, then use the path as is.

This is stronger than the previous check if the path is just the filename, since if it's just a file name then we'll check if the file exists at the relative path & then use if yes. Otherwise, use the path as is.

[NoahLerner]

Before this fix, providing a relative path failed. For example:

If we have a folder at
__admin\mappings\myresponses\myresponse.xml

Then the only way to reach this file was by providing an absolute path. Since if the user provided
\myresponses\myresponse.xml
then it would fail the first check (path != filename) and not create the relative path. Then it would go on to return 500 internal server error since the provided path is not a valid path.

[NoahLerner]

@StefH How is it that my unit tests are all passing locally but failing on the CI? Any idea?

[StefH]

I've 2 CI builds

• Windows
• Linux

And it seems that Linux is failing:

Now listening on: https://0.0.0.0:37351
  X WireMock.Net.Tests.ResponseBuilders.ResponseWithBodyFromFileTests.Response_ProvideResponse_WithBodyFromFile [5s 117ms]
  Error Message:
   System.Net.Http.HttpRequestException : Response status code does not indicate success: 500 (Internal Server Error).
  Stack Trace:
     at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
   at System.Net.Http.HttpClient.GetStringAsyncCore(Task`1 getTask)
   at WireMock.Net.Tests.ResponseBuilders.ResponseWithBodyFromFileTests.Response_ProvideResponse_WithBodyFromFile() in /home/vsts/work/1/s/test/WireMock.Net.Tests/ResponseBuilders/ResponseWithBodyFromFileTests.cs:line 39
--- End of stack trace from previous location where exception was throw

I think the private string CleanPath(string path) method is not correct.
You need to use the correct slash character for the correct operating system.
So do not define it yourself, but use Path.DirectorySeparatorChar

[NoahLerner]

Great tip! Thank you.

I think this syntax will be good enough to support both platforms:

path = path.Replace(Path.AltDirectorySeparatorChar, Path.DirectorySeparatorChar);

Also, the build is still failing and I think wrapping the return statement of public string GetMappingFolder will fix it. Does that make sense?

https://docs.microsoft.com/en-us/dotnet/api/system.io.path.combine?view=netframework-4.8#System_IO_Path_Combine_System_String_System_String_

[StefH]

The best is to move this Clean path logic to a new class. Like: internal static class PathUtils

And the logic should be :

1. replace any \ by the defined system (= Path.DirectorySeparatorChar)
2. replace any / by the defined system (= Path.DirectorySeparatorChar)

After the above logic:
3. if the string starts with a Path.DirectorySeparatorChar), remove that one.

Does this make sense?

[StefH]

• please see comments
• and the CI Linux still fails it seems?

[NoahLerner]

Linux CI keeps failing. It started failing on 9bc737f when I tried dealing with slashes.

[NoahLerner]

The issue was in removing the leading directory separator character, the absolute path on Linux systems (which begins with such a character) was broken. I moved the "remove leading dir sep char" logic inside Path.Combine call so it's called only when absolutely necessary as an extra defense against users who provide paths with leading \ or /.

[NoahLerner]

I don't seem to be able to approve this to resolve the merge conflicts.

[StefH]

ok

[StefH]

I'll merge this one now to master.

For that Delete RestApi change :

• please make a PR and also try to test this new logic.
• And I think your PR Admin Delete with mappings in body is also deleted, so make a new PR for this