Server类是Jetty中最核心的是类，它即包含Connectors数据，有包含了Handler的集合，即它是Jetty中用于连接Connector和Handler的类。同时它还包含了一个Container，用于存储Jetty中核心类实例的关系发生变化时触发事件的Listener，接收者可以注册一个Listener以获取Jetty中某个类的关系发生变化。
Server的实现

Server继承自HandlerWrapper，因而它默认是一个Handler容器，另外它也包含一个Container字段，以及Connector数组字段，ThreadPool字段，另外它还包含了一些配置字段，如：attributes、sessionIdManager、sendServerVersion、sendDateHeader、stopAtShutdown（注册shutdown hook）、maxCookieVersion、dumpAfterStart、dumpBeforeStop等，这些只是用于配置信息，而且名称本身已经很清楚它的含义了。

在使用Server时，我们需要向其添加Connector以及Handler，从而在启动时，它会首先注册ShutdownThread，即在JVM退出时会首先调用它的stop方法；如果没有手动设置ThreadPool，使用QueuedThreadPool初始化ThreadPool字段；然后启动所有Handler以及Connector。在stop时，它先close所有Connector，然后设置所有实现了Graceful接口的类的shutdown为true，并等待graceful时间后，stop所有Connector以及Handler。

Server中有两个handle方法在HttpConnection请求解析完成后调用，其中handle方法用于在非ASYNC状态下的调用，它只是从HttpConnection中取得Request、Response实例以及PathInfo作为target，传递给Handler的handle方法；而handleAsync方法则是在ASYNC状态下调用，它的baseRequest从HttpConnection中获取，但是会将其原有的RequestURI、QueryString、ContextPath设置到其Attribute（javax.servlet.async.*）中，而将他们对应的属性包括PathInfo更新为当前AsyncContext中Request的值，并且request、response实例则是从AsyncContext中获取，然后调用Handler的handle方法。

Container的实现

Container用于生成父实例和子引用的关系发生变化时生成的时间，以提供其注册的Listener接收到相应的事件。Container通过内部接口Listener可以触发如下事件：

其中Relationship表示一个父实例和一个子引用的关系，如handler、threadPool、errorHandler等。每当一个关系发生变化时，可以调用Container的update方法，而update方法内部会触发相应的remove和add事件。

ContextHandler实现

ServletContextHandler实现

WebAppContext实现

在WebAppContex启动时：

1. 根据WebAppContext的allowDuplicateFragmentNames属性设置MetaData实例对应的属性。

2. 调用preConfigure方法，它加载所有Configuration实例（用户自定义或默认设置：WebInfConfiguration、WebXmlConfiguration、MetaInfConfiguration、FragmentConfiguration、JettyWebXmlConfiguration）；加载系统类规则集合（即不能被Web Application覆盖的类，他们必须使用System ClassLoader加载，可以通过Server属性org.eclipse.jetty.webapp.sysemClasses属性定义，或者使用默认值）以及Server类规则集合（不能被Web Application加载的类，他们需要使用System ClassLoader加载，可以使用Server属性org.eclipse.jetty.webapp.serverClasses定义，或者使用默认值，这两个的区别参考WebAppClassLoader的实现解析）；设置ClassLoader，默认为WebAppClassLoader；调用所有Configuration的preConfigure方法。

3. 调用startContext方法，他会调用Configuration的configure方法，以及MetaData的resolve方法；在MetaData的resolve方法中，他首先设置WebAppContext的javax.servlet.context.orderedLibs属性，然后设置ServletContext的EffectiveMajorVersion和EffectiveMinorVersion，并遍历通过Configuration注册的DescriptorProcessor，对webDefaultRoots、webXmlRoot、webOverrideRoots等Descriptor进行处理，以读取Servlet、Filter、Listener等信息的定义，遍历在Configuration中注册的DiscoveredAnnotation，对所有找到的WebFilter、WebServlet、WebListener注解类进行解析并添加到WeAppContext中，最后对在FragmentConfiguration中注册的FragmentDescriptor以及DiscoveredAnnotation进行相应的处理已进一步配置WebAppContext。

4. 调用postConfiguration方法，即调用所有注册的Configuration的postConfigure方法以做一些清理工作。

WebAppClassLoader实现

WebAppClassLoader是Jetty中用于对Servlet规范的ClassLoader的实现，它集成子URLClassLoader。它不会加载任何System Class（使用System ClassLoader加载），对Java2中父ClassLoader优先于子ClassLoader的规则，可以使用WebAppContext的setParentLoadPriority为true来配置。如果没有配置父ClassLoader，则使用当前的Thread Context ClassLoader，如果该ClassLoader也为null，则使用加载该类的ClassLoader，如果它还为null，则使用SystemClassLoader作为其父ClassLoader。

在加载类时，WebAppClassLoader有SystemClass和ServerClass的类别，SystemClass是指在Web Application中可见的，但是他们不能被Web Application中的类(WEB-INF/classes，WEB-INF/lib中的类)覆盖的类，而ServerClass是指这些类是Server部分的实现，它对Web Application是不可见的，如果需要使用它们，可以将相应的jar包添加到WEB-INF/lib中。

WebAppClassLoader默认支持.zip,.jar为扩展名的文件中查找class定义，可以使用org.eclipse.jetty.webapp.WebAppClassLoader.extensions系统属性添加更多的扩展名文件支持（以“,”或“;”分隔）。WebAppClassLoader也会添加WebAppContext中的ExtraClassPath到其ClassPath中（以“,”或“;”分隔），即添加URL。

在WebInfConfiguration的configure方法中，他会默认的将所有WEB-INF/lib下的jar包以及WEB-INF/classes目录添加到WebAppClassLoader的ClassPath中，即添加URL。

在其loadClass的实现中，如果某class既是SystemClass又是ServerClass，则返回null；如果不是ServerClass，且是父ClassLoader优先或者是SystemClass，则使用父ClassLoader加载，然后再使用当前ClassLoader加载；在getResources和getResource的实现中，对于ServerClass它只能从当前ClassLoader中查找，对SystemClass它只能从父ClassLoader中查找。

XmlConfiguration是Jetty中用来实现使用XML文件配置WebAppContext实例的框架，事实上，他可以用来配置任何的Object。类似Digester可以将一个XML配置文件直接实例化成一个类实例，XmlConfiguration可以使用一个XML文件初始化一个Object实例，它支持属性设置、方法调用、新建新实例等。

XmlConfiguration实现

在XmlConfiguration的实现中，可以使用URL、configuration字符串、InputStream作为构造函数传入XmlConfiguration中，在XmlConfiguration的构造函数初始化时，它初始化XmlParser实例，使用XmlParser对XML文件进行解析成一个Node树，并将该树的根节点赋值给config字段；在初始化config字段的同时初始化processor字段，processor字段是ConfigurationProcessor类型，他用于解析XmlParser解析出的Node树的处理类，如果根节点的Tag是Configure，则processor使用Jetty中的默认实现：JettyXmlConfiguration类，否则使用ServiceLoader查找到的ConfigurationProcessorFactory实例，并调用其getConfigurationProcessor方法，传入dtd和tag作为参数，直到找到一个非null的ConfigurationProcessor；在创建出ConfigurationProcessor实例后，首先调用其init方法，在JettyXmlConfiguration类的实现中，init方法只是将传入的参数保存：Node树的config实例、以及两个idMap、propertyMap实例用于传递参数，其中idMap用于保存解析过程中所有id属性对应的实例，也可以用它来传递XML文件用于配置的实例以及其他ref引用的实例，而propertyMap用于定义一些XML文件中用到的属性对应的值。

可以使用带Object实例的参数或不带参数两种方式调用configure方法，带参数表示将XML中内容配置实例中的属性，不带参数则先在内部创建class属性指定的类实例，然后使用XML的内容配置该新创建的实例的属性，如果根元素定义了id属性，则可以设置要配置的实例是idMap中该id值对应的实例。

在configure方法的真正实现中，它遍历根节点的所有子节点，判断tag值（在这个过程中对任何有id定义的元素，将该id属性的值做为key，该元素对应的实例保存在idMap中）：
Set => 用于设置name属性指定的set方法或字段的值，在查找方法中会有各种尝试：1. 尝试当前值实例作为参数的set方法；2. 使用Class实例的TYPE字段作为参数类型的set方法；3. 尝试查找public类型的字段；4. 尝试所有只有一个参数的对应的set方法；5. 尝试是否可以将其转换成Set或数组类型的参数；6. 尝试装箱后的参数。

Put => 要使用该方法，配置类型必须继承自Map接口，使用name属性作为key，获取其值实例，调用put方法。

Call => 指定class属性表示调用其静态方法；读取所有的Arg子节点（Arg节点必须紧跟Call节点），并且解析这些Arg的值类型，name属性指定方法名，在返回后如果其他节点定义，则使用它们配置返回的实例。

Get => 使用name属性指定的get无参数方法，如果没有找到get方法，则从name属性指定的字段中获取值，如果还有子元素，则对返回的实例进行配置。

New => 创建一个class指定的类实例，可以使用Arg指定构造函数参数。如果有除了Arg以外的节点定义，则使用它们对新创建的实例配置。

Array => 创建数组实例，type指定数组类型，支持以下列举的所有的值类型，使用Item指定它的元素。

Ref => 为传入的ref引用实例配置。

Property => 从传入的propertyMap中获取值，可以指定default属性。可以通过定义子元素继续配置返回的值。
Map => 创建新的Map实例，使用Entry/Item, Item指定key、value的值。
对于所有值类型，可以指定其type属性，Jetty默认支持的类型有String、java.lang.String、URL、java.net.URL、InetAddress、java.net.InetAddress、boolean、byte、char、double、float、int、long、short、void、java.lang.Boolean.TYPE、java.lang.Byte.TYPE、java.lang.Character.TYPE、java.lang.Double.TYPE、java.lang.Float.TYPE、java.lang.Integer.TYPE、java.lang.Long.TYPE、java.lang.Short.TYPE、java.lang.Void.TPPE、Boolean、Byte、Character、Double、Float、Integer、Long、Short、null、string等。另外值类型还可以使用Call、Get、New、Ref、Array、Map、Property、SystemProperty定义。其中SystemProperty可以定义name和default属性用于表示prop名和default的值。ref引用必须先定义，因而这里无法处理循环引用的问题。

使用

可以使用XmlConfiguration，给定一个或多个Properties、XML文件参数，在Command Line中直接启动Jetty服务器。

XmlConfiguration也可以用于EnvConfiguration中，用于进一步配置WebAppContext，可以手动设置jettyEnvXmlUrl属性，或默认使用WEB-INF/jetty-env.xml文件。

XmlConfiguration还用于JettyWebXmlConfiguration，他默认查找WEB-INF目录下的jetty8-web.xml、jetty-web.xml、web-jetty.xml作为配置文件对WebAppContext做进一步的配置。

附录
XmlConfiguration支持的XML文件格式使用configure_6_0.dtd文件定义：

<?xml version="1.0" encoding="ISO-8859-1"?>

<!--
This is the document type descriptor for the
org.eclipse.XmlConfiguration class.  It allows a java object to be
configured by with a sequence of Set, Put and Call elements.  These tags are
mapped to methods on the object to be configured as follows:

  <Set  name="Test">value</Set>              ==  obj.setTest("value");
  <Put  name="Test">value</Put>              ==  obj.put("Test","value");
  <Call name="test"><Arg>value</Arg></Call>  ==  obj.test("value");

Values themselves may be configured objects that are created with the
<New> tag or returned from a <Call> tag.

Values are matched to arguments on a best effort approach, but types
my be specified if a match is not achieved.

-->

<!ENTITY % CONFIG "Set|Get|Put|Call|New|Ref|Array|Map|Property">
<!ENTITY % VALUE "#PCDATA|Get|Call|New|Ref|Array|Map|SystemProperty|Property">

<!ENTITY % TYPEATTR "type CDATA #IMPLIED " > <!-- String|Character|Short|Byte|Integer|Long|Boolean|Float|Double|char|short|byte|int|long|boolean|float|double|URL|InetAddress|InetAddrPort| #classname -->
<!ENTITY % IMPLIEDCLASSATTR "class NMTOKEN #IMPLIED" >
<!ENTITY % CLASSATTR "class NMTOKEN #REQUIRED" >
<!ENTITY % NAMEATTR "name NMTOKEN #REQUIRED" >
<!ENTITY % IMPLIEDNAMEATTR "name NMTOKEN #IMPLIED" >
<!ENTITY % DEFAULTATTR "default CDATA #IMPLIED" >
<!ENTITY % IDATTR "id NMTOKEN #IMPLIED" >
<!ENTITY % REQUIREDIDATTR "id NMTOKEN #REQUIRED" >


<!--
Configure Element.
This is the root element that specifies the class of object that
can be configured:

    <Configure class="com.acme.MyClass">  </Configure>
-->
<!ELEMENT Configure (%CONFIG;)* >
<!ATTLIST Configure %IMPLIEDCLASSATTR; %IDATTR; >


<!--
Set Element.
This element maps to a call to a setter method or field on the current object.
The name and optional type attributes are used to select the setter
method. If the name given is xxx, then a setXxx method is used, or
the xxx field is used of setXxx cannot be found.
A Set element can contain value text and/or the value objects returned
by other elements such as Call, New, SystemProperty, etc.
If no value type is specified, then white
space is trimmed out of the value. If it contains multiple value
elements they are added as strings before being converted to any
specified type.

A Set with a class attribute is treated as a static set method invocation.
-->
<!ELEMENT Set ( %VALUE; )* >
<!ATTLIST Set %NAMEATTR; %TYPEATTR; %IMPLIEDCLASSATTR; >


<!--
Get Element.
This element maps to a call to a getter method or field on the current object.
The name attribute is used to select the get method.
If the name given is xxx, then a getXxx method is used, or
the xxx field is used if getXxx cannot be found.
A Get element can contain other elements such as Set, Put, Call, etc.
which act on the object returned by the get call.

A Get with a class attribute is treated as a static get method or field.
-->
<!ELEMENT Get (%CONFIG;)*>
<!ATTLIST Get %NAMEATTR; %IMPLIEDCLASSATTR; %IDATTR; >


<!--
Put Element.
This element maps to a call to a put method on the current object,
which must implement the Map interface. The name attribute is used
as the put key and the optional type attribute can force the type
of the value.

A Put element can contain value text and/or value elements such as Call,
New, SystemProperty, etc. If no value type is specified, then white
space is trimmed out of the value. If it contains multiple value
elements they are added as strings before being converted to any
specified type.
-->
<!ELEMENT Put ( %VALUE; )* >
<!ATTLIST Put %NAMEATTR; %TYPEATTR; >


<!--
Call Element.
This element maps to an arbitrary call to a method on the current object,
The name attribute and Arg elements are used to select the method.

A Call element can contain a sequence of Arg elements followed by
a sequence of other elements such as Set, Put, Call, etc. which act on any object
returned by the original call:

 <Call id="o2" name="test">
   <Arg>value1</Arg>
   <Set name="Test">Value2</Set>
 </Call>

This is equivalent to:

 Object o2 = o1.test("value1");
 o2.setTest("value2");

A Call with a class attribute is treated as a static call.
-->
<!ELEMENT Call (Arg*,(%CONFIG;)*)>
<!ATTLIST Call %NAMEATTR; %IMPLIEDCLASSATTR; %IDATTR;>


<!--
Arg Element.
This element defines a positional argument for the Call element.
The optional type attribute can force the type of the value.

An Arg element can contain value text and/or value elements such as Call,
New, SystemProperty, etc. If no value type is specified, then white
space is trimmed out of the value. If it contains multiple value
elements they are added as strings before being converted to any
specified type.
-->
<!ELEMENT Arg ( %VALUE; )* >
<!ATTLIST Arg %TYPEATTR; %IMPLIEDNAMEATTR;  >


<!--
New Element.
This element allows the creation of a new object as part of a
value for elements such as Set, Put, Arg, etc. The class attribute determines
the type of the new object and the contained Arg elements
are used to select the constructor for the new object.

A New element can contain a sequence of Arg elements followed by
a sequence of elements such as Set, Put, Call, etc. elements
which act on the new object:

 <New id="o" class="com.acme.MyClass">
   <Arg>value1</Arg>
   <Set name="test">Value2</Set>
 </New>

This is equivalent to:

 Object o = new com.acme.MyClass("value1");
 o.setTest("Value2");
-->
<!ELEMENT New (Arg*,(%CONFIG;)*)>
<!ATTLIST New %CLASSATTR; %IDATTR;>


<!--
Ref Element.
This element allows a previously created object to be referenced by id.
A Ref element can contain a sequence of elements such as Set, Put, Call, etc.
which act on the referenced object:

 <Ref id="myobject">
   <Set name="Test">Value2</Set>
 </New>
-->
<!ELEMENT Ref ((%CONFIG;)*)>
<!ATTLIST Ref %REQUIREDIDATTR;>


<!--
Array Element.
This element allows the creation of a new array as part of a
value of elements such as Set, Put, Arg, etc. The type attribute determines
the type of the new array and the contained Item elements
are used for each element of the array:

 <Array type="java.lang.String">
   <Item>value0</Item>
   <Item><New class="java.lang.String"><Arg>value1</Arg></New></Item>
 </Array>

This is equivalent to:
 String[] a = new String[] { "value0", new String("value1") };
-->
<!ELEMENT Array (Item*)>
<!ATTLIST Array %TYPEATTR; %IDATTR; >


<!--
Map Element.
This element allows the creation of a new map as part of a
value of elements such as Set, Put, Arg, etc. The type attribute determines
the type of the new array and the contained Item elements
are used for each element of the array:

 <Map>
   <Entry>
     <Item>keyName</Item>
     <Item><New class="java.lang.String"><Arg>value1</Arg></New></Item>
   </Entry>
 </Map>

This is equivalent to:
 Map m = new HashMap();
 m.put("keyName", new String("value1"));
-->
<!ELEMENT Map (Entry*)>
<!ATTLIST Map %IDATTR; >
<!ELEMENT Entry (Item,Item)>


<!--
Item Element.
This element defines an entry for the Array or Map Entry elements.
The optional type attribute can force the type of the value.

An Item element can contain value text and/or the value object of
elements such as Call, New, SystemProperty, etc. If no value type
is specified, then white space is trimmed out of the value.
If it contains multiple value elements they are added as strings
before being converted to any specified type.
-->
<!ELEMENT Item ( %VALUE; )* >
<!ATTLIST Item %TYPEATTR; %IDATTR; >


<!--
System Property Element.
This element allows JVM System properties to be retrieved as
part of the value of elements such as Set, Put, Arg, etc.
The name attribute specifies the property name and the optional
default argument provides a default value.

 <SystemProperty name="Test" default="value" />

This is equivalent to:

 System.getProperty("Test","value");
-->
<!ELEMENT SystemProperty EMPTY>
<!ATTLIST SystemProperty %NAMEATTR; %DEFAULTATTR; %IDATTR;>


<!--
Property Element.
This element allows arbitrary properties to be retrieved by name.
The name attribute specifies the property name and the optional
default argument provides a default value.

A Property element can contain a sequence of elements such as Set, Put, Call, etc.
which act on the retrieved object:

 <Property name="Server">
   <Call id="jdbcIdMgr" name="getAttribute">
     <Arg>jdbcIdMgr</Arg>
   </Call>
 </Property>
-->
<!ELEMENT Property ((%CONFIG;)*)>
<!ATTLIST Property %NAMEATTR; %DEFAULTATTR; %IDATTR;>

一个简单的例子（摘自：http://www.blogjava.net/xylz/archive/2012/04/12/372999.html）：

在Jetty中，所有XML文件的配置使用Descriptor来表达，而对这些Descriptor的处理使用DescriptorProcessor来实现。

Descriptor和DescriptorProcessor类图

Descriptor实现

Descriptor可以表达一个*.tld文件（TldDescriptor）、一个/META-INF/web.xml文件(WebDescriptor)，一个/org/eclipse/jetty/webapp/webdefault.xml（DefaultsDescriptor），一个/META-INF/web-fragment.xml文件（FragmentDescriptor），一个override-web.xml文件（OverrideDescriptor）。其中TldDescriptor在TagLibConfiguration的TagListener中查找并使用TldProcessor解析；WebDescriptor在WebXmlConfiguration的preConfigure中查找，并设置到MetaData的webXmlRoot字段中，并更新MetaData的ordering字段，其资源文件可以手动设置WebAppContext的descriptor字段，或者未设置而使用META-INF/web.xml文件；DefaultsDescriptor也在WebXmlConfiguration的preConfigure中查找，并设置到MetaData的webDefaultsRoot字段中，并更新MetaData的ordering字段，其资源文件可以手动设置WebAppContext中的defaultsDescriptor字段，或未设置而默认使用/org/eclipse/jetty/webapp/webdefault.xml文件；OverrideDescriptor也在WebXmlConfiguration的preConfigure中查找，并设置到MetaData的webOverrideRoots集合中，并更新MetaData中的ordering字段，其资源文件可以手动设置，如果未设置，则忽略；而FragmentDescriptor则是在FragmentConfiguration中的preConfigure中添加到MetaData的webFragmentResourceMap、webFragmentNameMap以及webFragmentRoots中，如果MetaData的ordering为null，且不为absolute，则更新ordering字段。

每个Descriptor使用一个xml的Resource实例作为构造函数构建，并使用XmlParser将其解析成类DOM树，保存树的root节点引用。

除了TldDescriptor在TagLibConfiguration中已经处理完成，其他的Descriptor使用StandardDescriptorProcessor以及PlusDescriptorProcessor来处理，其中StandardDescriptorProcessor在WebXmlConfiguration的configure方法中注册到MetaData的descriptorProcessors集合中，而PlusDescriptorProcessor在PlusConfiguration的configure方法中注册到MetaData中。并在MataData的resolve方法中使用注册的DescriptorProcessor依次解析webDefaultsRoot、webXmlRoot、webOverrideRoots以及webFragmentRoots对应的Descriptor实例。

DescriptorProcessor实现

DescriptorProcessor只有一个process方法，他遍历传入的Descriptor的所有Node，并对不同Node做相应的处理。在IterativeDescriptorProcessor的采用了非常巧妙的实现方法，即使用一个visitors的Map，包含节点的tag到相应处理方法的映射，因而在IterativeDescriptorProcessor的实现中，它遍历Descriptor的节点树，对每个节点查找对应的处理方法，并调用查找到的方法，其子类的实现只需要注册这个visitors的Map，然后实现注册的方法即可；为了增加可扩展性，在解析前和解析后分别添加了start、end的插入点。

如在StandardDescriptorProcessor中，注册了如下几个visitor方法：
context-param => visitContextParam 向WebAppContext添加InitParam信息。

display-name => visitDisplayName 向WebAppContext设置displayName属性。
servlet => visitServlet 向ServletHandler中添加一个新的ServletHolder，并配置其servlet-name、init-param、servlet-class、jsp-file、load-on-startup、security-role-ref、run-as、async-supported、enabled、multipart-config等信息；如果id设置为jsp，则会在InitParam中配置scratchdir、classpath参数，以及为Jasper配置com.sun.appserv.jsp.classpath参数，而在WebAppContext中为Jasper配置org.apache.catalina.jsp_classpath属性；用于注册org.apache.jasper.servlet.JspServlet；对jsp-file，设置其forcePath为该值。

servlet-mapping=> visitServletMapping 配置ServletHandler中servlet-name对应的ServletMapping信息。

session-config => visitSessionConfig 设置SessionHandler中SessionManager的一些配置信息。

mime-mapping => visitMimeMapping 设置WebAppContext中extension到mimeType的映射。

welcome-file-list => visitWelcomeFileList 设置WebAppContext中的welcomeFiles。

locale-encoding-mapping-list => visitLocaleEncodingList 设置WebAppContext中locale到encoding的映射关系。

error-page => visitErrorPage 设置ErrorPageErrorHandler中errorCode或exceptionType到location的映射关系。

taglib => visitTagLib 设置taglib-uri到taglib-location的映射关系，即WebAppContext中taglib-uri是taglib-location的alias。

jsp-config => visitJspConfig 将jsp-property-group下url-pattern映射到JspServlet中。

security-constraint => visitSecurityConstraint 向SecurityHandler中添加ConstraintMapping。

login-config => visitLoginConfig 向SecurityHandler中设置AuthMethod、RealmName属性，以及对FORM方法的验证，设置login、error页面的InitParam。

security-role => visitSecurityRole 向SecurityHandler中注册定义的role集合。

filter => visitFilter 向ServletHandler注册FilterHolder，并配置filter-name、filter-class、init-param、async-supported等信息。

filter-mapping => visitFilterMapping 向ServletHandler注册FilterMapping信息。

listenr => visitListener 向WebAppContext注册EventListener。

distributable => visitDestributable 设置WebDescriptor的distributable属性为true。

在PlusDescriptorProcessor中，首先在其start方法中会向WebAppContext注册InjectionCollection、LifeCycleCallbackCollection、RunAsCollection（该属性在RunAsAnnotationHandler中使用）属性，并且注册了以下几个visitor方法：
env-entry => visitEnvEntry 向InjectionCollection添加Injection实例，其中jndiName为env-entry-name定义的值，valueClass为env-entry-type定义的类型，而targetClass、targetName为injection-target下的injection-target-class、injection-target-name中定义的值，每个injection-target生成一个Injection实例。同时将env-entry-value中定义的值绑定到java:com/env/<name>对应的资源中。（Injection实例也可以使用@Resource注解注册，并在ResourceAnnotationHandler中解析）

resource-ref => visitResourceRef 向InjectionCollection添加Injection实例，其中jndiName为res-ref-name，typeClass为res-type，并绑定该引用资源。

resource-env-ref => visitResourceEnvRef 向InjectionCollection添加Injection实例，其中jndiName为resource-env-ref-name，typeClass为resource-env-ref-type，并绑定该env引用资源。

message-destination-ref => visitMessageDestinationRef 向InjectionCollection添加Injection实例，其中jndiName为message-destination-ref-name，typeClass为message-destination-type，并绑定该message-destination引用资源。

post-construct => visitPostConstruct 向LifeCycleCallbackCollection注册一个PostConstructCallback，其targetClass由lifecycle-callback-class定义，而method由lifecycle-callback-method定义（该PostConstructCallback也可以使用@PostConstruct的Annotation方式注册，并在PostConstructAnnotationHandler中解析）。

pre-destroy => visitPreDestroy 向LifeCycleCallbackCollection注册PreDestroyCallback，其targetClass由lifecycle-callback-class定义，methodName由lifecycle-callback-method定义（该PreDestroyCallback也可以使用@PreDestroy注解注册，并在PreDestroyAnnotationHandler中解析）。

所有以上注册的RunAsCollection、InjectionCollection、LifeCycleCallbackCollection都在PlusDecorator中使用，PlusDecorator类实现Decorator方法，在所有的decorate实现方法中，使用RunAsCollection向ServletHolder中注册配置的roleName（感觉这里有bug，应该是decorate一个Servlet而不是ServletHolder）；使用InjectionCollection向Servlet、Filter、EventListener注入JNDI对应的值；使用LifeCycleCallbackCollection调用所有注册的PostConstruct方法。而在destroyServlet、Filter实例时，使用LifeCycleCallbackCollection调用素有注册的PreDestroy方法。

Jetty对Servlet Security实现概述和类图

UserIdentity实现

IdentityService实现

LoginService实现

Authenticator实现

SecurityHandler与ConstraintSecurityHandler实现

ServletHandler的成员

doScope方法实现

doHandle方法实现

AsyncContext

RequestDispatcher

HttpSession

SessionHandler

ServletRequest

ServletResponse

Jetty中的Holder

Servlet

Filter

Registration

Holder实现

FilterHolder实现

ServletHolder实现

概述

ServletContext

public interface ServletContext {
    // Servlet Container为当前Web Application设置临时目录，并将该临时目录的值存储到当前ServletContext的属性中使用的属性名。
    // Jetty使用WebInfConfiguration(在preConfig ure()方法中)来设置该值，设置temp目录的规则：
    // 1. 如果存在WEB-INF/work目录，则temp目录的值为：WEB-INF/work/Jetty_<host>_<port>__<resourceBase>_<context>_<virtualhost+base36_hashcode_of_whole_string>
    // 2. 如果"javax.servlet.context.tempdir"已经在外部被设置，并且该目录存在且可写，则temp目录直接设置为该目录实例。
    // 3. 如果系统变量中"jetty.home"目录下存在"work"目录且可写，则设置temp目录的值为：${jetty.home}/work/Jetty_<host>_<port>__<resourceBase>_<context>_<virtualhost+base36_hashcode_of_whole_string>
    // 4. 如果存在"org.eclipse.jetty.webapp.basetempdir"的属性，且该目录存在并可写，设置temp目录为：${org.eclipse.jetty.webapp.basetempdir}/Jetty_<host>_<port>__<resourceBase>_<context>_<virtualhost+base36_hashcode_of_whole_string>
    // 5. 如果以上条件都不成立，则设置temp目录为：${java.io.tmpdir}/Jetty_<host>_<port>__<resourceBase>_<context>_<virtualhost+base36_hashcode_of_whole_string>，且删除已存在临时目录。
    // 注：对temp目录的父目录不是work，会注册在JVM退出时删除该temp目录，并在temp目录下创建.active目录。

    public static final String TEMPDIR = "javax.servlet.context.tempdir";
    // Servlet 3.0中新引入的特性，即可以在WEB-INF/lib下的jar包中定义/META-INF/web-fragment配置响应的Servlet等。
    // 如果在web.xml文件中定义了absolute-ordering，或者在jar包中存在/META-INF/web-fragment.xml文件，且定义了ordering，
    // 则该属性的值即为根据规范中定义的规则计算出来的读取jar包中web-fragment.xml文件的jar包名顺序，它时一个List<String>类型，包含jar包名字。
    // 在Jetty中使用Ordering来表示这种顺序，它有两个实现类：AbsoluteOrdering和RelativeOrdering用来分别表示在web.xml和web-fragment.xml中定义的absolute-ordering和ordering定义，
    // 并且将最终的解析结果汇总到Metadata类中，并根据规范中定义的规则以及metadata-complete的定义来计算实际的解析顺序，
    // 而对这两种配置文件的解析由WebDescriptor和FragmentDescriptor来实现，它们都包含了metadata-complete解析，而真正的解析入口在WebXmlConfiguration和FragmentConfiguration中。
    // 该规范的定义参考：https://blogs.oracle.com/swchan/entry/servlet_3_0_web_fragment
    public static final String ORDERED_LIBS = "javax.servlet.context.orderedLibs";

    // 返回当前Web Application的Context Path，即当前Web Application的根路径，Servlet Container根据该路径以及一个Request URL的匹配情况来选择一个Request应该交给那个Web Application处理该请求。
    // Context Path以"/"开始，但是不能以"/"结尾，对默认的根Context，它返回""，而不是"/"。该值在配置Jetty的ContextHandler中设置。
    // 有些Servlet Container支持多个Context Path指向同一个Context，此时可以使用HttpServletRequest中的getContextPath()来获取该Request实际对应的Context Path，此时这两个Context Path的值可能会不同，但是ServletContext中返回的Context Path值是主要的值。另外Jetty也不支持这种特性。
    public String getContextPath();

    // 通过给定一个Context Path以在当前Servlet Container中找到其对应的ServletContext实例。
    // 可以通过该方法获取Servlet Container中定义的另一个Web Application的ServletContext实例，并获得其RequestDispatcher，并将当前请求Dispatch到那个Web Application中做进一步的处理。这里的uripath必须以"/"开头，且其路径相对于当前Server的根路径。出于安全考虑，该方法可能会返回null。
    // 在Jetty的实现中，这里uripath可以是一个具体的路径，并且支持查找最准确的匹配。如：对uripath为/foo/goo/abc.html，在Server中由以下Context Path定义："/", "/foo", "/foo/goo"，则最终查找到的ServletContext为"/foo/goo"作为Context Path对应的ServletContext实例。
    public ServletContext getContext(String uripath);
    
    //返回Servlet规范的主版本，如3
    public int getMajorVersion();
    // 返回Servlet规范的次版本，如0
    public int getMinorVersion();
    // 返回当前Web Application基于的Servlet规范的主版本，如在web.xml文件中定义的version(<web-app version="..." ...>...</web-app>，即Jetty中的实现)
    public int getEffectiveMajorVersion();
    // 返回当前Web Application基于的Servlet规范的次版本，如在web.xml文件中定义的version(<web-app version="..." ...>...</web-app>，即Jetty中的实现)
    public int getEffectiveMinorVersion();


    // 返回给定file的MIME type，返回null如果无法计算出其MIME type。这个映射关系由Servlet Container定义或在web.xml文件中定义(mime-mapping, extension, mine-type)。
    // 常见的MIME type有：text/html, image/gif等。Jetty使用MimeTypes类来封装所有和MIME type相关的操作，MimeTypes类中定义了所有默认支持的MIME type以及编码类型，
    // 并且默认从org/eclipse/jetty/http/mime.properties文件中加载默认的映射，如css=text/css, doc=application/msword等，使用addMimeMapping()方法向该类注册web.xml中定义的文件名扩展名到MIME type的映射。
    // 而从org/eclipse/jetty/http/encoding.properties文件中加载MIME type的默认编码类型，如text/xml=UTF-8等。
    // 在使用文件名查找MIME type时，根据文件名的扩展名查找已注册或默认注册的MIME type。用户自定义的映射优先。用户定义的MIME type映射支持extension为"*"，表示任意扩展名。
    public String getMimeType(String file);
    
    // 对于给定目录，返回该目录下所有的资源以及目录。path必须以"/"开头，如果它不是指向一个目录，则返回空的Set。所有返回的路径都相对当前Web Application的根目录，
    // 或对于/WEB-INF/lib中jar包中的/META-INF/resources/目录，如一个Web Application包含以下资源：/catalog/offers/music.html, /WEB-INF/web.xml,
    // 以及/WEB-INF/lib/catalog.jar!/META-INF/resources/catalog/moreOffers/books.html，则getResourcePaths("/catalog")返回{"/catalog/offers/", /catalog/moreOffers/"}
    // Jetty的实现中，在MetaInfConfiguration中，它会扫描WEB-INF/lib目录下所有的jar包，如果发现在某个jar包中存在META-INF/resources/目录，
    // 就会将该目录资源作为baseResource在WebInfConfiguration中注册到ContextHandler(WebAppContext)中。从而实现jar包中的META-INF/resources/目录作为根目录的查找。  
    public Set<String> getResourcePaths(String path);
    
    // 返回给定path的URL，path必须以"/"开头，它相对当前Web Application的根目录或相对/WEB-INF/lib中jar包中的/META-INF/resources/目录。
    // 其中查找顺序前者优先于后者，但是在/WEB-INF/lib/目录下的jar包的查找顺序未定义。该方法不同于Class.getResource()在于它不使用ClassLoader，如果没有找到给定资源，返回null。
    // 在WebAppContext实现中，它还支持Alias查找，并且如果其extractWAR的变量为false，给定的资源在WAR包中，则该URL返回WAR包中的URL。    
    public URL getResource(String path) throws MalformedURLException;
    
    // 参考getResource(path)的查找实现，如果其返回的URL为null，则该方法返回null，否则返回URL对应的InputStream。
    public InputStream getResourceAsStream(String path);

    // 创建一个RequestDispatcher用于将一个Request、Response分发到path对应的URL中，这里path必须以"/"开头，且它相对于当前Context Path。如果无法创建RequestDispatcher，返回null。
    // path可以包含query数据用于传递参数：uriInContext?param1=abc&param2=123....该方法可以和getContext(uripath)一起使用，以将当前请求分发到另一个Web Application中。
    // 该方法的另一种用法是先有一个Servlet或Filter处理基本的逻辑，然后使用这个RequestDispatcher将当前请求forward到另一个URL中或include一个JSP文件生成响应页面，如果在处理过程中出错，则将其当前请求分发到错误处理的流程中。
    // RequestDispatcher支持两种类型的分发：forward和include，唯一的区别是include只可以改变Response的内容，不可以改变其Header信息，forward则没有这种限制。
    public RequestDispatcher getRequestDispatcher(String path);

    // 创建一个RequestDispatcher用于将一个Request、Response分发到name对应的Servlet(JSP)中。如果没能找到响应的Servlet，返回null。
    public RequestDispatcher getNamedDispatcher(String name);    

    // 将msg打印到Servlet对应的log文件中，在Jetty中，使用INFO级别打印，logger名称为web.xml定义的display-name，或者context path。
    // Jetty默认使用SLF4J作为日志打印框架，可以使用"org.eclipse.jetty.util.log.class"系统属性改变其日志打印框架。
    public void log(String msg);   

    // 打印message和throwable到Servlet对应的log文件中，在Jetty中使用WARN级别打印该信息。
    public void log(String message, Throwable throwable);

    // 返回给定path在当前机器上操作系统对应的位置。对/META-INF/resources下的资源，除非他们已经解压到本地目录，否则对那些资源该方法返回null。
    // 在Jetty实现中，使用getResource()方法相同的实现获取Resource实例，如果其getFile()返回不为null，则返回该File的canonical路径。
    public String getRealPath(String path);

    // 返回Servlet Container的名称和版本号，其格式为：<servername>/<versionnumber>，如：Jetty/8.1.9.v20130131。
    public String getServerInfo();

    // ServletContext级别的初始参数操作，可以在web.xml中使用context-param定义，也可以手动设置。在get中如果找不到对应的项，返回null，在set时，如果已存在name，则返回false，并且不更新相应的值。
    public String getInitParameter(String name);
    public Enumeration<String> getInitParameterNames();
    public boolean setInitParameter(String name, String value);

    // ServletContext级别的属性操作，其中属性名遵循包命名规则。在set中，如果object为null表示移除该属性，如果name以存在，则会替换原有的值，如果注册了ServletContextAttributeListener，则会出发相应的attributeRemoved、attributeReplaced、attributeAdded事件。在remove中，如果name存在且被移除了，则会触发attributeRemoved事件。
    // 在Jetty中使用ContextHandler中的Context内部类实现ServletContext，在ContextHandler中定义了两个相关字段：_attributes以及_contextAttributes，其中_attributes表示在Jetty内部通过ContextHandler设置的属性，而_contextAttributes表示用户设置的属性，但是在获取属性值时，两个字段的属性都会考虑进去，在移除属性时，如果是移除_attributes字段中的值，则不会触发attributeRemoved事件。
    public Object getAttribute(String name);
    public Enumeration<String> getAttributeNames();
    public void setAttribute(String name, Object object);
    public void removeAttribute(String name);

    // 返回当前Web Application在web.xml中的display-name定义的ServletContext名字，在Jetty实现中，如果该值为null，则返回context path。
    public String getServletContextName();

    // 该部分具体的使用可以参考：http://www.blogjava.net/yongboy/archive/2010/12/30/346209.html 

    // 动态的向ServletContext中注册Servlet，注册的Servlet还可以通过返回的ServletRegistration继续配置，如addMapping、setInitParameter等。
    // 在使用className实例话Servlet时，使用当前ServletContext相关联的ClassLoader。在创建Servlet实例时，会根据该类中定义的以下Annotation做相应的配置：
    // javax.servlet.annotation.ServletSecurity、javax.servlet.annotation.MultipartConfig、javax.annotation.security.RunAs、javax.annotation.security.DeclareRoles
    public ServletRegistration.Dynamic addServlet(String servletName, String className);
    public ServletRegistration.Dynamic addServlet(String servletName, Servlet servlet);
    public ServletRegistration.Dynamic addServlet(String servletName, Class <? extends Servlet> servletClass);
    // 创建给定Servlet类的Servlet实例，并且会根据该类中定义的以下Annotation做相应的配置：
    // javax.servlet.annotation.ServletSecurity、javax.servlet.annotation.MultipartConfig、javax.annotation.security.RunAs、javax.annotation.security.DeclareRoles
    // 在创建Servlet实例后，一般还要调用addServlet()方法将其注册到ServletContext中。
    public <T extends Servlet> T createServlet(Class<T> clazz) throws ServletException;
    // 根据servletName获取ServletRegistration实例
    public ServletRegistration getServletRegistration(String servletName);
    // 获取所有在ServletContext中注册的servletName到ServletRegistration映射的Map。所有动态注册和使用配置注册的映射。
    public Map<String, ? extends ServletRegistration> getServletRegistrations();

    // 动态的向ServletContext中注册Filter，注册的Filter可以通过返回的FilterRegistration进一步配置，如addMappingForUrlPatterns、setInitParameter等
    public FilterRegistration.Dynamic addFilter(String filterName, String className);
    public FilterRegistration.Dynamic addFilter(String filterName, Filter filter);
    public FilterRegistration.Dynamic addFilter(String filterName, Class <? extends Filter> filterClass);
    // 创建给定Filter类实例的Filter实例，一般都会后继调用addFilter将该实例注册到ServletContext中。
    public <T extends Filter> T createFilter(Class<T> clazz) throws ServletException;
    // 根据filterName获取FilterRegistration实例。
    public FilterRegistration getFilterRegistration(String filterName);
    // 返回所有filterName到FilterRegistration映射的Map，包括所有动态注册和使用配置注册的映射。
    public Map<String, ? extends FilterRegistration> getFilterRegistrations();

    // 返回SessionCookieConfig实例，用于session tracking的cookie属性，多次调用该方法返回相同的实例。
    public SessionCookieConfig getSessionCookieConfig();
    // 设置session tracking模式，可以是URL、COOKIE、SSL。Jetty8只支持URL和COOKIE。
    public void setSessionTrackingModes(Set<SessionTrackingMode> sessionTrackingModes);
    // 返回当前ServletContext默认支持的session tracking模式。
    public Set<SessionTrackingMode> getDefaultSessionTrackingModes();
    // 返回当前ServletContext目前使用的session tracking模式。
    public Set<SessionTrackingMode> getEffectiveSessionTrackingModes();

    // 向ServletContext动态的注册Listener，该Listener类或实例必须实现以下的一个或多个接口：
    // ServletContextAttributeListener、ServletRequestListener、ServletRequestAttributeListener、HttpSessionListener、HttpSessionAttributeListener}</tt>
    // 如果这个ServletContext传入ServletContainerInitializer的onStartup方法，那么这个Listener类或实例也可以实现ServletContextListener接口。
    // 注：动态注册的ServletContextListener中的contextInitialized方法中不可以调用Servlet 3.0中定义的这些动态注册Servlet、Filter、Listener等方法，不然会抛出UnsupportedOperationException，看起来像是出于一致性、安全性或是兼容性的考虑，但是具体是什么原因一直想不出来。而且在Jetty实现中，它在注册EventListener实例是确取消了这种限制，而对注册EventListener类实例和类名确有这种限制，不知道这是Jetty的bug还是其他什么原因。。。。。
    // 对于调用顺序按定义顺序来的EventListener(如ServletRequestListener、ServletContextListener、HttpSessionListener)，那这个新的EventListener会添加到相应列表末尾。
    public void addListener(String className);
    public <T extends EventListener> void addListener(T t);
    public void addListener(Class <? extends EventListener> listenerClass);
    // 创建clazz对应的EventListener实例，一般这个新创建的EventListener会之后注册到ServletContext中。
    public <T extends EventListener> T createListener(Class<T> clazz) throws ServletException; 

    // 返回web.xml和web-fragment.xml配置文件中定义<jsp-config>的汇总，或返回null如果没有相关配置。看起来像Jetty并没有实现该方法。
    public JspConfigDescriptor getJspConfigDescriptor();

    // 返回当前Web Application对应的ClassLoader实例。
    public ClassLoader getClassLoader();

    // 定义角色名。角色名在ServletRegistration.Dynamic.setServletSecurity()和ServletRegistration.Dynamic.setRunAsRole()中默认定义，因而不需要重新使用这个方法定义。
    public void declareRoles(String roleNames);
}

ServletContext初始化

实现

使用

Handler接口定义

Handler类图

AbstractHandler

DefaultHandler

DumpHandler

ErrorHandler

ErrorPageErrorHandler

ResourceHandler

AbstractHandlerContainer

HandlerCollection

HandlerList

ContextHandlerCollection

HotSwapHandler

HandlerWrapper

ConnectHandler

DebugHandler

IPAccessHandler

RequestLogHandler

StatisticsHandler

Connector类图

Connector接口

AbstractConnector实现

SocketConnector实现

SelectChannelConnector实现

BlockingChannelConnector实现

Generator接口

请求行和响应行设置
请求行包括请求方法、URI、HTTP协议版本，响应行包括HTTP协议版本、状态码、状态短语，因而在Generator接口中定义了各自的设置方法：

Parser接口定义

EventHandler定义

HttpPaser有限状态机实现

HttpParser在HttpConnection类中的使用

Connection接口定义

Connection类图

HttpConnection实现

1. 它首先设置_handling字段，表示当前正在处理，并且将当前HttpConnection实例设置到__currentConnection的ThreadLocal变量中。
   
2. 循环处理请求消息直到EndPoint关闭或者在more_in_buffer为true（初始值为true）。
3. 如果当前Request处于Async状态，并且还Async状态还没有结束，直接调用handleRequest()方法，如果Async状态结束了，但是HttpParser还没有结束，则继续使用HttpParser解析，在解析过程中，可能会在headerComplete()、content()、messageComplete()回调函数中调用handleRequest()方法（具体参见HttpParser的实现）；而后在HttpGenerator已经Commit(所有的响应头已经准备好，并已经写入到EndPoint中)，但是还没有完成的情况下，将HttpGenerator中的数据Flush到EndPoint中；此时如果EndPoint还存在输出缓存，则将其Flush到底层链路中。
4. 如果当前Request没有处于Async状态，如果HttpPaser还没有结束，使用HttpParser解析，在解析过程中，可能会在headerComplete()、content()、messageComplete()回调函数中调用handleRequest()方法（具体参见HttpParser的实现）；而后在HttpGenerator已经Commit(所有的响应头已经准备好，并已经写入到EndPoint中)，但是还没有完成的情况下，持续的将HttpGenerator中的数据Flush到EndPoint中，如果EndPoint还存在输出缓存，则将其Flush到底层链路中；如果HttpGenerator已经处于完成状态，但是EndPoint中还有输出缓存数据，此时将这些数据Flush到底层链路，如果写完缓存中的数据，将progress设置为true，表示handle方法需要继续处理。
5. 在这些过成中如果出现任何HttpException，则使用HttpGenerator发送错误响应码给客户端(使用sendError()方法，并关闭EndPoint)。
6. 如果HttpParser中还有数据未处理或者EndPoint中还有输入数据未处理，则循环继续。
   
7. 如果此时HttpParser已经处理完成，HttpGenerator已经处理完成，并且EndPoint中的输出缓存中已经没有任何数据：1. 如果响应状态码时101 Switching Protocols，且在Request存在org.eclipse.jetty.io.Connection的Connection实例，则新的Connection从Request的该Attribute中获取，并重置HttpParser和HttpGenerator；2. 如果Request不存在该Attribute的Connection，HttpGenerator非persisent状态或EndPoint的InputStream已经关闭，则重置HttpParser，关闭EndPoint，设置more_in_buffer为false，重置当前HttpConnection。
8. 如果HttpParser处于idle状态，并且EndPoint的InputStream已经关闭，则关闭当前EndPoint，并设置more_in_buffer为false。
9. 如果Request的Async处于启动状态，则设置more_in_buffer为false。
10. 如果EndPoint是AsyncEndPoint，Generator已经Commit，但是还未Complete，则该EndPoint schedule一个write操作。
11. 最后，清理_handle字段和__currentConnection的ThreadLocal字段。

1. 对任何Request还没有处理完成，并且Server不为null且处于Running状态，循环处理。
2. 设置Request的handled为false，以及PathInfo字段（如果pathInfo为null，又不是Connect请求，则为400 Error）。
3. 如果_out字段不为null，reopen it。
   
4. 如果Request处于initial状态，设置Request的DispatcherType为REQUEST，使用当前的EndPoint和Request实例配置Connector，并调用使用当前HttpConnection作为参数调用Server的handle()方法；否则，设置Request的DispatcherType为ASYNC，调用Server的handleAsync()方法(传入当前HttpConnection做为参数)。
5. 对任何非ContinuationThrowable异常，设置Request的handled为true，error为true，对HttpException使用Response发送响应状态码给客户端，而对Throwable，使用HttpGenerator发送400或500状态码给客户端。
6. 如果此时Request处于为完成状态，调用AsyncContinuation.doComplete()方法；如果100 Continue响应没有发送给客户端，则清除该状态，但是如果此时Response还没有Commit，则设置HttpGenerator的persistent为false，表示客户端并没有发送数据过来，我们可以关闭该连接了；如果EndPoint关闭了，则调用Response的complete方法；如果EndPoint没有关闭并且有error，直接关闭EndPoint；如果EndPoint没有关闭，也没有error，但是HttpGenerator没有Commit，Request也没有被handle，则使用resonse发送404 Resource Not Found响应消息，之后调用Response的complete方法；最后设置Request的handled为true。

1. 在HttpGenerator还没有Commit之前（即响应状态行和响应消息头还没写入到EndPoint中）时，先调用HttpGenerator的setResponse()方法设置状态行。
2. 然后调用HttpGenerator的completeHeader()方法将响应消息头写入到EndPoint中。
3. 最后调用HttpGenerator的complete方法，不断的将HttpGenerator中的缓存写入到EndPoint中。

EndPoint接口定义

EndPoint类图

EndPoint接口定义概述

StreamEndPoint实现

ChannelEndPoint实现

Buffer接口定义

类图

主要实现类

Buffers

BufferCache/BufferDateCache

请求消息

POST /index.jsp?articleId=1234&articleName=GoodArticle HTTP/1.1
Host: www.blogjava.com
Content-Length: 74
Content-Type: application/x-www-form-urlencoded
myText1=hello+world&myText2=%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C

请求方法：

HTTP1.1定义的请求方法有

OPTIONS：
请求查询服务器的性能，或查询与资源相关的选项和需求。

GET：
请求获取Request-URI所标识的资源。

HEAD：
请求获取由Request-URI所标识的资源的响应消息报头。

POST：
在Request-URI所标识的资源后附加新的数据。

PUT：
请求服务器存储一个资源，并用Request-URI作为其标识。

DELETE：
请求服务器删除Request-URI所标识的资源。

TRACE：
请求服务器会送收到的请求信息，主要用于测试或诊断。

CONNECT：
保留将来使用。

扩展的方法：
用户自定义扩展方法。

如果Server能识别某个请求方法但是不允许该请求方法，则应该返回405（Method Not Allowed）响应状态。如果Server无法识别某个请求方法或者当前Server没有实现这个请求方法，则应该返回501（Not Implemented）状态码。

Request－URI支持的值有：＊｜absoluteURI｜abs_path｜authority

1. ＊表示请求不应用于某个特定的资源，并且只对于某些不需要应用于特定资源的请求方法，如：OPTIONS * HTTP/1.1
2. absoluteURI：当客户端是向一个代理发送请求时需要使用absoluteURI，然后这个代理会转发这个请求，并返回响应。虽然按规范，HTTP1.1客户端只发送absoluteURI到代理服务器，但是为了在将来的HTTP版本中可以允许请求都转换成absoluteURI，所有HTTP1.1 Server必须可以解析absoluteURI风格的请求：GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
3. authority只在CONNECT请求方法中使用。
4. abs_path：用于表示Server的资源，而Server本身的信息在Host消息头中表示：

   GET /put/www/TheProject.html HTTP/1.1

   Host: www.w3.org

Resource Identification rules：

1. 如果Request－URI是absoluteURI，并且这个absolute的host和server的host相同，则忽略Host头。
2. 如果Request－URI不是absoluteURI，并且请求消息包含Host头，host由Host消息头决定。
3. 如果1或2中的host不是一个合法的host，则返回400（Bad Request）响应消息。

响应消息

HTTP/1.1 200 OK                                              //请求成功
Server: Microsoft-IIS/5.0                                    //web服务器
Date: Thu,08 Mar 200707:17:51 GMT
Connection: Keep-Alive                                 
Content-Length: 23330
Content-Type: text/html
Expries: Thu,08 Mar 2007 07:16:51 GMT
Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/
Cache-control: private

杂记

消息报头详解

通用消息头：

Cache-Control: 

Connection:
客户端通过发送包含close值的Connection头，表达在这次请求结束后，Server可以关闭这个连接，此时Server如果选择发送响应后关闭连接，则在响应消息中需要包含值为close的Connection头。 

Date: 

Pragma: 

Trailer: 

Transfer-Encoding: 

Upgrade: 

Via: 

Warning: 

请求消息头：

请求消息头允许客户端传递一些额外关乎客户端信息给Server，这些字段类似在方法调用中的参数。

Accept: 

Accept-Charset: 

Accept-Encoding: 

Accept-Language: 

Authorization: 

Expect:
客户端发送一个包含100-continue值的Expect字段头，以在不发送真正消息实体的情况下测试服务器是否能接收这个消息。此时Server响应417（Expectation Failed）或100（Continue），然后客户端决定是否要继续发送请求消息体。

From: 

Host: 

If-Match: 

If-Modified-Since: 

If-None-Match: 

If-Range: 

If-Unmodified-Since: 

Max-Forwards: 

Proxy-Authorization: 

Range: 

Referer: 

TE: 

User-Agent: 

响应消息头

响应消息头允许Server传递一些关于响应的额外信息给客户端。

Accept-Ranges: 

Age: 

ETag: 

Location: 

Proxy-Authenticate: 

Retry-After: 

Server: 

Vary:

WWW-Authenticate: 

实体消息头

实体消息头属于实体的一部分，是实体的元数据。

Allow: 

Content-Encoding: 

Content-Language: 

Content-Length: 

Content-Location: 

Content-MD5: 

Content-Range: 

Content-Type: 

Expires: 

Last-Modified: 

响应状态码详解

1xx: Informational - Request received, continuing process

1. 100 - Continue
   
   客户端应该继续它的请求，这个暂时的响应用于通知客户端初始的请求已经被服务器接受，并且暂时没有被拒绝。此时客户端会继续发送剩余的请求，或者当所有请求已经发送完成时忽略该响应码。服务器必须在请求结束时发送一个最终的响应。
2. 101 - Switching Protocols
   
   服务器理解并打算执行客户端的请求，并且使用“Upgrade”字段头用户表示服务器会在这个连接中的协议升级到“Upgrade”头标识的版本号。

2xx: Success - The action was successfully received, understood, and accepted

1. 200 - OK
   
   请求成功处理。
2. 201 - Created
   
   请求成功处理并且新的资源被创建。新创建的资源可以使用URI标识，并且该URI在响应消息的Location头中。服务器在返回201响应时必须保证新的资源已经被创建，如果服务器在返回响应时还没来得及创建新的资源，服务器应该返回202（Accepted）响应。
   201响应还可以包含“ETag”响应头，表示实体标签的当前值。
3. 202 - Accepted
   
   请求被接受并处理，但是处理还未完成。这个请求不一定被成功执行，并且也不会在有结果后重新异步发送响应消息。该响应状态主要用于一些类似batch的操作，当客户发送请求以后，不需要继续保持和服务器的连接。返回的消息实体需要包含请求当前的状态以及一个指向状态监视器或客户能得到结果的估计值。
4. 203 - Non-Authoritative Information
   
   响应消息实体头部返回的元信息不是在原始服务器有效的集合，而是从本地或第三方中拷贝收集。当前的集合可能是原始集合的子集或超集，这个响应码不是必须的，可以使用200（OK）替代。
5. 204 - No Content
   
   服务器已经成功的完成请求，该请求没有消息实体，只是返回一些最新的元信息。
6. 205 - Reset Content
   
   服务器已经成功的完成请求，客户端必须重置由该请求引起的文档视图。该响应主要用于清除用于之前输入的表单。该响应不可以包含消息实体。
7. 206 - Partial Content
   
   服务器已经成功完成“Partial GET”的请求。该响应的请求必须包含“Range”头，以及可选的“If-Range”头。响应必须包含以下头：Content-Range（或值为multipart/byteranges的Content-Type头）、Date、ETag或Content-Location、Expires、Cache-Control、Vary等。

3xx: Redirection - Further action must be taken in order to complete the request

1. 300 - Multiple Choices
   
   当前请求包含多个资源，并且在返回消息中包含每个资源的location信息。客户端可以根据一定的算法自行选择使用那个资源（没有定义算法）。服务器也可以指定一个推荐的选择（在Location头中），客户端可能会使用这个值重定向。
2. 301 - Moved Permanently
   
   请求的资源已经被永久的移动到一个新的URI上。客户端可以自动跳转到新的URI上。新的URI需要在响应消息的Location头中包含。
3. 302 - Found
   
   请求的资源临时的存在于另一个URI中。因为这个重定向还可能会改变，客户端需要继续使用旧的URI。临时的URI需要包含在响应消息的Location头中。
4. 303 - See Other
   
   请求的响应可以使用另一个URI中获得，并且必须使用GET方法获取另一个URI上的响应。该响应码主要用于将一个POST产生的输出重定向到一个新选择的资源上。新的URI需要在Location响应头中给出。
5. 304 - Not Modified
   
   如果客户端发送一个“Conditional GET”请求，并且该请求是被允许的，但是它所对应的文档没有改变，则服务器返回该响应。该响应不能包含消息体，但必须包含一些消息头：Date、ETag、Content-Location、Expires、Cache-Control、Vary。
6. 305 - Use Proxy
   
   请求的资源必须通过Proxy使用Location响应头中的URI访问。
   
7. 306 - Unused
   
   以前版本使用，现在已经不使用，但是响应码保留。
8. 307 - Temporary Redirect
   
   请求的资源临时的指向另一个URI，但是由于这个重定向可能会在将来被更改，因而客户端需要继续使用原来的URI。临时的URI在Location响应头中指定。

4xx: Client Error - The request contains bad syntax or connote be fulfilled

1. 400 - Bad Request
   
   语法错误，请求不能被服务器理解。
2. 401 - Unauthorized
   
   请求需要包含用于认证。响应必须包含WWW-Authenticate头，包含请求认证需要的信息。客户端可以使用包含Authorization头重新发送请求。
3. 402 - Payment Required
   
   为将来使用保留。
4. 403 - Forbidden
   
   服务器拒绝该请求。如果服务器希望让客户端知道拒绝的原因，可以将原因放在响应消息体重，如果服务器想暴露该原因，则可以返回404（Not Found）响应。
5. 404 - Not Found
   
   服务器没有发现任何匹配的请求URI。如果服务器知道某些资源已经永久的被移出，并且没有重定向地址，则需要返回410（Gone）响应。该响应也可以用于服务器不想暴露客户请求被拒绝的原因。
6. 405 - Method Not Allowed
   
   请求方法不被对请求的资源允许。在响应消息中必须包含Allow头，指定请求资源允许的请求方法。
7. 406 - Not Acceptable
   
   请求的资源产生的响应包含了不被Accept请求头指定的特性。
8. 407 - Proxy Authentication Required
   
   类似401（Unauthorized），表示客户端必须在Proxy中通过认证。Proxy必须返回Proxy-Authenticate头，包含请求认证需要的信息。
9. 408 - Request Time-out
   
   服务器已经准备好并在等待，但是客户端在指定的时间里没有发送请求。
10. 409 - Conflict
    
    因为和资源当前状态冲突而导致请求没有完成。该响应码只有在用户知道任何解决这个冲突，并且重新提交请求时产生。
11. 410 - Gone
    
    请求的资源已经不在服务器上，并且没有更进一步的重定向地址。
12. 411 - Length Required
    
    请求消息必须包含Content-Length消息头。
13. 412 - Precondition Failed
    
    服务器对一个或多个请求消息头的测试失败。
14. 413 - Request Entity Too Large
    
    请求消息太大。如果这个条件是临时的，则服务器需要包含Retry-After响应头，表示这个响应时临时的，并在指定的时间以后重试。
15. 414 - Request-URI Too Large
    
    请求的URI太长。
16. 415 - Unsupported Media Type
    
    请求消息格式不被支持。
17. 416 - Request range not satisfiable
    
    在请求包含Range头，不包含If-Range头，并且请求的资源不在Range指定的范围中。响应头中需要包含Content-Range表示指定资源当前的长度。
18. 417 - Expectation Failed
    
    Expect请求头指定的值不能匹配服务器的逻辑。

5xx: Server Error - The server failed to fulfill an apparently valid request

1. 500 - Internal Server Error
   
   服务器内部错误。
2. 501 - Not Implemented
   
   服务器没有实现当前请求。如没有实现对应的请求方法。
3. 502 - Bad Gateway
   
   代理或网关服务器从上游服务器中接收到一个不合法的响应。
4. 503 - Service Unavailable
   
   服务器因为临时负载过重或处于维护状态而不能处理请求。该响应暗示服务器当前的状态是临时的，如果服务器知道什么时候恢复可用状态，则可以包含Retry-After响应头，如果没有包含Retry-After头，则客户端可以把它视为500（Internal Server Error）来处理。
5. 504 - Gateway Time-out
   
   代理服务器或网关服务器在指定的时间内没有收到上游服务器的响应。
6. 505 - HTTP Version not supported
   
   服务器不支持或拒绝支持请求消息中指定的HTTP版本。