上善若水
In general the OO style is to use a lot of little objects with a lot of little methods that give us a lot of plug points for overriding and variation. To do is to be -Nietzsche, To bei is to do -Kant, Do be do be do -Sinatra
posts - 146,comments - 147,trackbacks - 0

概述

Servlet是Server Applet的缩写,即在服务器端运行的小程序,而Servlet框架则是对HTTP服务器(Servlet Container)和用户小程序中间层的标准化和抽象。这一层抽象隔离了HTTP服务器的实现细节,而Servlet规范定义了各个类的行为,从而保证了这些“服务器端运行的小程序”对服务器实现的无关性(即提升了其可移植性)。
在Servlet规范有以下几个核心类(接口):
ServletContext:定义了一些可以和Servlet Container交互的方法。
Registration:实现Filter和Servlet的动态注册。
ServletRequest(HttpServletRequest):对HTTP请求消息的封装。
ServletResponse(HttpServletResponse):对HTTP响应消息的封装。
RequestDispatcher:将当前请求分发给另一个URL,甚至ServletContext以实现进一步的处理。
Servlet(HttpServlet):所有“服务器小程序”要实现了接口,这些“服务器小程序”重写doGet、doPost、doPut、doHead、doDelete、doOption、doTrace等方法(HttpServlet)以实现响应请求的相关逻辑。
Filter(FilterChain):在进入Servlet前以及出Servlet以后添加一些用户自定义的逻辑,以实现一些横切面相关的功能,如用户验证、日志打印等功能。
AsyncContext:实现异步请求处理。

ServletRequest

ServletRequest是对Servlet请求消息的封装,其子接口HttpServletRequest则是对HTTP请求消息的封装,在Servlet框架中默认实现了ServletRequestWrapper和HttpServletRequestWrapper以便利用户对请求的Wrap。

在Jetty中,使用Request类实现HttpServletRequest接口,Request包含了HttpConnection引用,因为HttpConnection包含了HttpParser解析HTTP请求后的所有信息,如请求行、请求头以及请求内容。其中ServletRequest接口定义与实现如下:
public interface ServletRequest {
    // Request级别的Attribute操作,它属于Request的私有数据,因而Request使用Attributes私有字段实现。然而Jetty添加了一些自定义的Attribute:
    // 在getAttribute时,org.eclipse.jetty.io.EndPoint.maxIdleTime用于获取EndPoint中MaxIdleTime属性,org.eclipse.jetty.continuation用于获取Continuation实例(如果该属性没被占用)
    // 在setAttribute时,org.eclipse.jetty.server.Request.queryEncoding属性同时用于设置Request的QueryEncoding属性;
    // org.eclipse.jetty.server.sendContent同时用于直接向客户端发送Object指定的相应内容,该值必须是HttpContent、Resource、Buffer、InputStream类型;
    // org.eclipse.jetty.server.ResponseBuffer同时用于设置对客户端相应的ByteBuffer数据;org.eclipse.jetty.io.EndPoint.maxIdleTime同时用于设置EndPoint中的MaxIdleTime属性。
    // 如果注册了ServletRequestAttributeListener,则相应的attributeAdded、attributeReplaced、attributeRemoved方法会被调用。
    public Object getAttribute(String name);
    public Enumeration<String> getAttributeNames();
    public void setAttribute(String name, Object o);
    public void removeAttribute(String name);

    // CharacterEncoding属性,用于指定读取请求内容时使用的编码方式,如果设置的编码方式不支持,抛出UnsupportedEncodingException。CharacterEncoding的设置必须在读取Parameter或getReader方法的调用之前,不然该方法不会有效果。该属性默认为null,此时Jetty默认使用UTF-8编码Parameter,使用ISO-8859-1编码方式创建Reader实例。
    public String getCharacterEncoding();
    public void setCharacterEncoding(String env) throws UnsupportedEncodingException;

    // 请求内容的长度,以字节为单位,-1表示长度未知。该值从HttpConnection的RequestFields字段中获取,该字段在HttpParser解析HTTP请求消息时填充。
    public int getContentLength();
    
    // 返回请求内容的MIME type,即在请求头中设置的ContentType头,该值同样从HttpConnection的RequestFields字段中获取,该字段在HttpParser解析HTTP请求消息时填充。
    public String getContentType();
    
