DEV Community: Jim Buck

Demystifying the ASP.NET Core Request Pipeline: Part 1 - Receiving Requests

Jim Buck — Fri, 12 Jul 2019 18:31:01 +0000

This is Part 1 of a 3 part series on the ASP.NET Core Request Pipeline. Check back here for links to the follow-up articles!

Preface
Part I - Receiving Requests
Part II - Coming Soon
Part III - Coming Soon

For many developers the area between a browser request and a controller action is a land a of mystery and magic. Any why shouldn't it be? In MVC/WebAPI and ASP.NET Core convention is king when it comes to routing and controllers. As long your naming scheme follows convention, you can safely expect requests to magically hit your code.

But what happens when you don't follow convention? Or when you need to support a more complex configuration that is not provided by out-of-the-box project templates? Don't be afraid, the request pipeline doesn't have to be a black box. And having a solid understanding of the request pipeline can take you from zero to hero by the end of the sprint.

In this article I break down of each type of server implementation and outline their differences. Check out the tl;dr table at the end for a quick summary. After that I outline some common scenarios and which implementation is best suited for the job.

Server Implementations

When it comes to web apps, something must be listening on a port (typically 80 or 443) to receive the request. Listening for and maintaining connections to requests are the primary responsibilities of a web server. When it comes to ASP.NET Core, there are a few implementations and hosting models that each have their own benefits.

Standalone with Kestrel

Standalone Kestrel

Kestrel is the light-weight, cross-platform web server built specifically for ASP.NET Core. It's open source, can easily exceed 1M+ practical requests per second, and is the default when starting a new project for ASP.NET Core 3. Kestrel will listen on the specified hosts/ports and runs right within your web app.

Once connections are made, the requests are handled directly by the request pipeline. It's a great option to use for new projects since there are no additional dependencies and, even better, it works on Windows, Mac, AND Linux! I highly recommend using Kestrel during development and for open source projects.

Out-of-Process with IIS and Kestrel

Out-of-Process IIS with Kestrel

When building enterprise server applications that run on Windows, you almost always will rely on the de facto web server: IIS. Originally released for Windows NT and rewritten for Windows Server 2008, it's currently on version 10 and provides stability, security, and management tools for production applications. To say that IIS has been battle tested is a massive understatement. And any enterprise developer/IT professional has probably relied on IIS at some point in there career.

IIS Out-of-Process hosting uses IIS as a reverse proxy that forwards requests to your ASP.NET Core app running on Kestrel (thanks to the ASP.NET Core Module). The primary benefit to this setup is the ability to host and configure a mix of .NET Framework and .NET Core apps. This simplifies configuration for things like SSL, caching, and authentication since they can be shared across applications.

Other reverse proxies can also be used (Apache for Windows/Linux, and Nginx for Linux). While they do provide support for other platforms, IIS provides dedicated support which will result in the best experience.

In-Process with IIS

In-Process IIS

Starting with ASP.NET Core 2.2 if you app targets .NET Core (not the full .NET Framework) then you can take advantage of in-process hosting. This means that the IIS worker process (w3wp.exe) actually loads up the CoreCLR and your ASP.NET Core app in the same process. This enables faster time to first byte by allowing requests to be passed directly into the pipeline!

This is improved performance does come at a cost. Only one application can be used per IIS Application Pool and there is no support for .NET Framework. But the benefit is 2x-3x improved requests per second.

HTTP.sys

HTTP.sys is a Windows-only web server focused on security and additional features (compared to Kestrel). Prior to ASP.NET Core 2.0, Kestrel was not secure enough to expose directly to the public internet. HTTP.sys allowed apps to be accessible on the public web without the need for IIS. Additionally it provides a few features not available to Kestrel, such as Windows Authentication.

Custom OWIN-based Server

Custom OWIN Server

Custom servers can be used in the off chance that a feature is not supported in Kestrel/IIS or HTTP.sys. Conforming to the Open Web Interface for .NET (OWIN), these servers implement a set of interfaces used to manage and interact with ASP.NET Core apps. You can learn about the IServer interface and how to implement it here.

tl;dr

Server Implementation	Notes
In-process with IIS	Maximum Performance, but for Windows only.
Kestrel (standalone)	Lightweight and cross-platform.
Out of process IIS with Kestrel	Host alongside existing .NET Framework apps.
HTTP.sys	Advanced features, Windows only.
Custom OWIN Server	Complete control, highest complexity.

Summary of Server Implementations

Which Implementation is right for me?

The following scenarios are just a few possible cases to consider. Your specific project might have special circumstances or specific requirements from your organization.

Open Source Project

Kestrel (standalone) is probably your best bet. The two main benefits for open source projects is cross-platform support and super simple workflow ( no messing with IIS Express ). While cross-platform is not a requirement for open source projects, there is nothing more annoying than finding a good project that doesn't have support for your platform. Now a simple developer workflow is something that we should all strive for, but not always obtainable. Regardless using standalone Kestrel is without a doubt the best option for new open source projects.

Enterprise Project with Legacy Apps

In most enterprise scenarios, legacy applications must be considered when building new applications. Some companies/administrators have strict rules on how sites get hosted. IIS can easily host new and legacy apps together, but you have to consider 2 things.

If performance (speed and memory usage) are important, then In-Process with IIS is the way to go. By letting IIS load and execute the ASP.NET Core application, reverse proxy HTTP calls are avoided and request data is shared in memory. This results is faster response times and reduced memory consumption.
If sharing AppPools is important, then use Out-Of-Process with IIS. IIS will act like a reverse proxy, which allows you to share AppPools between legacy apps and new apps. Your ASP.NET Core app will have a Kestrel server running, but will be completely managed by IIS. While this does slow down the request speed, it does provided benefits around shared security, availability , etc.

Greenfield Project

For brand new projects, Kestrel (standalone) is your best place to start. Kestrel provides a lightweight server for easy development, allowing your team to spend more time focusing on building the app. If you are developing for Windows-only and using IIS, then consider deploying with IIS In-Process. In addition to an easier configuration, you will find less memory usage and faster response time.

High Performance Project

If you need to squeeze every ounce of performance out of your tech stack, then believe it or not but Kestrel (standalone) is probably your best bet. The ASP.NET team has put in a tremendous amount of effort to make Kestrel a top tier web server when it comes to requests per second. The key to keeping your server performant is through the use of custom middleware instead of the "general use" implementations used by most projects. Kestrel, when stripped down to simple text-based requests, can handle about 6 MILLION requests per second. With some smart authentication and body parsing optimized for your domain, you would be surprised at how fast Kestrel can fly.

Not Sure?

Without a doubt the first server to try is Kestrel (standalone). With complete security implementation (ASP.NET Core 2.0 and beyond) and a highly dedicated team pushing its performance to the max, most projects will be perfectly happy relying on Kestrel. The best part is that you can use standalone Kestrel during development and deploy with IIS In-Process or Out-of-Process with just a few configuration changes.

Conclusion

All projects, big or small, benefit when starting off on the right foot. Plan ahead and learn about the options you have available when it comes to project architecture. The most difficult projects don't always have the most complex logic; they have the least amount of high-level planning.

Keep an eye out for Part 2 of this series on the ASP.NET Core Request Pipeline. It will dive into the details of pipeline configuration and MVC middleware!

Questions? Comments? Disagreements? Hit me up on Twitter!

Demystifying the ASP.NET Core Request Pipeline: Preface

Jim Buck — Tue, 09 Jul 2019 19:48:47 +0000

This is Part 0 of a 3 part series on the ASP.NET Core Request Pipeline. Check back here for links to the follow-up articles!

Every day we use products and services that we could consider a "black box". Look at cell phones for example. Most people (myself included) have absolutely no grasp of exactly how two people can be connected when thousands of miles apart. Scott Hanselman eloquently phrases it as "each new layer of abstraction becomes indistinguishable from magic". Life would be pretty rough if we could only use things we had a complete technical understanding of.

But there are times when learning about that "magic" can provide a ton of value. It could be as simple as having a better understand when problems hit, which could save you time and frustration. Or it could help steer your logic away from potentially problematic scenarios, improving performance and avoiding security nightmares.

When working with ASP.NET it's very easy to get started and just breeze over the architecture details. In this series I am going to dive into the ASP.NET Core Request Pipeline from start to finish. I will cover everything from hosting models and pipeline fundamentals to building your own custom middleware. While I will focus on ASP.NET Core 2.2 and beyond, the same general tips should also apply to any OWIN based app , even in ASP.NET MVC5.

I hope you enjoy the series and get to learn something new! If you have any comments or questions hit me on Twitter! Follow me to get notified about the next part!

Contributing to OSS: Getting Started

Jim Buck — Thu, 09 May 2019 01:56:44 +0000

One of the most beautiful aspects to software development is having the opportunity to contribute to Open Source Software. For a long time I wanted to contribute to a library or framework that I used every day.

The only problem was that every time I had the motivation to try, I easily got intimidated by what seemed like a high-pressure situation (spoiler alert: it doesn't have to be). By starting small and staying focused, making your first PR for a widely used project can be both fun and beneficial for the community.

Jon Galloway

@jongalloway

Talked to @jimbuckio Monday night about how to get started contributing to @dotnet open source by contributing small fixes to @docsmsft. He stopped by the .NET Open Source booth to tell me his first pull request had just been merged. #MSBuild

19:14 PM - 08 May 2019

0 5

So after chatting with Jon Galloway of the .NET Foundation, I sat down and fixed an issue that I had discovered in the ASP.NET Core documentation. I created my pull request and the next morning I woke up to it already merged in! It's not always that easy, but follow these simple steps and you'll be a well-respected contributor in no time.

Step 1: Find an Issue

Although it may seem obvious, the most important step is finding a issue. And not just any issue, a good issue. What makes an issue good? Just find something that seems wrong and ask yourself these questions:

Is there a clear and obvious reason for the change? If a change fixes a breaking bug, then it is a fix worth pursuing. If there is indisputable evidence that a section of documentation is wrong, then a fix is worth pursuing. The key is making sure that the motivation for the change is shared among users and maintainers alike. If you want to make a change to the API because you think it will be better, then maybe you should start by creating an issue to first get some input from the maintainers before spending more time on it.
Can you fix it in a clean and concise way? To some people refactoring/rewriting can be a cathartic exercise. But just because you feel better after a rewrite doesn't mean it was a good idea. Keeping the changes minimal and specific will help in two ways. The first is that it will keep your changes easy to read, which will help speed up the review process. The second is by minimizing the chance for new bugs or issues. No amount of cleanup is worth it if new bugs are introduced.
Is there already a fix out there? Before diving too deep into a solution, make sure that someone else didn't already take a shot at it. If they did, double check the status. It might be pending, abandoned, or simply obsolete at this point. Open source moves fast, so investigate first to avoid wasting time.

Step 2: Fork & Fix

Believe it or not, the easiest part of your first open source contribution should be forking and fixing. GitHub makes forking super easy, just navigate to the repository and click the "Fork" button!

GitHub's Repository Interaction Options

Once you have your own fork of the repo you can clone it to your development environment for editing. You technically have the option to edit it online from GitHub, but as I cover in the next step it's best to clone the repo so you can ensure the changes pass tests and coding standards.

Finally, when applying fixes try to limit changes to those required for the fix. Small changes means fast reviews, which probably increases the chances of getting it merged. If you feel like the changes are beginning to snowball, reach out to the project maintainers for some guidance.

Step 3: Test & Pull Request

The world would be a better place if everyone tested their code. And to me, it's absolutely CRAZY that people make changes and commit it without verifying that it works! Continuous Integration has been a blessing by allowing teams to move fast while maintaining stable branches. But that doesn't mean we should rely on CI alone. It's crucial to test your changes as rigorously as possible before making your PR. It helps to ensure that the changes you made were correct, and helps to avoid wasting the valuable time of a maintainer.

Once you've successfully tested your changes your good to create your PR! Be sure to provide a clear and concise title so maintainers can easily triage the PR. In the description be sure to include details about the motivation for the change, how the issue was solved, and any other supporting details that would help a maintainer review the changes.

When creating a PR, sometimes repositories will have a Contributor License Agreement (CLA). This is just an agreement that means the community can use your changes. It typically takes less than 5 minutes and only has to be done once, so don't be intimidated by it.

Step 4: Be Patient, Listen, and Stick with it

With some luck and hard work, your PR will get merged in once the maintainers take a look. They could also provide some requests for more changes or simply ask some questions.

An important part of Open Source Software is being able to work together and receive criticism. Respect is paramount in a community.

Take the time to understand their feedback and work with them to arrive at the best outcome. If it results in a merged PR, then that's great! But if they are still not happy with the changes, don't let that get you down. Stick with it and use it as an opportunity to learn and grow.

Finally, if they close it (or worse, never respond to it) then do not worry! Anyone who contributes to Open Source Software will get a closed PR at some point in their career. My recommendation is to start back at Step 1 and find a good issue to fix. GitHub projects usually have issues with a tag like good first issue or help wanted that are great for new contributors.

Conclusion

Contributing to Open Source Software is an exercise that all developers should try at some point. There are so many fantastic tools and frameworks out there that we use for free every day. But they are not free for the maintainers and their families. Give back to those who work so hard and help make your community a better place.

If you have any questions please hit me up on twitter! I'm happy to help anyone with their first (or 100th) PR!

SSL Certificates in Development

Jim Buck — Fri, 12 Apr 2019 02:15:22 +0000

Recently I've been working a lot with multiple multi-app servers and their SSL certificates. Once you get more than two or three environments up and running it can get a little tricky finding and wrangling certificates from each instance. Thankfully I've found a few super tips that have been a big time saver when it comes to solving issues with certs when your working in less than ideal system setups.

Tip 1: Find and Destroy

I find there are certain times when the dev certs on my PC are just out of hand. The first step to cleaning them up is by removing the old ones. The certificates snap-in for the Microsoft Management Console is a decent tool if you want to look at a specific cert. Simply select the folder on the left and you can easily find the certs you need. But when you're looking for one or more possible certs, then try the following Powershell snippet:

ls Cert:\ -Recurse | where { $_.Issuer -like "*Jim Buck*" }

This snippet will recursively search all installed certificates but only display those that match the criteria (in this case the Issuer must contain Jim Buck. You can filter on any of the following fields:

Subject - text (might be generic or the same as issuer)
Issuer - text (typically quite reliable to filter on)
Thumbprint - hash (unique per certificate)
FriendlyName - string (sometimes empty)
NotBefore - Datetime
NotAfter - Datetime
Extensions - List of Oid objects (they have FriendlyName and Value properties).

Early in the development process you might be adding quite a few certs to your store. Run the same command but pipe it to the rm command and you can easily remove all of the pesky old certificates:

ls Cert:\ -Recurse | where { $_.Issuer -like "*Jim Buck*" } | rm

I don't recommend clearing out certs too often though. Ideally you only have to do it before installing the "good" certs. Once you have a nice clean cert store adding new certs that are known to be good should be just fine to have installed.

Tip 2: Trust the CA Root certificate

Our application relies on an in-house data service. During the install of this service, it generates a CA Root certificate and an end-user certificate for the server's FQDN (signed by the generated CA Root). We can't modify the install logic of the service, so we have to make due with the certs it produces. The best approach is to simply download the CA Root cert from each instance and install it in the Trusted Root of our Local Machine.

I typically select "Local Machine" (just in case) and manually select "Trusted Root Certification Authorities".

Don't be fooled, certs of the same name (but different thumbprint) can be installed side-by-side. Just remember to restart your browser/client apps so they pick up the new certificates.

Tip 3: Use a shared CA Root certificate

By far the best approach is to simply make your certificate generation use a shared CA Root. This would allow a project or even a whole department to use one common root cert that signs all server-specific development/test certs. No more downloading of certs to trust, no more hacks to ignore cert errors. No more rummaging through each environment trying to update all references of which cert to use. Just one shared cert that keeps developers, testers, managers, and product owners safe and secure.

I am currently finalizing a script to help create (dev-only) CA Root and SSL certs. Once I can test it a bit more and get the usage as simple as possible I will write a special article all about it.