W3C的CORS Specification

W3C的CORS Specification

随着Web开放的程度越来越高，通过浏览器跨域获取资源的需求已经变得非常普遍。在我看来，如果Web API不能针对浏览器提供跨域资源共享的能力，它甚至就不应该被称为Web API。从另一方面来看，浏览器作为进入Internet最大的入口，是各大IT公司的必争之地，所以浏览器市场出现了种类繁多、鱼龙混杂的局面。针对这两点，我们迫切需要一种能够被各个浏览器厂商共同遵循的标准来对跨域资源共享作出规范，这就是由W3C指定2的CORS（Cross-Origin Resource Sharing）规范。

目录 
CORS是如何工作的？ 
对响应报头的授权 
预检机制 
是否支持用户凭证

一、CORS是如何工作的？

基于Web的资源共享涉及到两个基本的角色，即资源的提供者和消费者。针对我们前面演示的应用场景，即显示在浏览器中的某个Web页面通过调用Web API的方式来获取它所需的资源，资源提供者为Web API本身，通过发送Ajax请求来调用Web API的JavaScript程序为资源的消费者。

CORS旨在定义一种规范让浏览器在接收到从提供者获取的资源时能够正决定是否应该将此资源分发给消费者作进一步处理。CROS利用资源提供者的显式授权来决定目标资源是否应该与消费者共享。换句话说，浏览器需要得到提供者的授权之后才会将其提供的资源分发给消费者。那么，资源的提供者如何进行资源的授权，并将授权的结果告诉浏览器呢？

具体的实现其实很简单。如果浏览器 自身提供对CROS的支持，由它发送的请求会携带一个名为“Origin”的报头表明请求页面所在的站点。对于前面我们演示实例中调用Web API获取联系人列表的请求来说，它就具有如下一个“Origin”报头。

   1: Origin: http://localhost:9527

资源获取请求被提供者接收之后，它可以根据该报头确定提供的资源需要共享给谁。资源提供者的授权通过一个名为“Access-Control-Allow-Origin”的响应报头来承载，其报头值表示得到授权的站点。一般来说，如果资源的提供者认可了当前请求的“Origin”报头携带的站点，那么它会将该站点作为“Access-Control-Allow-Origin”响应报头的值。

除了指定具体的源并对其作针对性授权之外，资源提供者还可以将“Access-Control-Allow-Origin”报头值设置为“*”对所有消费者授权。换言之，如果作了这样的设置，意味着由其提供的是一种公共资源，所以在做此设置之前需要慎重。如果针对请求着的授权不被允许，资源提供者可以将此响应报头值设置为“null”，或者让响应不具有此报头。

当浏览器接收到包含资源的响应之后，会提取此“Access-Control-Allow-Origin”响应报头的值。如果此值为“*”或者包含的源列表包含此前请求的源（即请求的“Origin”报头值），意味着资源的消费者获取了提供者获取和操作资源的权限，所以浏览器会允许JavaScript程序操作获取的资源。如果此响应报头不存在或者其值为“null”，客户端JavaScript程序针对资源的操作会被拒绝。

二、对响应报头的授权

资源提供者除了通过设置“Access-Control-Allow-Origin”报头对提供的主体资源进行授权之外，还可以通过设置另一个名为“Access-Control-Expose-Headers”的报头对响应报头进行授权。具体来说，此“Access-Control-Expose-Headers”的报头用于设置一组直接暴露给客户端JavaScript程序的响应报头，没有在此列表的响应报头 对于客户端JavaScript程序是不可见的。

但是由此实现的针对响应报头的授权针对简单响应报头是无效的，客户端JavaScript程序总是具有获取它们的权限。对于CORS规范来说，这里所谓的“简单响应报头（Simple Response Header）”包含如下6种。

• Cache-Control
• Content-Language
• Content-Type
• Expires
• Last-Modified
• Pragma

我们知道用于实现Ajax请求的XMLHttpRequest具有一个getResponseHeader方法，调用它会返回一组响应报头的列表。按照这里介绍的针对响应报头的授权原则，只有在“Access-Control-Expose-Headers”报头中指定的报头和简单响应报头才会包含在该方法返回的列表中。

