2

We have a web API service running that uses attribute routing. When a request is sent with the route not containing a file extension it routes to the correct action evaluating the query string correctly. When we have a route that contains a file extension if you do not include a '/' before the query identifier then you get a 404 Not Found.

For example:

Working:

https://example/api/interview/test/70ac327a-d77b-41da-bf9c-76af8efdfbbaf/Test.docx/?format=Unspecified

Not Found:

https://example/api/interview/test/70ac327a-d77b-41da-bf9c-76af8efdfbbaf/Test.docx?format=Unspecified

It is probably also worth noting that the route parameter with the file extension is optional.

An example route is:

[HttpPost]
[Route("api/HDCS/Interview/{subscriberId}/{packageId}/{templatename?}")]
public IHttpActionResult Interview(string subscriberId, string packageId, string format = null,
    [FromUri] IEnumerable<string> markedVariables = null, string templatename = null,
    bool encodeFileNames = false, string retrieveFromHub = null){...}

Edit:

Sorry I also should have mentioned that we have

<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
    <handlers>
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <remove name="OPTIONSVerbHandler" />
      <remove name="TRACEVerbHandler" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>

in our web.config

1 Answers1

2

I didn't include one very important piece of information when explaining our API which was needed when fixing this issue. We are using OWIN and to ensure that the OWIN module actually passes the URL's with extensions in the route onto WebApi we had to add to our Startup.cs file:

        builder.UseWebApi(config);
        builder.UseStageMarker(PipelineStage.MapHandler); // this line

This has resolved the issue and we no longer get 404's when using the route detailed in the question.

Source for fix: https://github.com/domaindrivendev/Swashbuckle/issues/57