The request object encapsulates all request information from the client. In the HTTP protocol, all information sent from the client to the server is transmitted through the request header and request body of the request object.
SRV.4.1 HTTP parameters
Servlet Request Parameters are transmitted to the servlet container as strings as part of client requests. When the request information uses the HttpServletRequest object, if the required parameters are met, the container will send the URI query parameters and POST form data.
Parameters are stored as name-value pairs, and a parameter name can correspond to multiple parameter values. The following four methods of the ServletRequest interface are used to access these parameter information:
• GetParameter
• GetParameterNames
• GetParameterValues
• GetParameterMap
The getParameterValues method queries all the parameter values corresponding to a parameter name and returns the values in a String array. The getParameter method is similar to this method, except that getParameter only returns the first value of the String array queried by the getParameterValues method. The getParameterMap method returns all Request Parameters in Map mode. Of course, this Map uses the parameter name key and the parameter value as the corresponding value.
All request data obtained from the request body submitted by the query string and post are encapsulated in the request parameter set. The data priority of query strings is higher than that submitted by post. For example, the query parameter in the address bar of the client has a = hello, while the request body parameter submitted by post contains a = goodbye $ a = world, the final parameter results encapsulated by the server are sorted as a = (hello, goodbye, world ).
Path parameters that are part of a GET request are not processed and displayed by the current API specification. They must parse the String results returned by the getRequestURI or getPathInfo method.
SRV.4.1.1 parameter availability
The following four prerequisites must be met when the post method is used to submit request data:
1. HTTP or HTTPS requests.
2. the HTTP request method is POST.
3. The content type is application/x-www-form-urlencoded.
4. The servlet has initialized and called the getParameter method on the request object.
If the preceding conditions are not met, the form data submitted by post is not included in the parameter set, but the post data itself can still be accessed through the input stream of the request object. If the preceding conditions are met, the form data submitted by post cannot be directly accessed through the input stream of the request object.
SRV.4.2 attributes
Attributes is the associated object of the request. Attributes can be used by containers to identify information that cannot be expressed by Servlet APIs, or to communicate and exchange data between multiple servlets. Attributes can be accessed through the following methods of the ServletRequest interface:
• GetAttribute
• GetAttributeNames
• SetAttribute
A property name can only correspond to one property value. Attribute names starting with "java." and "javax." have been reserved for the Servlet specification itself. Similarly, "sun." and "com. sun" have been reserved for Sun systems. We recommend that you use inverted domain names or Java package naming rules to name all attributes. This ensures the uniqueness of the attribute names.
SRV.4.3 Headers
Servlet uses the following methods of the HttpServletRequest interface to access HTTP request header information:
• GetHeader
• GetHeaders
• GetHeaderNames
GetHeader returns the header information of the specified name. A header name can correspond to multiple header values, similar to a request. If there are multiple values, getHeader returns only the first request header, while getHeaders can return all header information (returned by String object enumeration ).
The header contains a string representation of the int and Date types. The following methods of HttpServletRequest can be used to access the corresponding request header data:
• GetIntHeader
• GetDateHeader
If the getIntHeader method cannot convert the header to the int type, NumberFormatException is thrown. Similarly, if the getDateHeader method cannot convert the Date type normally, IllegalArgumentExcetion will be thrown.
Elements related to the Request Path of SRV.4.4
The Request Path is composed of multiple important information segments. The following elements are obtained by the request URI and displayed by the request object:
1. Context Path: the Path prefix associated with ServletContext. If the application Context is the default Context of the Web service URL namespace, the Context Path is empty. Otherwise, it starts with the slash "/" and ends with other non-slash characters.
2. Servlet Path: This Path corresponds to the ing Path for request processing. It starts with the slash "/". If the request matches the "/*" rule, the Servlet Path will be a null string.
3. PathInfo: This part is neither part of the Context Path nor part of the Servlet Path. It is either null or a string with the slash "/" as the leading character.
The following three methods of the HttpServletRequest interface are used to access this information:
• GetContextPath
• GetServletPath
• GetPathInfo
Remember this: the following equation is always true unless the request URI and path are encoded differently:
RequesetURI = contextPath + servletPath + pathInfo.
To understand this, consider the following example:
Table 1: context setting example
Context Path |
/Catalog |
Servet Manpping |
Pattern:/lawn /* Servlet: LawnServlet |
Servlet Mapping |
Pattern:/garden /* Servlet: GardenServlet |
Servet Mapping |
Pattter: *. jsp Servlet: JSPServlet |
Table 2: path element Parsing
/Catalog/lawn/index.html |
ContextPath:/catalog ServletPath:/lawn PathInfo:/index.html |
/Catalog/garden/implements/ |
ContextPath:/catalog ServletPath:/garden PathInfo:/implements/ |
/Catalog/help/feedbak. jsp |
ContextPath:/catalog ServletPath:/help/feedback. jsp PathInfo: null |
SRV.4.5 path Conversion Method
The API provides two convenient methods for developers to obtain the real path of the file system corresponding to the Servlet:
• ServletContext. getRealPath
• HttpServletRequest. getPathTranslated
The getRealPath method receives a String parameter, and then returns the file path on the local file system corresponding to this parameter. The getPathTranslated method calculates the actual path corresponding to pathInfo in the request.
In some cases, the Servlet container cannot know the available File paths corresponding to these methods. For example, when a web application is executed from a compressed package, a remote file system that cannot be accessed locally, or a database, all of these methods return null.
SRV.4.6 Cookies
The HttpServletRequest interface provides the getCookies method to obtain the cookie array of the request object. These cookies are sent to the server every time the client sends a request. In typical cases, the only information in the cookies sent back to the client is the cookie name value pair. Other cookie attributes can also be set when returned to the browser, such as comments. Of course, this data is usually not available.
SRV.4.7 SSL attributes
If the sent request uses HTTPS and other security protocols, the request information must be safe when the isSecure method of the ServletRequest interface is called. Web containers must maintain the following attributes:
Table 3: protocol-related attributes
Attribute |
Attribute Name |
Java Type |
Cipher suite |
Javax. servlet. request. cipher_suite |
String |
Bit size of the algorithm |
Javax. servlet. request. key_size |
Integer |
If the request is associated with SSL authentication, the servlet container must be displayed to the developer with a java. security. cert. x509Certificate object array, and through the javax. servlet. request. the X509Certificate attribute can access these authorizations.
This array uses the credit cascading relationship as the sorting level. The first-level authentication of the credit chain is set by the client, and the next-level authentication is performed for the first-level authentication, and so on.
SRV.4.8 Internationalization
The client can specify the language in which the web service returns response information. The Language settings are specified by the client's Accept-Language request header. The following methods of the ServletRequest interface are used for localization settings required for response detection:
• GetLocale
• GetLocales
The getLocale method returns the locale that the client prefers to use. The getLocales method returns an enumerated object of Locale, listing the most desired and acceptable locale on the client according to the preference level.
If this is not specified by the client, the getLocale method must return the default locale of the servlet container, while the getLocales method must return the enumerated object containing the default locale.
SRV.4.9 request data encoding
Currently, many browsers do not specify the encoding format. The service program automatically determines the encoding method used to read the requested data. If the client does not specify the encoding format, the container must use the ISO-8859-1 encoding when reading the request header and parsing the POST data body. However, even if the servlet container uses the ISO-8859-1 by default, the getCharacterEncoding method must return null to explicitly inform developers that the client request does not specify the encoding format at this time.
If no character encoding is specified on the client and different encoding rules are used to parse the request data, garbled characters may occur. To solve this problem, the ServletRequest interface adds a new setCharacterEncoding (String enc) method. Developers can reset the container encoding mode. It should be emphasized that this method must be called before parsing or reading any request data and input stream, otherwise it will not take effect.
SRV.4.10 request object Lifecycle
Each request object is only available in the service method area of the current servlet, or in the doFilter Method Area of the filter. Generally, the container recycles request objects to avoid performance overhead when creating new request objects. Developers must avoid calling request objects out of the above scope; otherwise, unpredictable execution results may easily occur.
Document Information
- Translator: Uncle Zhang
- Http://www.cnblogs.com/flance/
- Copyright statement: Free Reprint-non commercial-Non derivative-keep the signature | Creative Commons BY-NC-ND 3.0