三、预检机制

W3C的CORS规范将跨域资源请求划分为两种类型，一种被称为“简单请求（Simple Request）”。要弄清楚CORS规范将那些类型的跨域资源请求划分为简单请求的范畴，需要额外了解几个名称的含义，其中包括“简单（HTTP）方法（Simple Method）”、“简单（请求）报头（Simple Header）”和“自定义请求报头（Author Request Header/Custom Request Header）”。

CORS规范将GET、HEAD和POST这三个HTTP方法视为“简单HTTP方法”，而将请求报头Accept, Accept-Language, Content-Language以及采用如下三种媒体类型的报头Content-Type称为“简单请求报头”

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

请求的报头包含两种类型，一类是通过浏览器自动生成的报头，另一种则是由JavaScript程序自行添加的报头（比如调用XMLHttpRequest的setRequestHeader方法可以为生成的Ajax请求添加任意报头），后者被称为“自定义报头”。

CORS规范将服务如下条件的跨域资源请求划分为简单请求：请求采用简单HTTP方法，并且其自定义请求报头空或者所有自定义请求报头均为简单请求报头。之所以作如此划分是因为具有这些特性的请求不是以更新（添加、修改和删除）资源为目的，服务端对请求的处理不会导致自身维护资源的改变。

对于简单跨域资源请求来说，浏览器将两个步骤（取得授权和获取资源）合二为一，由于不涉及到资源的改变，所以不会带来任何副作用（Side Effect）。如果针对请求的处理过程会涉及到对资源的改变，这样做就会有问题了。按照CORS规范的规定，浏览器应该采用一种被称为“预检（Preflight）”的机制来完成非简单跨域资源请求。

所谓预检机制就是说浏览器在发送真正的跨域资源请求前，先发送一个预检请求（Preflight Request）。预检请求为一个采用HTTP-OPTIONS方法的请求，这是一个不包含主体的请求，同时用户凭证相关的报头也会被剔除。基于真正资源请求的一些辅助授权的信息会包含在此预检请求的相应报头中。除了代表请求页面所在站点的“Origin”报头之外，如下所示的是两个典型的请求报头。

• Access-Control-Request-Method：真正跨域资源请求采用的HTTP方法。
• Access-Control-Request-Headers：真正跨域资源请求携带的自定义报头列表。

资源的提供者在接收到预检请求之后，根据其提供的相关报头进行授权检验，具体的检验逻辑即包括确定请求站点是否值得信任，以及请求采用HTTP方法和自定义报头是否被允许。如果预检请求没有通过授权检验，资源提供者一般会返回一个状态为“400， Bad Reuqest”的响应。反之则会返回一个状态为“200， OK”的响应，授权相关信息会包含在响应报头中。除了上面介绍的“Access-Control-Allow-Origin”和“Access-Control-Expose-Headers”报头之外，预检请求的响应还具有如下3个典型的报头。

• Access-Control-Allow-Methods：跨域资源请求允许采用的HTTP方法列表。
• Access-Control-Allow-Headers：跨域资源请求允许携带的自定义报头列表。
• Access-Control-Max-Age：浏览器可以将响应结果进行缓存的时间（单位为秒），这样可以让浏览器避免频繁地发送预检请求。

浏览器在接收到预检响应之后，会根据响应报头确定后续发送的真正跨域资源请求是否会被接受，相关的检验包括针对服务端允许站点以及HTTP方法和自定义请求报头（利用响应报头“Access-Control-Allow-Methods”和“Access-Control-Allow-Headers”）的检验。具体的检验逻辑如下

• 通过请求的“Origin”报头表示的源站点必须存在于“Access-Control-Allow-Origin”响应报头标识的站点列表中。
• 响应报头“Access-Control-Allow-Methods”不存在，或者预检请求的“Access-Control-Request-Method”报头表示的请求方法在其列表之内。
• 预检请求的“Access-Control-Request-Headers”报头存储的报头名称均在响应报头“Access-Control-Allow-Headers”表示的报头列表之内。

只有在确定服务端一定会接受的情况下，浏览器才会发送真正跨域资源请求。预检响应结果会被浏览器缓存，在“Access-Control-Max-Age”报头设定的时间内，缓存的结果将被浏览器用户进行授权检验，所以在此期间不会再有预检请求发送。