    // 使用ServletInputStream包装请求内容的读取,该方法和getReader方法,只能使用一种方式来读取请求内容,否则抛出IllegalStateException。
    // ServletInputStream继承自InputStream,它只是实现了一个readLine函数。在该方法实现中返回HttpConnection的getInputStream,在该方法返回前,如果当前请求有Expect: 100-continue头,则先向客户端发送100 Continue相应,然后返回HttpInput实例,它继承自ServletInputStream,从HttpParser中读取数据。

    public ServletInputStream getInputStream() throws IOException; 
     
    // 请求参数相关的操作,请求参数可以在URL使用?paramName=paramValue&...的方式指定,也可是使用POST/PUT方法在请求消息体中指定(ContentType: application/x-www-form-urlencoded),或同时存在。URL的parameter信息读取使用queryEncoding字段指定的编码方式(默认编码为UTF-8),请求消息体中信息读取使用characterEncoding字段指定的编码方式(默认编码为ISO-8859-1)。在读取请求消息体中的parameter数据时,可以使用ContextHandler中的MaxFormContentSize属性或Server中的org.eclipse.jetty.server.Request.maxFormContentSize的Attribute配置最大支持的parameter数据大小,如果ContentLength超过该值,则抛出IllegalStateException。
    // 相同的paramName可以多次出现,因而一个paramName可能对应多个值,此时使用getParameterValues()方法获取所有的值。
    // 如果使用POST指定请求参数,使用getInputStream或getReader读取数据会对parameter的读取有影响。

    public String getParameter(String name);
    public Enumeration<String> getParameterNames();
    public String[] getParameterValues(String name);
    public Map<String, String[]> getParameterMap();
    
    // 返回当前请求使用的协议以及其版本号,如HTTP/1.1,对HTTP请求,它在解析请求行时设置。
    public String getProtocol();
    
    // 返回请求的Schema,默认为http,在SSL相关的Connector的customize方法中会被设置为https。
    public String getScheme();
    
    // 返回当前请求发送的服务器名称,如果请求URI中包含Host Name信息,则ServerName使用该信息;否则使用Host头(值为host:port)中的Server Name信息;
    // 如果不存在Host头,尝试使用EndPont中的LocalHost(LocalAddr,如果_dns值设置为false,即Connector的ResolveNames属性为false,其默认值为false);
    // 否则使用当前Server的LocalHost的Address:InetAddress.getLocalHost().getHostAddress();
    // 对代理服务器,如果Jetty在Connector中开启了forwarded检查,如果Connector中设置了_hostHeader值,则使用强制设置Host头为该值,清除已有的ServerName和Port,并重新计算;
    // 否则如果存在X-Forwarded-Host头,强制设置Host头为该头值的最左边的值,即第一个代理服务器的主机名,清除已有的ServerName和Port,并重新计算;
    // 如果存在X-Forwarded-Server头,则强制设置Request的ServerName值为该头值的最左边的值,即第一个代理服务器的主机名。
    // 如果存在X-Forwarded-For头,则更新Request的RemoteAddr和RemoteHost值,即最原始客户端的地址和主机名。
    // 如果存在X-Forwarded-Proto头,则更新Request的Schema为该头值的最左边的值。(这是原始请求的Schema还是神马呢?)
    // 具体参考:
http://benni82.iteye.com/blog/849139
    public String getServerName();

    // ServerPort有一下查找路径:请求URI中的Port;Host头中值的Port;EndPoint的LocalPort;如果都没有找到,则对HTTPS默认值为443,对HTTP默认值为80
    public int getServerPort();
    
    // 将ServletInputStream包裹成BufferedReader类型,使用CharacterEncoding编码方式,如果没有设置该编码,默认使用ISO-8559-1,因而CharacterEncoding的设置必须在该方法调用之前。
    public BufferedReader getReader() throws IOException;
    
    // 返回客户端的IP地址,如果开启了forwarded检查,则该值会被更新为原始的客户端请求IP,即使该请求穿越了好几个代理服务器。
    public String getRemoteAddr();

    // 如果Connector设置了ResolveNames属性为true,即Request中_dns字段为true,则返回客户端主机名,否则返回客户端主机IP;如果开启了forwarded检查,则该值被更新为最原始的客户端的主机名或IP,即使该请求穿越了好几个代理服务器。
    public String getRemoteHost();

    // 返回Accept-Language请求头中的指定的Locale值,支持多个值,以",", " ", "\t"等字符分隔,每个值都可以是如下格式:language-<country>;q<value>或language-<country>; q=<value>的格式,在选择一个Locale时使用qValue最大的那个。如果没有设置,默认使用当前服务器的Locale值。
    public Locale getLocale();

    // 返回Accept-Language头中指定的所有Locale枚举值,以qValue的值降序排列,如果没有指定该头,使用服务器默认的Locale值。
    public Enumeration<Locale> getLocales();

    // 检查当前请求是否在安全传输通道,如https。
    public boolean isSecure();
    
    // 返回一个RequestDispatcher,内部使用ServletContext获取RequestDispatcher实例,根据传入的path计算uriInContext值:如果它以"/"开头,uriInContext的值即为该值,
    // 如果它不以"/"开头,即表示它是相对与当前请求的path,则uriInContext的值为相对于当前Request URI,如pathInfo为/foo/goo,path为poo,则uriInContext为:<servletPath>/foo/poo
   public RequestDispatcher getRequestDispatcher(String path);
    
    // 返回客户端的端口,调用EndPoint的getRemotePort方法。
    public int getRemotePort();

    // 返回当前服务器的主机名,如果Connector的ResolveNames为true,否则为当前服务器的IP地址。
    public String getLocalName();

    // 返回当前服务器的IP地址,调用EndPoint的getLocalAddr方法。
    public String getLocalAddr();

    // 返回当前服务器的端口号,即当前连接使用的端口号,不是服务器本身监听的端口号。
    public int getLocalPort();

    // 返回当前Request正在执行所在ServletContext。
    public ServletContext getServletContext();

    // 启动当前请求的异步模式,该方法调用后,即可以推出当前请求的处理方法,在退出之前需要将返回的AsyncContext放到一个等待Queue或类似的数据结构中,从而在之后的处理中还能得到这个
    // AsyncContext实例进一步处理这个Request,AsyncContext包含了对当前Request和Response实例的引用,一般唤起这个异步的请求,使用AsyncContext的dispatch方法,
    // 从而保证在下一次的处理过程中依然存在Filter链通道。这个方法和带ServletRequest、ServletResponse参数的方法区别在于:
    // 如果Servlet A对应为/url/A,在Servlet A中调用request.getRequestDispatcher("/url/B"),此时在Servlet B中,如果调用request.startAsync().dispatch(),此时会dispatch到/url/A,
    // 但是如果在Servlet B中调用request.startAsync(request, response).dispatch(),此时会dispatch到/url/B中。
    // 另外该方法会在调用之前注册的AsyncListener的onStartAsync()方法之后,清除这些已注册的AsyncListener。在onStartAsync方法中可以将自己重新注册到AsyncContext中,只是这个设计好奇怪。。。

    public AsyncContext startAsync() throws IllegalStateException;
    public AsyncContext startAsync(ServletRequest servletRequest, ServletResponse servletResponse)
            throws IllegalStateException;

    // 查看是否当前request异步模式已经启动,即已经调用startAsync方法,但是还没有调用AsyncContext中的dispatch或onComplete方法。
    public boolean isAsyncStarted();

    // 查看当前Request是否支持异步模式,默认为true,如果Filter或Servlet不支持异步模式,这在调用对应的doFilter、service之前会把该值设置为false。
    public boolean isAsyncSupported();

    // 获取最近一次调用startAsync方法时创建的AsyncContext实例,如果当前request没有异步模式还没有启动,则抛出IllegalStateException。
    public AsyncContext getAsyncContext();

    // 获取当前请求的Dispatcher类型。Dispatcher Type是Container用于选区对应的Filter链。请求最初为Dispatcher.REQUEST;如果调用RequestDispatcher.forward()方法,
    // 则变为DispatcherType.FORWARD;如果调用RequestDispatcher.include()方法,则变为DispatcherType.INCLUDE;如果调用AsyncContext.dispatch()方法,则变为
    // DispatcherType.ASYNC;最后如果请求被dispatch到error page中,则为DispatcherType.ERROR。
    // DispatcherType在HttpConnection中的handleRequest方法中,在调用server.handle()/server.handleAsync()方法之前,设置为REQUEST、ASYNC,根据当前Request的AsyncContext是否处于初始化状态,如果是,则为REQUEST,否则为ASYNC状态,其他值则在Dispatcher中forward或include方法中设置。
    public DispatcherType getDispatcherType();
}
HttpServletRequest接口定义如下:
public interface HttpServletRequest extends ServletRequest {
    // Servlet的四种验证方式(他们在web.xml文件中的long-config/auth-method中定义):
    // BASIC使用Authentication头传输认证信息,该信息以Base64的编码方式编码,当需要用户验证时会弹出登陆窗口。
    // FORM使用表单的方式认证,用户名和密码在j_username和j_password字段中,登陆URL为/j_security_check,第一次使用表单方式明文传输,之后将认证信息存放在Session中,在Session实效之前可以不用在手动登陆。
    // DIGEST也时使用Authentication头传输认证信息,但是它使用加密算法将密码加密。
    // CLIENT_CERT则使用客户端证书的方式传输认证信息。
    // 更详细的内容参考:
http://docs.oracle.com/cd/E19798-01/821-1841/bncas/index.html 
    public static final String BASIC_AUTH = "BASIC";
    public static final String FORM_AUTH = "FORM";
    public static final String CLIENT_CERT_AUTH = "CLIENT_CERT";
    public static final String DIGEST_AUTH = "DIGEST";

    // 返回当前请求的认证方法,可以是BASIC、FORM、CLIENT_CERT、DIGEST。如果没有定义对应Servlet的认证配置,则返回null。在Jetty实现中,在ServletHandler根据配置信息以及认证的结果设置请求的Authentication实例,如果Authentication实例是Authentication.Deffered实例,则先验证,并设置验证后的Authentication实例,如果Authentication实例是Authentication.User实例,则设置返回其AuthMethod属性,否则返回null。
    public String getAuthType();

    // 返回当前请求包含的Cookie数组,从请求的Cookie头中获取,如果没有Cookie信息,则返回null。在Jetty实现中,使用CookieCutter类解析Cookie头。
    // Cookie值的格式为:<name>=value; [$path=..; $domain=...; $port=...; $version=..]; <name>=<value>.....
    // 在Servlet中,Cookie类包含comment(描述信息)、domain(cookie只是对指定的domain域可见,默认情况下cookie只会传输给设置这个cookie的server)、maxAge(cookie的最长可存活秒数,负数表示永远不会失效,0表示cookie会被删除)、path(指定那个path下的请求这个cookie才会被发送,包括它的子目录)、secure(这个cookie是否只在https请求中发送)、version(0表示netscape最初定义的cookie标准,1表示兼容RFC 2109,一般都是0以保持最大兼容性)、isHttpOnly(HttpOnly标识的cookie一般不应该暴露给客户端的脚本,以部分解决跨站点脚本攻击问题)字段。对浏览器,一般他们应该能为每个Web Server存储至少20个cookie,总共至少能处理300个cookie,以及至少4k大小。

    public Cookie[] getCookies();
    
    // 解析指定请求头的Date值,并转换成long值,如If-Modified-Since头。Jetty支持的Date格式有:EEE, dd MMM yyyy HH:mm:ss zzz; EEE, dd-MMM-yy HH:mm:ss等。
    public long getDateHeader(String name);

    // 返回指定的请求头的值,没有该头,返回null,如果有多个相同名字的头,则返回第一个该头的值。name是大小写无关。
    public String getHeader(String name); 

    // 返回指定请求头的所有值
    public Enumeration<String> getHeaders(String name); 
    
    // 返回请求头的所有名称,有些Container会禁用该方法,此时返回null。
    public Enumeration<String> getHeaderNames();

    // 返回指定请求头的int值。
    public int getIntHeader(String name);

    // 返回请求方法,如GET、POST、PUT等。该值在解析请求行结束后设置。
    public String getMethod();

    // 设置请求的额外path信息,该值在不同的地方会被设置为不同的值,如果请求的URI为: http://host:80/context/servlet/path/info如在HttpConnection中,其值为/context/servlet/path/info
    // 在ContextHandler的doScope中,其值被设置为/servlet/path/info;在ServletHandler的doScope方法中,其值被设置为/path/info,并设置ServletPath为/servlet。
    // 这里基于的假设为contextPath为/context,servletPath为/servlet,即在web.xml配置中Servlet相关的url-pattern为/servlet/*。
    // 如果没有/path/info后缀,则PathInfo为null,如果Servlet的path-pattern设置为/*,则ServletPath为"",对url-pattern为*.do类似的配置,pathInfo永远为null,servletPath则为/path/info.do的值;有些时候ServletPath的值也可能是Servlet Name的值。
   public String getPathInfo();
   public String getServletPath();

    // 返回pathInfo对应的在ServletContext下的真是Server路径,如果pathInfo为null,则返回null。
    public String getPathTranslated();

    // 返回当前请求所属的ContextPath。它在ContextHandler的doScope方法中或Dispatcher的forward方法中设置。
    public String getContextPath();
    
    // 返回当前请求的query字符串,如果设置了queryEncoding,使用该编码方式编码。
    public String getQueryString();

    // 返回请求的登陆用户,如果用户没有认证,则返回null。该信息从设置的Authentication实例中获取,如果其实例为Authentication.Defered,则需要先验证,然后返回获取UserIdentity,并从中获取Principal,而从Principal中可以获取用户名。
    public String getRemoteUser();

    // 验证当前请求的User是否在传入的Role中,即使用设置的Authentication实例验证,当前登陆的User所在的Roles中是否存在传入的RoleName。其中UserIdentity.Scope实例用于查找RoleName对应在Container使用的RoleName,如果没有这个映射则使用传入的RoleName本身,这个scope在ServletHandler的doScope方法中设置。这个映射在web.xml中的security-rol-ref(role-name->role-link)中设置。
    public boolean isUserInRole(String role);

    // 返回当前登陆User的Principal实例,从设置的Authentication实例中获取,或者为null。
    public java.security.Principal getUserPrincipal();

    // 返回客户端指定的Session ID,它可以和Server的当前Session ID不同。客户端可以使用两种方式设置该值:Cookie和URL。默认先从Cookie中找,找不到再从URL中找。
    // 对Cookie方式,在web.xml的cookie-config/name中配置Session的Cookie Name(默认值为JSSESSIONID),找到该Cookie Name对应的Cookie值作为Requested Session ID
    // 对URL方式,在;<sessionIdPathParamName>=....[;#?/]之间的值作为Requested Session ID的值。其中sessionIdPathParamName可以通过web.xml的context-param,使用org.eclipse.jetty.servlet.SessionIdPathParameterName属性值配置,默认为jsessionid。

    public String getRequestedSessionId();
    public boolean isRequestedSessionIdFromCookie();
    public boolean isRequestedSessionIdFromURL();

    // 检查当前Requested Session Id是否valid,在Jetty中valid是指RequstedSessionId存在,并且和当前请求的Server Session的ClusterId相同,即他们的SessionId相同。
    public boolean isRequestedSessionIdValid();    
    
    // 返回/contextPath/servletPath/pathInfo的值。对forward后请求,该值为forward后的URI。
    public String getRequestURI();
    
    // 返回getSchema()://getServerName():getPort()/getRequestURI(),对forward后请求,该值为forward后的URL。
    public StringBuffer getRequestURL();

    // 返回和当前请求相关联的HttpSession,如果没有关联的HttpSession,且create为true,则创建新的HttpSession实例。没有参数即create为true。
    public HttpSession getSession(boolean create);
    public HttpSession getSession();

    //使用Container定义的认证机制验证请求用户的合法性。在Jetty实现中,只是对Authentication.Deferred的Authentication类型进行验证,否则返回401 Unauthorized错误相应,并返回false。
    public boolean authenticate(HttpServletResponse response)  throws IOException,ServletException;

    // 提供用户名和密码并交由Container对其进行认证。在Jetty实现中,只对Authentication.Deferred类型提供用户名和密码认证,否则抛出ServletException。
    public void login(String username, String password)  throws ServletException;
    
    // 注销当前用户,并清理_authentication字段。
    public void logout() throws ServletException;

