Head First Servlets & JSP 笔记（一）

A web browser lets a user request a resource. The web server gets the request, finds the resource, and returns something to the user.

The browser's other big job is interpreting the HTML code and rendering the web page for the user.

The HTML tells the browser how to present the content to the user

HTML has dozens of tags and hundreds of tag attributes. The goal of HTML is to take a text document and add tags that tell the browser how to format the text.

TCP is responsible for making sure that a file sent from one network node to another ends up as a complete file at the destination, even though the file is split into chunks when Key elements stream of the it is sent.

IP is the underlying protocol that moves/routes the chunks (packets) from one host to another on their way to the destination. HTTP, then, is another network protocol that has Web-specific features, but it depends on TCP/IP to get the complete request and response from one place to another.

Key elements of the request stream:

• HTTP methods (the action to be performed)
• The page to access (URL)
• Form parameters

Key elements of the response stream:

• A status code
• Content-type
• The content

The structure of an HTTP conversation is a Request/Response.

An HTTP response can contain HTML. HTTP adds header information to the top of whatever content is in the response.

The job of GET is to ask the server to get a resource and give its back.

With POST, you can request send some parameter something and at the same time send form data to the server.

Reasons you might use POST instead of GET include

• total amount of characters in a GET is really limited (depending on the server
• data you send with the GET is appended to the URL up in the browser bar, so whatever you send is exposed
• The user can't bookmark a form submission if you use POST instead of GET

The path to the resource, and any parameters added to the URL are all included on the "request line".

An HTTP response has both a header and a body. The header info tells the browser about the protocol being used, whether the request was successful, and what kind of content is included in the body. The body contains the contents (for example, HTML) for the browser to display.

URL——Uniform Resource Locators

The web server application serves only static pages, but a separate "helper" application that the web server can communicate with can build non-static, just-in-time pages.

Just-in-time pages don't exist before the request comes in. It's like making an HTML page out of thin air. The request comes in, the helper app "writes" the HTML, and the web server gets it back to the client.

Web server hands over the parameters, and gives the app a way to generate a response to the client

CGI stands for Common Gateway Interface.

One DD per web application.

• A DD can declare many servlets.
• A <servlet-name> ties the to the <servletmapping<servlet> element > element.
• A <servlet-class> is the Java class.
• A <url-pattern> is the name the client uses for the request

Points:

• HTTP stands for Hypertext Transfer Protocol, and is the network protocol used on the Web. It runs on top of TCP/IP.
• HTTP uses a request/response model—the client makes an HTTP request, and the web server gives back an HTTP response that the browser then figures out how to handle (depending on the content type of the response).
• If the response from the server is an HTML page, the HTML is added to the HTTP response.
• An HTTP request includes the request URL (the resource the client is trying to access), the HTTP method (GET, POST, etc.), and (optionally) form parameter data (also called the "query string").
• An HTTP response includes a status code, the content-type (also known as MIME type), and the actual content of the response (HTML, image, etc.)
• A GET request appends form data to the end of the URL.
• A POST request includes form data in the body of the request.
• A MIME type tells the browser what kind of data the browser is about to receive so that the browser will know what to do with it (render the HTML, display the graphic, play the music, etc.)
• URL stands for Uniform Resource Locator. Every resource on the web has its own unique address in this format. It starts with a protocol, followed by the server name, an optional port number, and usually a specific path and resource name. It can also include an optional query string, if the URL is for a GET request.
• Web servers are good at serving static HTML pages, but if you need dynamically generated data in the page (the current time, for example), you need some kind of helper app that can work with the server. The non-Java term for these helper apps (most often written in Perl) is CGI (which stands for Common Gateway Interface).
• Putting HTML inside a println() statement is ugly and error-prone, but JSPs solve that problem by letting you put Java into an HTML page rather than putting HTML into Java code.

Servlets don't have a main() method. They're under the control of another Java application called a Container.

When your web server application (like Apache) gets a request for a servlet (as opposed to, say, a plain old static HTML page), the server hands the request not to the servlet itself, but to the Container in which the servlet is deployed. It's the Container that gives the servlet the HTTP request and response, and it's the Container that calls the servlet's methods (like doPost() or doGet()).

Container gives you:

• Communications support
  • Connect your servlet to the web server.
• Lifecycle Management
  • It takes care of loading the classes, instantiating and initializing the servlets, invoking the servlet methods, and making servlet instances eligible for garbage collection. With the Container in control, you don't have to worry as much about resource management.
• Multithreading Support
  • The Container automatically creates a new Java thread for every servlet request it receives. When the servlet's done running the HTTP service method for that client's request, the thread dies.
• Declarative Security
  • With a Container, you get to use an XML deployment descriptor to configure (and modify) security without having to hard-code it into your servlet (or any other) class code.
• JSP support

The URL that comes in as part of the request from the client is mapped to a specific servlet on the server.

The <servlet> element tells the container with class files belong to a particular web application.

The <servlet-name> element is used to tie a specific <servlet-mapping> element to a <servlet> element. The end-user never see the name; it is only used in other parts of DD.

When you deploy your servlet into your web Container, you will create a simple XML document called the Deployment Descriptor to tell the Container how to run your servlets and JSPs.

You'll use two XML elements to map URLs to servlets—one to map the client-known public URL name to your own internal name, and the other to map your own internal name to a fully-qualified class name.

The two DD elements for URL mapping:

1. <servlet> maps internal name to fully-qualified class name
2. <servlet-mapping> maps internal name to public URL name

You can use the DD to customize other aspects of your web application including security roles, error pages, tag libraries, initial configuration information, and if it's a full J2EE server, you can even declare that you'll be accessing specific enterprise javabeans.

Model View Controller (MVC) takes the business logic out of the servlet, and puts it in a "Model"— a reusable plain old Java class. The Model is a combination of the business data.

The spec always changes.

Controller: Takes user input from the request and figures out what it means to the model. Tells the model to and makes the update itself, new model state available for the view (the JSP).

Model: Holds the real business logic and the state. In other words, it knows the rules for getting and updating the state. It's the only part that talks to the database.

View: Responsible for the JSP presentation. It gets the JSP state of the model from the Controller. It's also the part that gets the user input that goes back to the Controller.

POINTS of the Container

• The Container gives your web app communications support, lifecycle management, multithreading support, declarative security, and support for JSPs, so that you can concentrate on your own business logic.
• The Container creates a request and response object that servlets (and other parts of the web app) can use to get information about the request and send information to the client.
• A typical servlet is a class that extends HttpServlet and overrides one or more service methods that correspond to HTTP methods invoked by the browser (doGet(), doPost(), etc.).
• The deployer can map a servlet class to a URL that the client can use to request that servlet. The name may have nothing to do with the actual class file name.