New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Web API 2 using Owin middle-ware #57
Comments
Hey there Thanks for your support and in particular for using Swashbuckle under a scenario that admittedly has not been documented to this point. OWIN definitely appears to be the way forward and so your ticket prompted me to do some much needed research and figure out the best approach. I've added some notes to the readme - Getting Started section. Here's the summary: Swashbuckle serves it's embedded UI files via a Web API HttpHandler. The URL's for these resources all have extensions (e.g. .html, .js, .css etc.). However, IIS also has a native static file handler which kicks in early in the process, prior to the OWIN module, and assumes these to be static files. It attempts to handle them itself and then bypasses remaining parts of the pipeline including the OWIN module and hence WebApi. To get around this, you'll need to ensure the OWIN module is run for all requests - extension and extensionless by placing the following line in your Web.config:
In addition, you'll also need to ensure that the OWIN module actually passes the URL-with-extension requests onto WebApi. This is done by adding a stage marker AFTER configuring the WebApi middleware (in namespace Microsoft.Owin.Extensions) in Startup.cs:
Check out the following for more info on stage markers: (https://katanaproject.codeplex.com/wikipage?title=Static%20Files%20on%20IIS) Let me know if this resolves your issue? |
Using It would be better to not force this across the board, and instead use: <handlers>
<add name="Swashbuckle-Swagger" verb="*" path="swagger/*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0"/>
</handlers> This change routes only the requests in the /swagger/ UI routing path through the managed modules. |
Awesome - thanks for the tip. I'll update the docs ASAP |
Hi, Date: Thu, 28 Aug 2014 08:28:37 -0700 Closed #57. — |
Hi there Saw your blog post. I had meant to get in touch and thank you - it's awesome! You can contact me directly at domaindrivendev@gmail.com Cheers Richie |
Thanks for this interesting project, I've tried to integrate your plugin with this web API 2 https://github.com/tjoudeh/AngularJSAuthentication/tree/master/AngularJSAuthentication.API which is IIS hosted and uses owin middleware but It didn't work out correctly.
What I've done is the following:
Once I Moved Swashbuckle.Bootstrapper.Init(config); to owin Startup class and commented out the implementation in SwaggerConfig file the url http://localhost:26264/swagger/api-docs returned list of the API but there was no UI (it returns 404).
Once I kept calling Swashbuckle.Bootstrapper.Init(config) from 2 places (Startup & SwaggerConfig) classes it worked correctly but I believe it is not correct to fire up the init method twice.
It will be great if you were able to check my API and tell me what is the right to integrate it using Web API 2 with own middle ware.
The text was updated successfully, but these errors were encountered: