0 概述
spring-web的web模塊是更高一層的抽象，它封裝了快速開發spring-web需要的基礎組件。其結構如下：
1. 初始化Initializer部分
1.1 Servlet3.0 的ServletContainerInitializer用來支持基於代碼的servlet容器配置，它使用spring的WebApplicationInitializer SPI 來代替(或者混合使用)使用傳統的基於web.xml的方式。
1.2 SpringServletContainerInitializer在兼容servlt 3.0的容器啟動時，觸發onStartUp方法加載並初始化該類。容器啟動時假定spring web模塊的jar已經存放在classpath中。加載時使用ServiceLoader的loader方法來查找spring-web模塊下的META-INF/services/javax.servlet.servletContainerInitializer服務提供者配置文件。
1.3 HttpRequestHandler接口約等於HttpServlet，所有的方法集中於handleRequest方法。其實現類如下：
2. 接受請求的accept部分
還記得我們的http請求報文嗎？
GET /tutorials/other/top-20-mysql-best-practices/ HTTP/1.1 (Request line)
Host: net.tutsplus.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120
Pragma: no-cache
Cache-Control: no-cache
先了解一下rfc-2616是如何定義的？
The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.
Accept = "Accept" ":"
#( media-range [ accept-params ] )
media-range = ( "*/*"
| ( type "/" "*" )
| ( type "/" subtype )
) *( ";" parameter )
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes of that type. The media-range MAY include media type parameters that are applicable to that range.
Each media-range MAY be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (section 3.9). The default value is q=1.
Note: Use of the "q" parameter name to separate media type
parameters from Accept extension parameters is due to historical
practice. Although this prevents any media type parameter named
"q" from being used with a media range, such an event is believed
to be unlikely given the lack of any "q" parameters in the IANA
media type registry and the rare usage of any media type
parameters in Accept. Future media types are discouraged from
registering any parameter named "q".
The example
Accept: audio/*; q=0.2, audio/basic
SHOULD be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in quality."
If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response.
A more elaborate example is
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then send the text/x-dvi entity, and if that does not exist, send the text/plain entity."
Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence. For example,
Accept: text/*, text/html, text/html;level=1, */*
have the following precedence:
1) text/html;level=1
2) text/html
3) text/*
4) */*
The media type quality factor associated with a given type is determined by finding the media range with the highest precedence which matches that type. For example,
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, */*;q=0.5
would cause the following values to be associated:
text/html;level=1 = 1
text/html = 0.7
text/plain = 0.3
image/jpeg = 0.5
text/html;level=2 = 0.4
text/html;level=3 = 0.7
Note: A user agent might be provided with a default set of quality
values for certain media ranges. However, unless the user agent is
a closed system which cannot interact with other rendering agents,
this default set ought to be configurable by the user.
我們再看accept部分的整體結構：
是不是有點恍然大悟或者有點小明白了？不錯，accept部分就是負責協商http內容的MIME TYPE是否滿足要求的。
3. 數據綁定bing部分
在這里，綁定的意思是將不同類型的http請求上的數據設置到特定的對象object上如javabean等，支持multipart的綁定。其結構如下：
綁定支持兩種方式：編程式和注解式。
其中，注解的實現由HandlerMethodInvoker觸發HandlerMethodResolver來完成。
4.web客戶端client部分
5. 上下文context部分
包含一系列web應用的applicationContext接口和用來啟動根web applicationContext的contextLoaderListener。
各種applicationContext層次結構如下圖：（圖片來源網絡，具體鏈接已經找不到了，請原諒）
spring-context相關內容請參照這方面的源碼解析，在這里就不一一贅述了。
6. 過濾器filter
spring也對filter進行一定程度的封裝和實現，其結構如下：
7. jsf部分
支持將jsf的web層和spring的service集成在一起，並支持jsf的el解析，spring的service層駐留在spring的根webapplicationContext中。
8. method部分
提供給spring mvc使用的方法處理類。
9. multipart部分
一個multipart的解決文件上傳的方案框架，MultipartResolver繼承實現了 Apache Commons FileUpload.
10. util部分
提供了公共的工具類。
小結
spring-web的web模塊是spring框架處理web請求的基礎，spring-web的http模塊(http://www.cnblogs.com/davidwang456/p/4421495.html)封裝http協議中client端/server端的request請求和response響應及格式的轉換，如json，rss，xml等；spring-web的remoting模塊包括jaxws、caucho、httpinvoker等遠程調用；spring-web的web模塊則在上述模塊的基礎上對web應用進行了進一步的封裝，提供了快速開發web的能力。
注意：上述內容為本人在閱讀源碼時的體會和見解，不一定正確，請引用時謹慎，如發現有錯誤的地方，希望能給我反饋，我會盡快修改。