欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

Servlet3.1规范翻译——Request

程序员文章站 2022-04-12 19:13:53
...

 

Request

请求对象封装了客户端请求的所有信息。在HTTP协议中,这些信息是从客户端发送到服务器请求的HTTP头部和消息体。

 

3.1 HTTP协议参数

servlet的请参数以字符串的形式作为请求的一部分从客户端发送到servlet容器。当请求是一个HttpServletRequest对象,且符合第24页中参数可用时描述的条件时,容器从URI查询字符串和POST数据中填充参数。参数以一系列的名-对的形式保存。任何给定的参数的名称可存在多个参数值。ServletRequest接口的下列方法可访问这些参数:

■ getParameter

■ getParameterNames

■ getParameterValues

■ getParameterMap

getParameterValues方法返回一个String对象的数组,包含了与参数名称相关的所有参数值。getParameter方法的返回值必须是getParameterValues方法返回的String对象数组中的第一个值。getParameterMap方法返回请求参数的一个java.util.Map对象,其中以参数名称作为map键,参数值作为map值。

 

查询字符串和POST请求的数据被汇总到请求参数集合中。查询字符串数据在POST数据之前发送。例如,如果请求由查询字符串a =helloPOST数据a=goodbye&a=world组成,得到的参数集合顺序将是=(hello,goodbye,world)

这些API不会暴露GET请求(HTTP 1.1所定义的)的路径参数。他们必须从getRequestURI方法或getPathInfo方法返回的字符串值中解析。

 

3.1.1 当参数可用时

以下是在POST表单数据填充到参数集前必须满足的条件:

1。该请求是一个HTTPHTTPS请求。

2HTTP方法是POST

3。内容类型是application/x-www-form-urlencoded

4。该servlet已经对request对象的任意getParameter方法进行了初始调用。

 

如果不满足这些条件,而且参数集中不包括POST表单数据,那么servlet必须可以通过request对象的输入流得到POST数据。如果满足这些条件,那么从request对象的输入流中直接读取POST数据将不再有效。

 

3.2文件上传

当数据以multipart/form-data的格式发送时,servlet容器支持文件上传。

 

如果满足以下任何一个条件,servlet容器提供multipart/form-data格式数据的处理,。

 

■ servlet处理第8.1.5节,8-68页中定义的注解“@MultipartConfig”标注的请求。

为了servlet处理请求,部署描述符包含了一个multipart-config元素。

 

如何使requestmultipart/form-data类型的数据可用,取决于servlet容器是否提供multipart/form-data格式数据的处理:

 

如果servlet容器提供multipart/form-data格式数据的处理,可通过HttpServletRequest中的以下方法得到:

■ public Collection<Part> getParts()

■ public Part getPart(String name)

 

译者注:Part类代表从multipart/form-data格式的POST请求中接收到的一个部分或表单项。 每个part都可通过Part.getInputStream方法访问头部,相关的内容类型和内容。

 

对于表单数据的Content-Disposition,即使没有文件名,也可使用part的名称通过HttpServletRequestgetParametergetParameterValues​​方法得到part的字符串值。

 

如果servlet的容器不提供multi-part/form-data格式数据的处理,这些数据将可通过HttpServletReuqest.getInputStream得到。

 

3.3 属性

属性是与请求相关联的对象。属性可以由容器设置来表达信息,否则无法通过API表示,或者由servlet设置将信息传达给另一个servlet(通过RequestDispatcher)。属性通过ServletRequest接口中下面的方法来访问:

■ getAttribute

■ getAttributeNames

■ setAttribute

 

只有一个属性值可与一个属性名称相关联。以前缀java.javax.开头的属性名称是本规范的保留定义。同样地,以前缀sun.com.sun.开头的属性名是Sun Microsystems的保留定义。建议属性集中所有属性的命名与Java编程语言的规范1为包命名建议的反向域名约定一致。

 

3.4

servlet可以通过HttpServletRequest接口的下面方法访问HTTP请求的头部信息:

■ getHeader

■ getHeaders

■ getHeaderNames

 

getHeader方法返回给定头名称的头。多个头可以具有相同的名称,例如HTTP请求中的Cache-Control头。如果多个头的名称相同,getHeader方法返回请求中的第一个头。 getHeaders方法允许访问所有与特定头名称相关的头值,返回一个String对象的枚举。

 

头可包含由String形式的intDate数据。HttpServletRequest接口提供如下方便的方法访问这些类型的头数据:

■ getIntHeader

■ getDateHeader

 

如果getIntHeader方法不能转换为int的头值,则抛出NumberFormatException异常。如果getDateHeader方法不能把头转换成一个Date对象,则抛出IllegalArgumentException异常。

 

3.5 请求路径元素

引导servlet服务请求的请求路径由许多重要部分组成。以下元素从请求URI路径得到,并通过request对象公开:

 

■ Context Path:与ServletContext相关联的路径前缀是这个servlet的一部分。如果这个上下文是基于Web服务器的URL命名空间基础上的默认上下文,那么这个路径将是一个空字符串。否则,如果上下文不是基于服务器的命名空间,那么这个路径以/字符开始,但不以/字符结束。

 

■ Servlet Path:路径部分直接与激活请求的映射对应。这个路径以“/”字符开头,如果请求与“/ *”“”模式匹配,在这种情况下,它是一个空字符串。

 

■ PathInfo:请求路径的一部分,不属于Context PathServlet Path。如果没有额外的路径,它要么是null,要么是以'/'开头的字符串。

 

使用HttpServletRequest接口中的下面方法来访问这些信息:

■ getContextPath

■ getServletPath

■ getPathInfo

 

重要的是要注意,除了请求URI和路径部分的URL编码差异外,下面的等式永远为真:

requestURI = contextPath + servletPath + pathInfo

 

举几个例子来澄清上述各点,请考虑以下几点:

3-1 上下文设置的例子

Context Path

/catalog

Servlet Mapping

Pattern: /lawn/*

Servlet: LawnServlet

Servlet Mapping

Pattern: /garden/*

Servlet: GardenServlet

Servlet Mapping

Pattern: *.jsp

Servlet: JSPServlet

 

遵守下列行为:

3-2 遵守路径元素行为

请求路径

路径元素

/catalog/lawn/index.html

ContextPath: /catalog

ServletPath: /lawn

PathInfo: /index.html

/catalog/garden/implements/

ContextPath: /catalog

ServletPath: /garden

PathInfo: /implements/

/catalog/help/feedback.jsp

ContextPath: /catalog

ServletPath: /help/feedback.jsp

PathInfo: null

 

3.6 路径转换方法

API中有两个方便的方法,允许开发者获得与某个特定的路径等价的文件系统路径。这些方法是:

■ ServletContext.getRealPath

■ HttpServletRequest.getPathTranslated

 

getRealPath方法需要一个字符串参数,并返回一个字符串形式的路径,这个路径对应一个在本地文件系统上的文件。getPathTranslated方法推断出请求的pathInfo的实际路径(译者注:把URLservlet名称之后,查询字符串之前的路径信息转化成实际的路径)。

 

这些方法在servlet容器无法确定一个有效的文件路径 的情况下,如Web应用程序从归档中,在不能访问本地的远程文件系统上,或在一个数据库中执行时,这些方法必须返回nullJAR文件中META-INF/resources目录下的资源,只有当调用getRealPath()方法时才认为容器已经从包含它的JAR文件中解压,在这种情况下,必须返回解压缩后位置。

 

3.7 非阻塞IO

Web容器中的非阻塞请求处理有助于提高对改善Web容器可扩展性不断增加的需求,增加Web容器可同时处理请求的连接数量。servlet容器的非阻塞IO允许开发人员在数据可用时读取数据或在数据可写时写数据。

 

ReadListener为非阻塞IO提供了下面的回调方法:

■ ReadListener

■ onDataAvailable().当可从传入的请求流中读取数据时ReadListeneronDataAvailable方法被调用。容器将调用该方法。每一组可用数据该方法将被调用一次。

 

■ onAllDataRead().当读取完注册了此监听器的ServletRequest的所有数据时调用onAllDataRead方法。

 

■ onError(Throwable t). 处理请求时如果有任何错误或异常发生时调用onError方法。

 

除了上述ReadListener定义的方法外,下列方法已被添加到ServletInputStream类中:

■ ServletInputStream

■ boolean isFinished(). ServletReader/ServletInputStream相关的请求的所有数据已经读取完时isFinished方法返回true否则返回false

 

■ boolean isReady().如果可以无阻塞地读取数据isReady方法返回true。如果没有数据可以无阻塞地读取该方法返回false如果isReady方法返回false,不能够调用read方法。

 

■ void setReadListener(ReadListener listener). 设置上述定义的ReadListener,调用它以非阻塞的方式读取数据。一旦把监听器与给定的ServletInputStream关联起来,当数据可以读取,所有的数据都读取完或如果处理请求时发生错误,容器调用ReadListener的方法。注册一个ReadListener将启动非阻塞IO。在那时不能切换到传统的阻塞IO

 

3.8 Cookies

HttpServletRequest接口提供了​​getCookies方法来获得请求中的cookie的一个数组。这些cookie是从客户端发送到服务器端的客户端发出的每个请求上的数据。典型地,客户端发送回的作为cookie的一部分的唯一信息是cookie的名称和cookie值。当cookie发送到浏览器时可以设置其他cookie属性,诸如注释,这些信息不会返回到服务器。该规范还允许的cookiesHttpOnly cookieHttpOnly cookie暗示客户端它们不会暴露给客户端脚本代码(它没有被过滤掉,除非客户端知道如何查找此属性)。使用HttpOnly cookie有助于减少某些类型的跨站点脚本攻击。

 

3.9 SSL属性

如果请求已经通过一个安全协议发送过,如HTTPS,必须通过ServletRequest接口的isSecure方法公开该信息。Web容器必须公开下列属性给servlet程序员:

3-3 协议属性

属性

属性名称

Java类型

密码套件

javax.servlet.request.cipher_suite

String

算法的位大小

javax.servlet.request.key_size

Integer

SSL会话id

javax.servlet.request.ssl_session_id

String

 

如果有一个与请求相关的SSL证书,它必须由servlet容器以java.security.cert.X509Certificate类型的对象数组暴露给servlet程序员并可通过一个javax.servlet.request.X509Certificate类型的ServletRequest属性访问。

 

这个数组的顺序是按照信任的升序顺序。证书链中的第一个证书是由客户端设置的,第二个是用来验证第一个的,等等。

 

3.10 国际化

客户可以选择希望Web服务器用什么语言来响应。该信息可以和使用Accept-Language头与HTTP/1.1规范中描述的其他机制的客户端通信。ServletRequest接口提供下面的方法来确定发送者的首选语言环境:

■ getLocale

■ getLocales

 

getLocale方法将返回客户端要接受内容的首选语言环境。要了解更多关于Accept-Language头必须被解释为确定客户端首选语言的信息,请参阅RFC 2616HTTP/1.114.4节。

 

getLocales方法将返回一个Locale对象的枚举,从首选语言环境开始顺序递减,这些语言环境是可被客户接受的语言环境。

 

如果客户端没有指定首选语言环境,getLocale方法返回的语言环境必须是servlet容器默认的语言环境,而getLocales方法必须返回只包含一个默认语言环境的Local元素的枚举。

 

3.11 请求数据编码

目前,许多浏览器不随着Content-Type头一起发送字符编码限定符,而是根据读取HTTP请求确定字符编码​​。如果客户端请求没有指定请求默认的字符编码,容器用来创建请求读取器和解析POST数据的编码必须是“ISO-8859-1”。然而,为了向开发人员说明客户端没有指定请求默认的字符编码,在这种情况下,客户端发送字符编码失败,容器从getCharacterEncoding方法返回null

 

如果客户端没有设置字符编码,并使用不同的编码来编码请求数据,而不是使用上面描述的默认的字符编码,那么可能会发生破坏。为了弥补这种情况,ServletRequest接口添加了一个新的方法setCharacterEncoding(String enc)。开发人员可以通过调用此方法来覆盖由容器提供的字符编码​​。必须在解析任何post数据或从请求读取任何输入之前调用此方法。此方法一旦调用,将不会影响已经读取的数据的编码。

 

3.12 Request对象的生命周期

每个request对象只在servletservice方法的作用域内,或过滤器的doFilter方法​​的作用域内有效,除非该组件启用了异步处理并且调用了request对象的startAsync方法。在发生异步处理的情况下,request对象一直有效,直到调用AsyncContextcomplete方法。容器通常会重复利用request对象,以避免创建request对象的性能开销。开发人员必须注意的是,不建议在上述范围之外保持startAsync方法还没有被调用的请求对象的引用,因为这样可能产生不确定的结果。

 

 

PS:希望大家不吝指正翻译中的错误,希望有兴趣的iteye朋友加入进来一起翻译和学习

 

Servlet3.1JSR340)规范目前处于早期草案阶段,目标是在Java EE 7或更高平台。 Servlet3.0JSR 315)已经包含在Java EE 6平台。具体请参考本规范网站:http://jcp.org/en/jsr/detail?id=340