四、是否支持用户凭证

在默认情况下，利用XMLHttpReuqest发送的Ajax请求不会携带用户凭证相关的敏感信息，这里的用户凭证类型包括Cookie、HTTP-Authentication报头以及客户端X.509证书（采用支持客户端证书的TLS/SSL）等。如果需要用户凭证附加到Ajax请求上，需要将XMLHttpReuqest的withCredentials 属性设置为True。

对于CORS来说，是否支持用户凭证也是授权检验的一个环节。换句话说，只有在服务端显式支持用户凭证的情况下，携带了用户凭证的请求才会被认为是有效的。在W3C的CORS规范来说，服务端利用响应报头“Access-Control-Allow-Credentials”来表明自身是否支持用户凭证。

也就是说，如果客户客户端JavaScript程序利用一个withCredentials属性为true的XMLHttpReuqest发送了一个跨域资源请求，但是浏览器得到的响应中不具有一个值为“true”的响应报头“Access-Control-Allow-Credentials”，它对获取资源的操作将会浏览器拒绝。

上面我们对W3C的CORS规范作了概括性的介绍，由于篇幅所限，很多的细节并没有涉及。如果读者朋友们对此有兴趣，我个人强烈推荐直接阅读W3C的官方文档。由于官方文档的文字描述较为“生硬”，可能需要多读几遍才能将资源提供者和浏览器如何处理资源授权流程搞清楚。

[1] 同源策略与JSONP 
[2] W3C的CORS规范 
[3] 通过自定义HttpMessageHandler实现跨域资源共享 
[4] CORS在ASP.NET Web API中的实现

浅谈C#泛型的定义、继承、方法和约束

摘要：本文介绍了如何定义一个C#泛型类，以及实现泛型类的继承、方法和约束。

C#泛型参数化了类型，把类型作为参数抽象出来，从而使我们在实际的运用当中能够更好的实现代码的重复利用，同时它提供了更强的类型安全，更高的效率，不过在约束方面，它只支持显示的约束，这样在灵活性方面就显得不是那么好了。我觉得它之所以能够提供更高的效率是因为泛型在实例化的时候采用了"on-demand"的模式,即按需实例化,发生在JIT(Just In Time)编译时。

下面来看如何定义一个C#泛型类，很简单，你只需要意识到一点,在这里,类型已经被参数化了:

using System;
using System.Collections.Generic;
using System.Text;

namespace GenericTest
{
    class Program
    {
        static void Main(string[] args)
        {
            //使用string,int来实例化Test< T,S>类
            Test<string, int> t = new Test<string, int>("SHY520", 22);

            //调用泛型类中的方法
            t.SetValue();
        }
    }

    /**/
    /// < summary>
    /// 定义一个泛型类，该类有两个类型参数，分别是T,S
    /// http://www.cnblogs.com/jara
    /// < /summary>
    /// < typeparam name="T">类型参数< /typeparam>
    /// < typeparam name="S">类型参数< /typeparam>
    public class Test<T, S>
    {
        //泛型类的类型参数可用于类成员
        private T name;
        private S age;

        public Test(T Name, S Age)
        {
            this.name = Name;
            this.age = Age;
        }

        public void SetValue()
        {
            Console.WriteLine(name.ToString());
            Console.WriteLine(age.ToString());
        }
    }
}

上面的例子不是很恰当，目的是让初学泛型的你了解一下泛型的定义及实例化方法，如上，我们定义了一个泛型类，那么如何实现C#泛型类的继承呢？这里需要满足下面两点中的任何一点即可：

1、泛型类继承中，父类的类型参数已被实例化，这种情况下子类不一定必须是泛型类；

2、父类的类型参数没有被实例化，但来源于子类，也就是说父类和子类都是泛型类，并且二者有相同的类型参数；

//如果这样写的话，显然会报找不到类型T,S的错误
public class TestChild : Test< T, S> { }  

//正确的写法应该是
public class TestChild : Test< string, int>{ }
public class TestChild< T, S> : Test< T, S> { }
public class TestChild< T, S> : Test< String, int> { } 

接着我们来看看泛型接口，其创建以及继承规则和上面说的泛型类是一样的，看下面的代码：

public interface IList<T>
{
    T[] GetElements();
}
public interface IDictionary<K, V>
{
    void Add(K key, V value);
}

// 泛型接口的类型参数要么已实例化
// 要么来源于实现类声明的类型参数
class List<T> : IList<T>, IDictionary<int, T>
{
    public T[] GetElements() { return null; }
    public void Add(int index, T value)
    { }
}

在来看一下C#泛型委托，首先我们定义一个类型参数为T的委托，然后在类中利用委托调用方法：

using System;
using System.Collections.Generic;
using System.Text;

namespace GenericTest
{
    //定义一个委托，类型参数为T，返回值类型T
    //泛型委托支持在返回值和参数上应用类型参数
    delegate string GenericDelete<T>(T value);

    class test
    {
        static string F(int i) { return "SHY520"; }
        static string G(string s) { return "SHY520"; }

        static void Main(string[] args)
        {
            GenericDelete<string> G1 = G;
            GenericDelete<int> G2 = new GenericDelete<int>(F);
        }
    }
} 

我们再来看C#泛型方法，C#的泛型机制只支持在方法申明上包含类型参数，也即是泛型方法。特别注意的是，泛型不支持在除了方法以外的其他类/接口成员上使用类型参数，但这些成员可以被包含在泛型类型中，并且可以使用泛型类型的类型参数。还有一点需要说的就是，泛型方法可以在泛型类型中，也可以存在于非泛型类型中。下面我们分别看一下泛型类型的申明，调用，重载和覆盖。

using System;
using System.Collections.Generic;
using System.Text;

namespace GenericTest
{
    class GenericClass
    {
        //申明一个泛型方法
        public T getvalue<T>(T t)
        {
            return t;
        }

        //调用泛型方法
        //注意：在调用泛型方法时，对泛型方法的类型参数实例化
        public int useMethod()
        {
            return this.getvalue<int>(10);
        }

        //重载getvalue方法
        public int getvalue(int i)
        {
            return i;
        }
    }

    //下面演示覆盖
    //要注意的是，泛型方法被覆盖时，约束被默认继承，不需要重新指定约束关系
    abstract class Parent
    {
        public abstract K TEST<K, V>(K k, V v) where K : V;
    }

    class Child : Parent
    {
        public override T TEST<T, S>(T t, S s)
        {
            return t;
        }
    }
}

最后我们来看一下C#泛型中的约束：

C#中的泛型只支持显示的约束，因为这样才能保证C#所要求的类型安全，但显示的约束并非时必须的，如果不加约束，泛型类型参数将只能访问System.Object类型中的公有方法。“显式约束”由where子句表达，可以指定“基类约束”，“接口约束”，“构造器约束”，“值类型/引用类型约束”共四种约束。下面的例子来源于李建忠老师的讲座PPT。

1、基类约束：

class A { public void F1() {} }
class B { public void F2() {} }
class C< S,T>
where S: A // S继承自A
where T: B // T继承自B
{
　// 可以在类型为S的变量上调用F1，
　// 可以在类型为T的变量上调用F2
}  

2、接口约束

interface IPrintable { void Print(); }
interface IComparable< T> { int CompareTo(T v);}
interface IKeyProvider< T> { T GetKey(); }
class Dictionary< K,V>
where K: IComparable< K>
where V: IPrintable, IKeyProvider< K>
{
　// 可以在类型为K的变量上调用CompareTo，
　// 可以在类型为V的变量上调用Print和GetKey
} 

3、构造器约束

class A { public A() { } }
class B { public B(int i) { } }
class C< T>
where T : new()
{
　//可以在其中使用T t=new T();
}
C< A> c=new C< A>(); //可以，A有无参构造器
C< B> c=new C< B>(); //错误，B没有无参构造器 

4、值/引用类型约束

public struct A { }
public class B { }
class C< T>
where T : struct
{
　// T在这里面是一个值类型
}
C< A> c=new C< A>(); //可以，A是一个值类型
C< B> c=new C< B>(); //错误，B是一个引用类型

 

 

 

标签: C#