    // 对multipart/form-data请求类型,表示请求内容由多个部分组成,此时使用RFC1867来解析该内容到多个Part中。在Servlet中一个Part有自己的请求头和请求消息提,包含ContentType、Name、Headers、Size(已写入的大小)、InputStream等信息,它还提供了一个方法将请求内容写入指定的文件中,以及删除该内部文件。并提供MultipartConfigElement类来做相关的配置,如写文件时的位置Location;最大可上传的文件大小MaxFileSize;最大可包含的所有Part的请求大小MaxRequestSize;如果写入的数据超过配置的大小,则开始将数据写入文件中MaxFileSizeThreshold。该配置信息可以使用org.eclipse.multipartConfig属性设置,而Location信息可以使用javax.servlet.context.tempdir属性在ServletContext中设置,或这使用java.io.tmpdir中指定的值。在Jetty中使用MultiPartInputStream来表达并解析请求内容到多个Part(MultiPart)中。具体格式可以参考:http://blog.zhaojie.me/2011/03/html-form-file-uploading-programming.html
    public Collection<Part> getParts() throws IOException, ServletException;
    public Part getPart(String name) throws IOException, ServletException;
}
除了以上实现,Request还包含了一些额外的字段,如_timestamp在请求开始时设置,即解析请求头完成时;_dispatchTime在RequestLogHandler的handle方法,当Request是非Initial的状态下设置,即当前Request已经为Dispatched的状态;_handled表示该请求是否已经处理完成;

ServletResponse

ServletResponse是对Servlet响应消息的封装,其子接口HttpServletResponse则是对HTTP响应消息的封装,

ServletResponse接口定义如下:
public interface ServletResponse {
    // 设置与返回消息体中的字符编码方式。如果没有设置,默认使用ISO-8559-1。其中setContentType和setLocale会隐式的设置该值,但是显示的设置会覆盖之前隐式的设置,而该值的设置也会影响ContentType的值。该值的设置必须在调用getWriter()方法之前,否则不会起作用。在set方法中,如果传入的charset为null,则清楚原来设置的值,并将原来的_mimeType值设置为Content-Type头;否则,更新characterEncoding的值,并更新contentType的属性以及Content-Type头(更新contentType中"charset="之后部分的值,或使用"mimeType; charset=<characterType>")。
    public void setCharacterEncoding(String charset);
    public String getCharacterEncoding();

    // 设置响应消息的Content-Type头以及contentType字段的值,它会同时影响mimeType字段以及characterEncoding字段。如果type为null,则清除contentType、mimeType的值,移除Content-Type响应头,并且如果locale也为null,同时清除characterType值;否则,设置mimeType为";"之前的值,而characterEncoding的值为"charset="之后的值,如果没有"charset="之后的值,则是使用"charset=<characterType>"值拼接以设置Content-Type响应头。
    public void setContentType(String type);
    public String getContentType();
    
    // 设置Locale的值,同时设置响应的Content-Language头。同时该set也会影响characterEncoding、mimeType和Content-Type响应头。其中characterEncoding从ContextHandler中的Locale到charset的映射中获取,即web.xml中的locale-encoding-mapping-list中定义,而对Content-Type的值只影响"charset="之后的值。
    public void setLocale(Locale loc);
    public Locale getLocale();

    // 设置contentLength字段以及Content-Length响应消息头。如果当前写入的数据已经大于或等于设置的值,则该方法还会关闭当前的ServletOutputStream或Writer。
    public void setContentLength(int len);  

    // 返回向客户端写数据的ServletOutputStream或PrintWriter。它们只能使用其中一个方法。在Jetty中使用HttpOutput内部封装HttpGenerator实例用于向Socket中写数据。
    public ServletOutputStream getOutputStream() throws IOException;
    public PrintWriter getWriter() throws IOException;    
    
    // 响应消息处理相关的Buffer操作,在Jetty中即为HttpGenerator中响应消息体的Buffer大小与刷新操作。设置BufferSize必须在写响应消息体之前。另外reset只是清除消息体的缓存,并不会清除响应状态码、响应头等信息,如果该方法调用时消息已经被commit,则抛出IllegalStateException。
    public void setBufferSize(int size);
    public int getBufferSize();
    public void flushBuffer() throws IOException;
    public void resetBuffer();
    
   // 是否响应消息已经commit,即响应消息状态行和消息头已经发送给客户端。
    public boolean isCommitted();

    // 清除所有的响应消息状态,所有已经设置的响应头(但是不包括Connection头),如果响应已经commit,则抛出IllegalStateException。
    public void reset();
}
HttpServletResponse接口定义如下,它添加了一些Cookie、Header相关的操作:
public interface HttpServletResponse extends ServletResponse {
    // 向响应消息中添加一个Cookie实例。即添加"Set-Cookie"头。
    public void addCookie(Cookie cookie);

    // 消息头操作:增删改查。一个相同名字的头可能会有多个条纪录,因而可以对应多个值。在Jetty实现中代理给HttpConnection中的responseFields字段。其中Date头的格式为:EEE, dd MMM yyyy HH:mm:ss 'GMT',对于String为值的设置来说,处于INCLUDE Dispatch状态下,只能设置org.eclipse.jetty.server.include.<HeaderName>的头。
    public boolean containsHeader(String name);
    public void setDateHeader(String name, long date);
    public void addDateHeader(String name, long date);
    public void setHeader(String name, String value);
    public void addHeader(String name, String value);
    public void setIntHeader(String name, int value);
    public void addIntHeader(String name, int value);
    public String getHeader(String name); 
    public Collection<String> getHeaders(String name); 
    public Collection<String> getHeaderNames();

    // 编码传入的url,决定并添加是否需要在URL中加入Session ID信息以作为Session追踪。处于健壮性的考虑,所有Servlet产生的URL必须使用改方法编码,不然对不支持Cookie的浏览器将会失去Session信息。在实现中,如果Request使用Cookie作为Session追踪,则去除url中的sessionId信息;否则如果session存在并可用,则向url中添加session追踪信息,在"#"或"?"之前。
    public String encodeURL(String url);

    // 编码传入的url,用于sendRedirect方法中。在Jetty中改方法直接调用encodeURL()方法。
    public String encodeRedirectURL(String url);

    // 向客户端发送响应状态码和原因(如果有的话)。服务器会保留已经设置的cookie,但是会在必要情况下修改响应头。如果在web.xml中定义了响应的状态码到error page的映射,则该响应会被转发到那个错误页面中。在Jetty实现中,它清除Buffer信息,characterEncoding值,Expires、Last-Modified、Cache-Control、Content-Type、Content-Length头,设置响应状态和消息,对非204(No Content)、304(Not Modified)、206(Partial Content)、200(OK)的状态码(即允许有消息体),首先查找有没有注册的ErrorHandler ,如果有,向Request的属性中设置javax.servlet.error.status_code, javax.servlet.error.message, javax.servlet.error.request_uri, javax.servlet.error.servlet_name为相应的值(RequestDispatcher中定义的属性key),并调用ErrorHandler的handle方法;否则设置Cache-Control头为must-revalidate,no-cache,no-store,设置Content-Type头为text/html;charset=ISO-8859-1,并返回一个简单的错误页面包含状态码和消息原因。最后调用HttpConnection的completeResponse()方法以完成响应。
    public void sendError(int sc, String msg) throws IOException;
    public void sendError(int sc) throws IOException;

    // 发送客户端一个重定向的消息和URL,即设者响应状态码为302 Moved Temporary,在Location中包含要重定向目的地的URL,此时客户端会使用新的URL重新发送请求。如果location以"/"开头,表示它是绝对地址,否则为相应请求的相对地址,即最终解析成Request.getRequestURI()/location,location可以包含query信息。最后调用HttpConnection的completeResponse()方法以完成当前响应。
    public void sendRedirect(String location) throws IOException;
    
    // 设置响应状态码和状态描述信息。
    public void setStatus(int sc);
    public void setStatus(int sc, String sm);
    public int getStatus();
}
posted on 2014-05-16 01:29 DLevin 阅读(5945) 评论(2)  编辑  收藏 所属分类: Jetty

FeedBack:
# re: 深入Jetty源码之Servlet框架及实现(ServletRequest、ServletResponse)
2014-05-17 15:07 | 问问
拉了  回复  更多评论
  
# re: 深入Jetty源码之Servlet框架及实现(ServletRequest、ServletResponse)
2014-05-17 15:08 | 问问
发  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航: