Transcription
Java Servlet SpecificationVersion 3.1Shing Wai ChanRajiv MordaniApril 2013LANIFOracle Corporationwww.oracle.comSubmit comments about this document to: users@servlet-spec.java.net
ORACLE IS WILLING TO LICENSE THIS SPECIFICATION TO YOU ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OFTHE TERMS CONTAINED IN THIS AGREEMENT. PLEASE READ THE TERMS AND CONDITIONS OF THIS AGREEMENTCAREFULLY. BY DOWNLOADING THIS SPECIFICATION, YOU ACCEPT THE TERMS AND CONDITIONS OF THE AGREEMENT. IF YOU ARE NOT WILLING TO BE BOUND BY IT, SELECT THE "DECLINE" BUTTON AT THE BOTTOM OF THIS PAGE.Specification: JSR-340 Java Servlet 3.1 Specification ("Specification")Version: 3.1Status: Final ReleaseSpecification Lead: Oracle America, Inc. ("Specification Lead")Release: April 2013Copyright 2013 Oracle America, Inc.All rights reserved.LIMITED LICENSE GRANTS1. License for Evaluation Purposes. Specification Lead hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limitedlicense (without the right to sublicense), under Specification Lead's applicable intellectual property rights to view, download, use and reproduce the Specification only for the purpose of internal evaluation. This includes (i) developing applications intended to run on an implementation of the Specification, provided that such applications do not themselves implement any portion(s) of the Specification, and (ii)discussing the Specification with any third party; and (iii) excerpting brief portions of the Specification in oral or written communicationswhich discuss the Specification provided that such excerpts do not in the aggregate constitute a significant portion of the Specification.2. License for the Distribution of Compliant Implementations. Specification Lead also grants you a perpetual, non-exclusive, non-transferable, worldwide, fully paid-up, royalty free, limited license (without the right to sublicense) under any applicable copyrights or, subject to theprovisions of subsection 4 below, patent rights it may have covering the Specification to create and/or distribute an Independent Implementation of the Specification that: (a) fully implements the Specification including all its required interfaces and functionality; (b) does not modify,subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields ormethods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; and(c) passes the Technology Compatibility Kit (including satisfying the requirements of the applicable TCK Users Guide) for such Specification("Compliant Implementation"). In addition, the foregoing license is expressly conditioned on your not acting outside its scope. No license isgranted hereunder for any other purpose (including, for example, modifying the Specification, other than to the extent of your fair use rights,or distributing the Specification to third parties). Also, no right, title, or interest in or to any trademarks, service marks, or trade names ofSpecification Lead or Specification Lead's licensors is granted hereunder. Java, and Java-related logos, marks and names are trademarks orregistered trademarks of Oracle America, Inc. in the U.S. and other countries.3. Pass-through Conditions. You need not include limitations (a)-(c) from the previous paragraph or any other particular "pass through"requirements in any license You grant concerning the use of your Independent Implementation or products derived from it. However, exceptwith respect to Independent Implementations (and products derived from them) that satisfy limitations (a)-(c) from the previous paragraph,You may neither: (a) grant or otherwise pass through to your licensees any licenses under Specification Lead's applicable intellectual property rights; nor (b) authorize your licensees to make any claims concerning their implementation's compliance with the Specification in question.4. Reciprocity Concerning Patent Licenses.a. With respect to any patent claims covered by the license granted under subparagraph 2 above that would be infringed by all technically feasible implementations of the Specification, such license is conditioned upon your offering on fair, reasonable and non-discriminatory terms, toPleaseRecycle
any party seeking it from You, a perpetual, non-exclusive, non-transferable, worldwide license under Your patent rights which are or would beinfringed by all technically feasible implementations of the Specification to develop, distribute and use a Compliant Implementation.b With respect to any patent claims owned by Specification Lead and covered by the license granted under subparagraph 2, whether or nottheir infringement can be avoided in a technically feasible manner when implementing the Specification, such license shall terminate withrespect to such claims if You initiate a claim against Specification Lead that it has, in the course of performing its responsibilities as the Specification Lead, induced any other entity to infringe Your patent rights.c Also with respect to any patent claims owned by Specification Lead and covered by the license granted under subparagraph 2 above, wherethe infringement of such claims can be avoided in a technically feasible manner when implementing the Specification such license, withrespect to such claims, shall terminate if You initiate a claim against Specification Lead that its making, having made, using, offering to sell,selling or importing a Compliant Implementation infringes Your patent rights.5. Definitions. For the purposes of this Agreement: "Independent Implementation" shall mean an implementation of the Specification thatneither derives from any of Specification Lead's source code or binary code materials nor, except with an appropriate and separate licensefrom Specification Lead, includes any of Specification Lead's source code or binary code materials; "Licensor Name Space" shall mean thepublic class or interface declarations whose names begin with "java", "javax", "com.sun" and “com.oracle” or their equivalents in any subsequent naming convention adopted by Oracle America, Inc. through the Java Community Process, or any recognized successors or replacements thereof; and "Technology Compatibility Kit" or "TCK" shall mean the test suite and accompanying TCK User's Guide provided bySpecification Lead which corresponds to the Specification and that was available either (i) from Specification Lead's 120 days before the firstrelease of Your Independent Implementation that allows its use for commercial purposes, or (ii) more recently than 120 days from suchrelease but against which You elect to test Your implementation of the Specification.This Agreement will terminate immediately without notice from Specification Lead if you breach the Agreement or act outside the scope ofthe licenses granted above.DISCLAIMER OF WARRANTIESTHE SPECIFICATION IS PROVIDED "AS IS". SPECIFICATION LEAD MAKES NO REPRESENTATIONS OR WARRANTIES,EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR APARTICULAR PURPOSE, NON-INFRINGEMENT (INCLUDING AS A CONSEQUENCE OF ANY PRACTICE OR IMPLEMENTATION OF THE SPECIFICATION), OR THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE.This document does not represent any commitment to release or implement any portion of the Specification in any product. In addition, theSpecification could include technical inaccuracies or typographical errors.LIMITATION OF LIABILITYTO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SPECIFICATION LEAD OR ITS LICENSORS BE LIABLEFOR ANY DAMAGES, INCLUDING WITHOUT LIMITATION, LOST REVENUE, PROFITS OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORYOF LIABILITY, ARISING OUT OF OR RELATED IN ANY WAY TO YOUR HAVING, IMPELEMENTING OR OTHERWISE USINGUSING THE SPECIFICATION, EVEN IF SPECIFICATION LEAD AND/OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.You will indemnify, hold harmless, and defend Specification Lead and its licensors from any claims arising or resulting from: (i) your use ofthe Specification; (ii) the use or distribution of your Java application, applet and/or implementation; and/or (iii) any claims that later versionsor releases of any Specification furnished to you are incompatible with the Specification provided to you under this license.RESTRICTED RIGHTS LEGEND
U.S. Government: If this Specification is being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor orsubcontractor (at any tier), then the Government's rights in the Software and accompanying documentation shall be only as set forth in thislicense; this is in accordance with 48 C.F.R. 227.7201 through 227.7202-4 (for Department of Defense (DoD) acquisitions) and with 48C.F.R. 2.101 and 12.212 (for non-DoD acquisitions).REPORTIf you provide Specification Lead with any comments or suggestions concerning the Specification ("Feedback"), you hereby: (i) agree thatsuch Feedback is provided on a non-proprietary and non-confidential basis, and (ii) grant Specification Lead a perpetual, non-exclusive,worldwide, fully paid-up, irrevocable license, with the right to sublicense through multiple levels of sublicensees, to incorporate, disclose, anduse without limitation the Feedback for any purpose.GENERAL TERMSAny action related to this Agreement will be governed by California law and controlling U.S. federal law. The U.N. Convention for the International Sale of Goods and the choice of law rules of any jurisdiction will not apply.The Specification is subject to U.S. export control laws and may be subject to export or import regulations in other countries. Licensee agreesto comply strictly with all such laws and regulations and acknowledges that it has the responsibility to obtain such licenses to export, re-exportor import as may be required after delivery to Licensee.This Agreement is the parties' entire agreement relating to its subject matter. It supersedes all prior or contemporaneous oral or written communications, proposals, conditions, representations and warranties and prevails over any conflicting or additional terms of any quote, order,acknowledgment, or other communication between the parties relating to its subject matter during the term of this Agreement. No modification to this Agreement will be binding, unless in writing and signed by an authorized representative of each party.
PrefaceThis document is the Java Servlet Specification, version 3.1. The standard for theJava Servlet API is described herein.Additional SourcesThe specification is intended to be a complete and clear explanation of Java Servlets,but if questions remain, the following sources may be consulted: A reference implementation (RI) has been made available which provides abehavioral benchmark for this specification. Where the specification leavesimplementation of a particular feature open to interpretation, implementors mayuse the reference implementation as a model of how to carry out the intention ofthe specification.A compatibility test suite (CTS) has been provided for assessing whetherimplementations meet the compatibility requirements of the Java Servlet APIstandard. The test results have normative value for resolving questions aboutwhether an implementation is standard.If further clarification is required, the working group for the Java Servlet APIunder the Java Community Process should be consulted, and is the final arbiter ofsuch issues.Comments and feedback are welcome, and will be used to improve future versions.Who Should Read This SpecificationThe intended audience for this specification includes the following groups:v
Web server and application server vendors that want to provide servlet enginesthat conform to this standard.Authoring tool developers that want to support Web applications that conform tothis specificationExperienced servlet authors who want to understand the underlying mechanismsof servlet technology.We emphasize that this specification is not a user’s guide for servlet developers andis not intended to be used as such. References useful for this purpose are availablefrom http://java.sun.com/products/servlet.API ReferenceThe full specifications of classes, interfaces, and method signatures that define theJava Servlet API, as well as their accompanying Javadoc documentation, isavailable online.Other Java Platform SpecificationsThe following Java API specifications are referenced throughout this specification: Java Platform, Enterprise Edition ("Java EE"), version 7JavaServer Pages ("JSP "), version 2.2Java Naming and Directory Interface ("J.N.D.I.").Context and Dependency Injection for the Java EE PlatformManaged Beans specificationThese specifications may be found at the Java Platform, Enterprise Edition Web site:http://java.sun.com/javaee/.Other Important ReferencesThe following Internet specifications provide information relevant to thedevelopment and implementation of the Java Servlet API and standard servletengines:viJava Servlet Specification April 2013
261626173986Uniform Resource Identifiers (URI)Uniform Resource Locators (URL)Uniform Resource Identifiers (URI): Generic SyntaxRelative Uniform Resource LocatorsHypertext Transfer Protocol (HTTP/1.0)MIME Part One: Format of Internet Message BodiesMIME Part Two: Media TypesMIME Part Three: Message Header Extensions for non-ASCII textMIME Part Four: Registration ProceduresMIME Part Five: Conformance Criteria and ExamplesHTTP State Management MechanismUse and Interpretation of HTTP Version NumbersHypertext Coffee Pot Control Protocol (HTCPCP/1.0)1Hypertext Transfer Protocol (HTTP/1.1)HTTP Authentication: Basic and Digest AuthenticationUniform Resource Identifier (URI): Generic SyntaxOnline versions of these RFCs are at http://wwww.ietf.org/rfc/.The World Wide Web Consortium (http://www.w3.org/) is a definitive source ofHTTP related information affecting this specification and its implementations.The eXtensible Markup Language (XML) is used for the specification of theDeployment Descriptors described in Chapter 13 of this specification. Moreinformation about XML can be found at the following Web oviding FeedbackWe welcome any and all feedback about this specification. Please e-mail yourcomments to users@servlet-spec.java.net.Please note that due to the volume of feedback that we receive, you will notnormally receive a reply from an engineer. However, each and every comment isread, evaluated, and archived by the specification team.1. This reference is mostly tongue-in-cheek although most of the concepts described in the HTCPCP RFC arerelevant to all well-designed Web servers.Prefacevii
Expert Group members Deepak Anupalli (Pramati Technologies) Euigeun Chung (TmaxSoft, Inc) Robert Goff (IBM) Richard Hightower Seth Hodgson (Adobe Systems Inc.) Remy Maucherat (RedHat) Minoru Nitta (Fujitsu Limited) Ramesh PVK (Pramati Technnologies) Alex Rojkov (Caucho Technologies) Mark Thomas (VMware) Gregory John Wilkins Wenbo Zhu (Google Inc.)AcknowledgementsBill Shannon from Oracle has provided invaluable technical input to thespecification. Ron Monzillo from Oracle has helped drive some of the proposals andtechnical discussions around security aspects.viiiJava Servlet Specification April 2013
Contents1.ContentsixOverview11.1What is a Servlet?1.2What is a Servlet Container?1.3An Example1.4Comparing Servlets with Other Technologies1.5Relationship to Java Platform, Enterprise Edition1.6Compatibility with Java Servlet Specification Version 2.51.6.12.2.2Processing annotations34452.1.1HTTP Specific Request Handling Methods2.1.2Additional Methods2.1.3Conditional GET SupportNumber of Instances5666Note About The Single Thread ModelServlet Life Cycle2.3.135Request Handling Methods2.2.12.312The Servlet Interface2.1177Loading and Instantiation7ix
2.3.22.3.32.3.43.Error Conditions on Initialization2.3.2.2Tool ConsiderationsRequest Handling8892.3.3.1Multithreading Issues2.3.3.2Exceptions During Request Handling2.3.3.3Asynchronous processing2.3.3.4Thread Safety2.3.3.5Upgrade ProcessingEnd of Service91020202123HTTP Protocol Parameters3.1.1x82.3.2.1The Request3.14.Initialization23When Parameters Are Available3.2File upload3.3Attributes3.4Headers3.5Request Path Elements3.6Path Translation Methods3.7Non Blocking IO3.8Cookies3.9SSL Attributes3.10Internationalization3.11Request data encoding3.12Lifetime of the Request ObjectServlet Context242425252627282930303131334.1Introduction to the ServletContext Interface4.2Scope of a ServletContext InterfaceJava Servlet Specification April 201333339
4.3Initialization Parameters4.4Configuration methods4.4.14.4.24.4.33434Programmatically adding and configuring Servlets354.4.1.1addServlet(String servletName, String className)4.4.1.2addServlet(String servletName, Servlet servlet)4.4.1.3addServlet(String servletName, Class ? extendsServlet servletClass) 354.4.1.4 T extends Servlet T createServlet(Class T clazz)4.4.1.5ServletRegistration getServletRegistration(StringservletName) 364.4.1.6Map String, ? extends ServletRegistration getServletRegistrations() 36Programmatically adding and configuring Filters353535364.4.2.1addFilter(String filterName, String className)4.4.2.2addFilter(String filterName, Filter filter)4.4.2.3addFilter(String filterName, Class ? extends Filter filterClass) 374.4.2.4 T extends Filter T createFilter(Class T clazz)4.4.2.5FilterRegistration getFilterRegistration(StringfilterName) 374.4.2.6Map String, ? extends FilterRegistration getServletRegistrations() 37Programmatically adding and configuring Listeners363637384.4.3.1void addListener(String className)384.4.3.2 T extends EventListener void addListener(T t)4.4.3.3void addListener(Class ? extends EventListener listenerClass) 394.4.3.4 T extends EventListener voidcreateListener(Class T clazz) 394.4.3.5Annotation processing requirements forprogrammatically added Servlets, Filters andListeners 4038Contentsxi
4.5Context Attributes4.5.1Context Attributes in a Distributed Container4.6Resources4.7Multiple Hosts and Servlet Contexts4.8Reloading Considerations4.8.15.6.5.2Headers5.3Non Blocking IO5.4Convenience Methods5.5Internationalization5.6Closure of Response Object5.7Lifetime of the Response Objectxii4546474849505051What is a filter?6.1.151Examples of Filtering ComponentsMain Concepts52526.2.1Filter Lifecycle6.2.2Wrapping Requests and Responses6.2.3Filter Environment6.2.4Configuration of Filters in a Web Application6.2.5Filters and the 1Filtering4141Temporary Working DirectoriesThe Response6.17.40525461Session Tracking Mechanisms7.1.1Cookies7.1.2SSL SessionsJava Servlet Specification April 2013616254615855
8.URL Rewriting627.1.4Session Integrity627.2Creating a Session7.3Session Scope7.4Binding Attributes into a Session7.5Session Timeouts7.6Last Accessed Times7.7Important Session Semantics62638.2646465657.7.1Threading Issues7.7.2Distributed Environments7.7.3Client SemanticsAnnotations and pluggability8.19.7.1.365656667Annotations and g8.1.6Other annotations / ty of web.xml718.2.2Ordering of web.xml and web-fragment.xml8.2.3Assembling the descriptor from web.xml, web-fragment.xml andannotations 788.2.4Shared libraries / runtimes pluggability8.3JSP container pluggability8.4Processing annotations and fragmentsDispatching Requests7291939395Contentsxiii
9.1Obtaining a RequestDispatcher9.1.1Using a Request Dispatcher9.3The Include Method9.410.97Included Request Parameters97989.4.1Query String989.4.2Forwarded Request Parameters9.5Error Handling9.6Obtaining an AsyncContext9.7The Dispatch Method9899991009.7.1Query String9.7.2Dispatched Request ParametersWeb Applications10010010310.1Web Applications Within Web Servers10.2Relationship to ServletContext10310.3Elements of a Web Application10410.4Deployment Hierarchies10.5Directory Structure103104104Example of Application Directory Structure10.6Web Application Archive File10.7Web Application Deployment Descriptor10610.7.1Dependencies On Extensions10.7.2Web Application Class Loader10.8Replacing a Web Application10.9Error Handling10810810.9.1Request Attributes10.9.2Error PagesJava Servlet Specification April 20139696The Forward Method10.5.1xivQuery Strings in Request Dispatcher Paths9.29.3.195109108106107107106
10.9.3Error Filters10.10 Welcome Files11111110.11 Web Application Environment11210.12 Web Application Deployment11310.13 Inclusion of a web.xml Deployment Descriptor11.Application Lifecycle Events11.1Introduction11.2Event Listeners11.312.13.11511511511.2.1Event Types and Listener Interfaces11.2.2An Example of Listener UseListener Class Configuration117Provision of Listener Classes11.3.2Deployment Declarations11.3.3Listener Registration11.3.4Notifications At Shutdown11711811811811.4Deployment Descriptor Example11811.5Listener Instances and Threading11911.6Listener Exceptions11.7Distributed Containers11.8Session Events119120120Mapping Requests to Servlets12112.1Use of URL Paths12.2Specification of Mappings12212.2.1Implicit Mappings12212.2.2Example Mapping n125Contentsxv
13.2Declarative Security13.3Programmatic Security13.4Programmatic Security Policy .2Mapping @ServletSecurity to security-constraint13.4.1.3Mapping @HttpConstraint and@HttpMethodConstraint to XML.13513.4.2setServletSecurity of ication13613813.6.1HTTP Basic Authentication13.6.2HTTP Digest Authentication13.6.3Form Based Authentication138138139Login Form Notes14013.6.4HTTPS Client Authentication14113.6.5Additional Container Authentication Mechanisms13.7Server Tracking of Authentication Information13.8Specifying Security Constraints14213.8.1Combining Constraints14313.8.2Example13.8.3Processing Requests13.8.4Uncovered HTTP Protocol Methods13.9xvi126@ServletSecurity es for Security Constraint Configuration13.8.4.2Handling Uncovered HTTP MethodsDefault Policies15013.10 Login and Logout151Deployment Descriptor153Java Servlet Specification April 2013149149133
15.14.1Deployment Descriptor Elements15314.2Rules for Processing the Deployment Descriptor14.3Deployment Descriptor14.4Deployment Descriptor Diagram14.5Examples15515517814.5.1A Basic Example17914.5.2An Example of Security180Requirements related to other Specifications15.1Sessions15.2Web Applications15.315.415.515418318318315.2.1Web Application Class Loader18315.2.2Web Application Environment18415.2.3JNDI Name for Web Module Context Root URLSecurity18418515.3.1Propagation of Security Identity in EJB Calls15.3.2Container Authorization Requirements15.3.3Container Authentication RequirementsDeployment18618618618715.4.1Deployment Descriptor Elements15.4.2Packaging and Deployment of JAX-WS Components15.4.3Rules for Processing the Deployment DescriptorAnnotations and Resource EJB Annotation15.5.3@EJBs Annotation15.5.4@Resource Annotation15.5.5@PersistenceContext Annotation15.5.6@PersistenceContexts Annotation191192192193193Contentsxvii
15.5.7@PersistenceUnit Annotation15.5.8@PersistenceUnits Annotation15.5.9@PostConstruct Annotation15.5.10 @PreDestroy Annotation15.5.11 @Resources Annotation15.5.12 @RunAs Annotation19419419419519519615.5.13 @WebServiceRef Annotation15.5.14 @WebServiceRefs Annotation19719715.5.15 Contexts and Dependency Injection for Java EE requirementsA. Change LogChanges since Servlet 3.0A.2Changes since Servlet 3.0 Proposed Final DraftA.3Changes since Servlet 3.0 Public ReviewA.4Changes since Servlet 3.0 EDR202A.5Changes since Servlet 2.5 MR6202A.6Changes since Servlet 2.5 MR 5203A.8xviii199A.1A.7197199201202A.6.1Clarify SRV 8.4 "The Forward Method"A.6.2Update Deployment descriptor "http-method values allowed"203A.6.3Clarify SRV 7.7.1 "Threading Issues"Changes Since Servlet 2.5 MR 2203204204A.7.1Updated Annotation Requirements for Java EE containersA.7.2Updated Java Enterprise Edition Requirements204A.7.3Clarified HttpServletRequest.getRequestURL()204A.7.4Removal of IllegalStateException from ath()A.7.6Requirement for web.xml in web applicationsChanges Since Servlet 2.4Java Servlet Specification April 2013206205206204205
A.8.1Session Clarification206A.8.2Filter All Dispatches207A.8.3Multiple Occurrences of Servlet MappingsA.8.4Multiple Occurrences Filter MappingsA.8.5Support Alternative HTTP Methods with AuthorizationConstraints 209A.8.6Minimum J2SE RequirementA.8.7Annotations and Resource InjectionA.8.8SRV.9.9 ("Error Handling") Requirement dValid() Clarification210207208210210210A.8.10 SRV.5.5 ("Closure of Response Object") ClarificationA.8.11 ServletRequest.setCharacterEncoding() ClarifiedA.8.12 Java Enterprise Edition RequirementsA.8.14 Synchronized Access Session Object ClarifiedChanges Since Servlet 2.3211211A.8.13 Servlet 2.4 MR Change Log Updates AddedA.9210211211211Contentsxix
xxJava Servlet Specification April 2013
CHAPTER1Overview1.1What is a Servlet?A servlet is a Java technology-based Web component, managed by a container, thatgenerates dynamic content. Like other Java technology-based components, servletsare platform-independent Java classes that are compiled to platform-neutral bytecode that can be loaded dynamically into and run by a Java technology-enabled Webserver. Containers, sometimes called servlet engines, are Web server extensions thatprovide servlet functionality. Servlets interact with Web clients via arequest/response paradigm implemented by the servlet container.1.2What is a Servlet Container?The servlet container is a part of a Web server or application server that provides thenetwork services over which requests and responses are sent, decodes MIME-basedrequests, and formats MIME-based responses. A servlet container also contains andmanages servlets through their lifecycle.A servlet container can be built into a host Web server, or installed as an add-oncomponent to a Web Server via that server’s native extension API. Servlet containerscan also be built into or possibly installed into Web-enabled application servers.All servlet containers must support HTTP as a protocol for requests and responses,but additional request/response-based protocols such as HTTPS (HTTP over SSL)may be supported. The required versions of the HTTP specification that a containermust implement are HTTP/1.0 and HTTP/1.1. Because the container may have acaching mechanism described in RFC2616 (HTTP/1.1), it may modify requests from1-1
the clients before delivering them to the servlet, may modify responses produced byservlets before sending them to the clients, or may respond to requests withoutdelivering them to the servlet under the compliance with RFC2616.A servlet container may place security restrictions on the environment in which aservlet executes. In a Java Platform, Standard Edition (J2SE, v.1.3 or above) or JavaPlatform, Enterprise Edition (Java EE, v.1.3 or above) environment, these restrictionsshould be placed using the permission architecture defined by the Java platform. Forexample, high-end application servers may limit the creation of a Thread object toinsure that other components of the container are not negatively impacted.Java SE 7 is the minimum version of the underlying Java platform with which servletcontainers must be built.1.3An ExampleThe following is a typical sequence of events:1. A client (e.g., a Web browser) accesses a Web server and makes an HTTP request.2. The request is received by the Web server and handed off to the servlet container.The servlet container can be running in the same process as the host Web server,in a different process on the same host, or on a different host from the Web serverfor which it processes requests.3. The servlet container determines which servlet to invoke based on theconfiguration of its servlets, and calls it with objects representing the request andresponse.4. The servlet uses the request object to find out who the remote user is, what HTTPPOST parameters may have been sent as part of this request, and other relevantdata. The servlet performs whatever logic it was programmed with, and generatesdata to send back to the client. It sends this data back to the client via theresponse object.5. Once the servlet has finished processing the request, the servlet container ensuresthat the response is properly flushed, and returns control back to the host Webserver.1-2Java Servlet Specification April 2013
1.4Comparing Servlets with OtherTechnologiesIn functionality, servlets lie somewhere between Common Gateway Interface (CGI)programs and proprietary server extensions such as the Netscape Server API(NSAPI) or Apache Modules.Servlets have the following advantages over other server extension mechanisms: 1.5They are generally much faster than CGI scripts because a different process modelis used.They use a standard API that is supported by many Web servers.They have all the advantages of the Java programming language, including easeof development and platform independence.They can access the large set of APIs available for the Java platform.Relationship to Java Platform, EnterpriseEditionThe Java Servlet API v.3.1 is a required API of the Java Platform, Enterprise Edition,71. Servlet containers and servlets deployed into them must meet a
This document is the Java Servlet Specification, version 3.1. The standard for the Java Servlet API is described herein. Additional Sources The specification is intended to be a complete and clear explanation of Java Servlets, but if questions remain, the following sources may be consulted:
