基于OWin的Web服务器Katana发布版本3

时间:2022-04-25
本文章向大家介绍基于OWin的Web服务器Katana发布版本3,主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

当 ASP.NET 首次在 2002 年发布时,时代有所不同。 那时,Internet 仍处于起步阶段,大约有 5.69 亿用户,每个用户平均每天访问 Internet 的时间为 46 分钟,大约有 3 百万个网站。 仅仅在 10 年之后,相同的测量指标揭示,大约有 22.7 亿个 Internet 用户,每个用户平均每天访问 Internet 的时间为 4 小时,大约有 5.55 亿个网站。伴随着网络应用程序开发的不断演进,ASP.NET也伴随着产生了新的技术,比如ASP.NET MVC和ASP.NET WEB API。网络应用程序开发的下一个方向是进入云计算, Katana工程则为ASP.NET提供了基础的模块,使网络应用程序变得更灵活、更轻量级、更容易移植以及拥有更好的性能 - 也就是说,Katana工程能够优化你的asp.net程序。

Katana 项目实际可以追溯到 Microsoft 外部一个名为 Open Web Inter­face for .NET (OWIN) 的开放源代码项目。OWIN 是一种定义 Web 服务器和应用程序组件之间的交互的规范(请参阅 owin.org)。 由于这一规范的目的是发展一个广阔且充满活力的、基于 Microsoft .NET Framework 的 Web 服务器和应用程序组件生态系统,因此它可以将服务器与应用程序之间的交互减少到一小部分类型和单个函数签名,这个函数签名被称为应用程序委托(即 AppFunc):

using AppFunc = Func<IDictionary<string, object>, Task>;

基于 OWIN 的应用程序中的每个组件都向服务器提供应用程序委托。 然后,这些组件链接成一个管道,基于 OWIN 的服务器将会向该管道推送请求。 为了更有效地使用资源,管道中的所有组件都应该是异步的,这体现在返回 Task 对象的应用程序委托中。随着版本3的发布,Kanata目前已经完整地支持了.NET 4.5中新加入的异步编程模型。尽管ASP.NET从十年前就已经开始支持异步编程模型,但.NET 2.0中引入的IAsyncResult模型使用起来非常繁琐,大多数开发者甚至都不知道它的存在。Node.js趁虚而入,它将自己称为高级异步web开发平台,而微软则希望通过在.NET 4.5中引入的async/await模型重新夺回这一称号。

包括应用程序状态、请求状态和服务器状态等在内的所有状态都保存在应用程序委托上指定的 IDictionary<string, object> 对象中。 这种数据结构称为环境字典,随着请求通过管道时会从一个组件传递到另一个组件。 虽然任何键/值数据都可以插入到环境字典中,但 OWIN 规范为某些 HTTP 核心元素定义了键.

HTTP 请求的必需环境字典键

键名称

值说明

"owin.RequestBody"

一个带有请求正文(如果有)的流。如果没有请求正文,Stream.Null 可以用作占位符。

"owin.RequestHeaders"

请求标头的 IDictionary<string, string[]>

"owin.RequestMethod"

一个包含请求的 HTTP 请求方法的字符串(例如 GET 和 POST)。

"owin.RequestPath"

一个包含请求路径的字符串。 此路径必须是应用程序委托的“根”的相对路径。

"owin.RequestPathBase"

一个字符串,包含对应于应用程序委托的“根”的请求路径部分。

"owin.RequestProtocol"

一个包含协议名称和版本的字符串(例如 HTTP/1.0 或 HTTP/1.1)。

"owin.RequestQueryString"

一个字符串,包含 HTTP 请求 URI 的查询字符串组成部分,不带前导“?”(例如 foo=bar&baz=quux)。 该值可以是空字符串。

"owin.RequestScheme"

一个字符串,包含用于请求的 URI 方案(例如 HTTP 或 HTTPS)。

定义一组基本的环境字典键/值对,使得许多不同的框架和组件作者可以在一个 OWIN 管道中进行互操作,而不必强制实施对特定 .NET 对象模型的协议,例如针对 ASP.NET MVC 中的 HttpContextBase 或 ASP.NET Web API 中的 HttpRequestMessage/HttpResponseMessage 的协议。

应用程序委托和环境字典这两个元素构成了 OWIN 规范。 Katana 项目是 Microsoft 创建和推出的基于 OWIN 的组件和框架集合。

在新的功能特性方面,新版本主要关注于“企业级认证功能以及基于声明的标识(claims-based identity)”。参与了Katana 3项目的Vittorio Bertocci特别提到了以下三种协议:

  • WS-Federation
  • OpenId Connect (通过表单提交方式提供id_token以及id_token+code方式)
  • 可在Web API中使用的OAuth2票据令牌认证

Vittorio还写道:

这个版本的发布还解决了由于Twitter和Google API发生变动所引起的问题。如果你在应用中使用了Google认证,并且打算升级到Katana版本3,请确保你已读过这篇帖子

Katana可以作为NuGet包获得。根据Katana网站描述显示,取决于你所需的不同特性,共有总数超过20的包可以选择下载:(这一点和传统的ASP.NET形成了鲜明的对比,后者的方式是将几乎所有特性都堆积在一个庞大的程序集中。)

  • Microsoft.Owin – 提供了一组辅助类型,以及为简化创建OWIN组件而建的各种抽象类型。
  • Microsoft.Owin.Diagnostics – 提供了各种中间件组件,以辅助开发基于OWIN的应用程序。
  • Microsoft.Owin.FileSystems – 这个包里提供了文件系统相关的抽象与实现。
  • Microsoft.Owin.Testing – 提供了对OWIN组件进行单元测试的一些辅助类。
  • Microsoft.Owin.SelfHost – 包含了为在自行指定的进程中托管基于OWIN的应用程序所必需的一些组件。
  • Microsoft.Owin.Hosting – 提供了托管与运行基于OWIN的应用程序所需的默认基础框架类型。
  • OwinHost – 提供了一个单独的可执行程序(OwinHost.exe),通过它可以托管一个基于OWIN的应用程序的运行。
  • Microsoft.Owin.Cors – 这个包里包含了一些能够在OWIN中间件中进行跨域资源共享(CORS)的组件。
  • Microsoft.Owin.StaticFiles – 这个包里包含了一些OWIN中间件,能够处理来自于文件系统资源的请求,包括文件与目录。
  • Microsoft.Owin.Security – 包含了一些各种不同的认证中间件组件所共享的 通用类型。
  • Microsoft.Owin.Security.ActiveDirectory – 一组允许应用程序使用微软技术进行认证的中间件。
  • Microsoft.Owin.Security.Cookies – 允许应用程序使用基于cookie进行认证的中间件,类似于ASP.NET中的表单认证方式。
  • Microsoft.Owin.Security.Facebook – 允许应用程序支持Facebook所使用的OAuth 2.0认证工作流的一些中间件。
  • Microsoft.Owin.Security.Google – 包含了一组支持Google的OpenId及OAuth 2.0认证工作流的中间件。
  • Microsoft.Owin.Security.Jwt – 一组允许应用程序保护及验证JSON Web令牌的中间件。
  • Microsoft.Owin.Security.MicrosoftAccount – 一组允许应用程序支持微软帐号认证工作流的中间件。
  • Microsoft.Owin.Security.OAuth – 允许应用程序支持任何标准OAuth 2.0认证工作流的中间件。
  • Microsoft.Owin.Security.OpenIdConnect – 允许应用程序使用OpenIdConnect方式进行认证的中间件。
  • Microsoft.Owin.Security.Twitter – 允许应用程序支持Twitter的OAuth 2.0认证工作流的中间件。
  • Microsoft.Owin.Security.WsFederation – 允许应用程序使用WsFederation进行认证的中间件。
  • Microsoft.Owin.Host.HttpListener – 基于.Net Framework中的HttpListener类创建的OWIN服务器,也是目前用于自托管的默认服务器。
  • Microsoft.Owin.Host.SystemWeb – 也是OWIN服务器实现,但它允许基于OWIN的应用程序运行在IIS中,并能够使用ASP.NET的请求管道。