Reading Notes for Chapter 1,
Head First Servlets and JSP

P. Conrad, CISC474, Spring 2006

Table of contents

p1: Intro: Web Site vs. Web App

Do you know what Swing is? (You should, from CISC370).

Question to consider: What is the advantage of deploying an application in a web browser vs. a a stand-alone GUI app? (And what is a GUI app?) What are the disadvantages of deploying in a web browser vs. as a stand-alone GUI app? Think about the pros/cons. (I might ask you on an exam, as evidence that you can engage in "critical thinking" (goal 2 under UD's goals for undergraduate education.)

p2: Objectives

Every chapter in the book starts with a list of objectives from the "Sun Certified Web Component Developer Exam" (SCWCDE). The original purpose of this textbook is to help prepare folks to take that exam.

So be warned: Throughout the textbook, when the authors mention "the exam", they are talking about the SCWCDE exam, not the exams for CISC474! Sometimes there will be things that are on the SCWCDE that I will not ask you about (including some details of the API specification, for example). The reverse is also true: the SCWCDE exam doesn't cover details of XHTML, CSS or JavaScript, but I will ask you about those things (that's what the Sebesta text is for.)

I'm not sure, in the grand scheme of things, how important certification exams such as the SCWCDE really are—opinions from folks in the so called "real world" differ on that.

• Here's an article on IT certifications from monster.com
• If you have other information on the value (or non-value) of IT certifications, esp. on the SCWCDE certification, post it to the WebCT discussion board titled "Reading Notes for HFSJ...".

However, it is kind of useful that each chapter starts with learning objectives. At the end of most chapters, you can use these to check whether you "learned what you were supposed to learn"... well, except for this chapter, since the "coverage notes" indicate that the topics covered here are covered in more detail in later chapters anyway.

p3: Everybody wants a web site

Introduces the idea of client and server.
Be able to identify "Mozilla" and "Apache" as one or the other.

p4: What does your web server do?

On pages like this, be sure to read through both the text, and look at all the picture and read all the captions. Sometime there is information covered only in the pictures, and not in the text.

Things to know: browser, resource, server, page, request, response, content

Also see: Sebesta, section 1.4.

p5: What does a web client do?

As explained on this page, describe how the word "client" can be used in two different ways. How is the word "client" used in this textbook?

Webster's dictionary says that one definition of rendering is "to melt down, to extract by melting (e.g. render lard); to treat so as to convert into industrial fats and oils or fertilizer"). According to this page, what do you interpret that "rendering" means in the context of web development?

Also see: Sebesta, section 1.3

p6: Clients and Servers know HTML and HTTP

Check the confirmed errata for this page!

Know the difference between HTML and HTTP. This difference is re-enforced on pages 7-19.

p7: Two minute HTML guide

Though you shouldn't bother memorizing them right now, by the time the first midterm comes around, you should know all the tags on this page.

But, be advised; as the book indicates, <align> and <center> are deprecated; while you may use them during the first two weeks of class, by week three you should be able to avoid them by using their replacements (e.g. <span> and <div> tags with CSS properties) (see Chapters 2 and 3 in Sebesta).

Other things this page glosses over:

• <input type> is not a literal tag... the actual tag is something like <input type="text"> or <input type="radio"> or <input type="checkbox">, and so forth.
• Technically speaking, the way that "align" is used in the example that follows on p8, align is an "attribute" of the <h1> and <p> tags, not a tag in its own right.

Not covered on this page, but also important to know:

Be aware of various versions of HTML that we will deal with in this course. Sebesta, section 2.1 provides an overview of these:

• HTML 4.01
• XHTML v1.0 (strict, transitional and frameset)
• XHTML v1.1

Sometimes, to keep things simple, the authors use older styles of HTML that would not be considered "valid" according to the most current specs, though they still would probably work in most browsers. Here are examples of "bad habits" you might pick up from the book, and good habits you should adopt instead:

See also: Sebesta, Chapters 2 and 3

p8: What you write... (the HTML)
p9: What the browser creates...

It is best to look at these two pages together.

Note a few things:

• The <img> element is a self-closing element.
• The items src, width and height inside the <img> tag are called "attributes".
• The <input type="text"> elements need to be nested inside a <form> element.
• For strict validation, the value of the type attribute of the last <input> element would be in lowercase, e.g. <input type="submit">, rather than <input type="SUBMIT">. Note that in the rendered version on p. 9, the uppercase isn't preserved anyway.

Also, a few things concerning validation:

• I've created a copy of this HTML in the file ch01/p8 orig.html. This file "tentatively" passes validation at validator.w3.org as HTML 3.2 (after selecting HTML 3.2 from the drop down menu, since no "doctype" declaration is in the document.) However it is not valid HTML 4.01, even using the "transitional" DTD (I'll leave it as an exercise to you to find the things that are wrong with it.)
• I've also created an updated copy of this HTML in the file ch01/p8_xhtml11.html. I've updated the content to be valid XHTML v1.1 (the strictest current standard.). I suggest that you compare the two to see what had to be changed for this file to pass validation.

p10: What is the HTTP protocol

The main things to know about HTTP in order to be able to build web apps are these:

• it is a request/response protocol
• a request has a "request type", "request headers" and a payload
• a response has a "response type", a "response headers" and a payload

This page also mentions the individual roles of TCP and IP (i.e. which part does TCP do, and which part does IP do.)

Note: the "relax" box at the bottom of p. 10 indicates that the SCWCDE exam (see explanation earlier on this web page) indicates that you don't have to memorize the HTTP spec. I agree, and that good news, because the HTTP spec is 175 pages of dense technical details.

That box also indicates that "The HTTP protocol is an IETF standard, RFC 2616. If you care. Fortunately the [SCWCDE] exam doesn't expect you to."

However, I do care that the HTTP spec is an IETF standard, and I expect you to care also, since that fact might be on the CISC474 exams. That means you ought to know what the IETF is, and what an RFC is also. Ask me during lecture if I don't already mention this, since it isn't in either of the textbooks, as far as I know.

See also: Section 1.7 in Sebesta

p11: HTML is part of the HTTP response

This page is a good place to get the "relationship" between HTML and HTTP (e.g. if you need it for a "concept map").

Another interesting point is made in the notes next to the picture. To see if you understand the point, answer these questions:

• If an HTML file contains some text, and an img tag, how many HTTP requests need to be made for that page?
• What if the HTML file contains three images—how many HTTP requests then?

If you are not sure, ask during lecture.

See also: Sebesta Section 1.7.2

p12: If that's the response what's in the request?

Pages 12 through 16 cover two of the HTTP methods: GET and POST. It is advisable to read these pages through together.

First, note the difference between HTTP "methods" and Java "methods"—two completely different uses of the same word.

Then, focus on the differences between GET and POST. There is not just one difference, there are several.

The choice as to whether to use GET or POST for any given web transaction is an important theme in web development, and one we'll come back to often. Pages 12-16 are not the last word on this topic. (In fact, we'll revisit this topic in detail in Chapter 4)

p13: GET is a simple request, POST can send user data

Be sure to read pages 13 and 14 together.

p14: It's true... you can send a little data with HTTP GET

This page contains a initial list of reasons why you might use POST instead of GET, and for now, it's a good enough list. However, there is more to say on in this Chapter 4 though, so keep an open mind.

Also, can you think of any times when, based on the information on this page, you might want to use GET instead of POST?

p15: Anatomy of an HTTP GET request

Check the confirmed errata for this page!

It is your browser that converts a URL such as

into the GET request that you see here, with the HTTP method on the first line followed by the path, parameters, and protocol version, and a sequence of request headers. Not shown is the fact that following the request headers there needs to be one extra "blank line" (i.e. a carriage return/line feed combination) to mark the end of the HTTP request in the TCP data stream.

See also: Sebesta Section 1.7.1

p16: Anatomy of an HTTP POST request

Note the similarity with the GET request on p. 15, and also the key difference (i.e. where the parameters go).

p17: Anatomy of an HTTP response, and what the heck is a "MIME type"?

MIME types will turn up throughout the semester, so its worth reviewing what they are both on this page, and in the Sebesta text.

See also: p. 130 in HFSJ, and in Sebesta, Section 1.6 (MIME types), and Section 1.7.2 (HTTP Responses)

p18: All the pieces. On one page.

Check the unconfirmed errata for this page!

Study this page in some detail until you get it. You'll be quizzed on this page later! (no kidding!)

p19: Sharpen your pencil: GET or POST?

The answers to this page aren't in the book as far as I know. But we might discuss these in class.

p20: URL. Whatever you do, don't pronounce it "Earl"

Know the parts of a URL: protocol, server, port, path, resource and query string.

We may cover later the technical distinction between URLs, URNs and URIs, but for now, we'll leave that be.

Also see: Section 1.5 in Sebesta

p21: A TCP port is just a number

Check the confirmed errata for this page!

Make sure you understand what a port number is, and know that the "well-known port number" for HTTP is port 80. However, typically only a user with system manager privileges can set up services on port numbers 1023 or lower (by system manager, we mean "root" on Unix, or "administrator" on Windows.)

So, if you have only user privileges on the machine when you are running your web server, you typically have to use a port other than port 80. Ports in the 8000-8999 range are typically used, but that is by convention only; any unused port will do.

The Unix command "netstat -an | grep xxxx" can be used to check whether port xxxx is in use.

Typically, on strauss, you'll just "pick any old port number" that is not in use, use it for a short time, then shutdown your server. When we cover how to start up the Tomcat web server, we'll cover how to configure which port to use.

Note that Tomcat can use up to three ports at once:

• one port for HTTP requests/responses (i.e. URLs starting with http://)
• one port for secure HTTP requests/responses (i.e. URLs starting with https://)
• one port where it listens for a shutdown request (i.e. a message that you want the server to shutdown)

A few notes on ports when running on cis.udel.edu systems:

When we run on jaguar.cis.udel.edu or the machines that are part of the porsche.cis.udel.edu cluster, you'll be assigned a specific port number to use. This is necessary because only certain port numbers are allowed to go through the firewall on the cis.udel.edu systems.

Furthermore, when using the "back end" machines on the porsche.cis.udel.edu cluster, the back-end machines aren't directly connected to the internet. Therefore, porsche.cis.udel.edu has to pass thru requests coming in on particular ports to specific back end machines, so only certain port numbers will work.

p22: Directory structure for a simple Apache web site

This page is pretty self-explanatory, and is mostly there to serve as a diagram for the exercise on p. 23.

p23: Sharpen your pencil: Mapping URLs to content

This is an exercise that you should fill in to make sure you are following.
Fill in your answers, and then check them on the bottom p. 24 (upside-down.)

p24: Web servers love serving static pages
p25: But sometimes you need more than just a web server

These two pages should be read together; they set up the material on p. 26 through p. 28,
which is, in one sense, the core of what CISC474 is all about.

p26: Two things the web server alone won't do

Check the confirmed errata for this page!

This page is crucial; in some sense, the main thrust of the entire course CISC474 is to cover techniques for helping web apps do the two things indicated on this page.

p27: The non-Java term for a web server helper app is "CGI" program

Note that this page describes a kind of "generic architecture" that is common to many server side web technologies, including Perl, C, Python, PHP, as well as Java servlets and JSPs.

See also: Sebesta Chapter 10.

p28: Servlets and CGI both play the role of a helper app in the web server

An interesting discussion, and one that is continued later in the book.

Towards the end of this discussion, there is talk of J2EE. Read up on your own about J2EE; there is some controversy in the Java community about whether J2EE is too "heavyweight for its own good". In fact, that's the entire thrust of the book Better Faster Lighter Java (our third required textbook), especially Chapter 1 of BFLJ. In particular, BFLJ Section 1.1.1 skewers EJB, comparing it to the game "Up Up with the Fish" from Dr. Seuss's The Cat in the Hat. Can you find some arguments on the "other side" of this debate?

See also: Sebesta, Chapter 11 intro, and Section 11.1. You could read on to Section 11.2, and further, but I'd advise waiting until after Chapters 2,3,4 in HFSJ.

p29: Sharpen your pencil: Request Response

Didn't I warn you back on page 18 that you were going to be quizzed? Don't be surprised if something like this ends up on a midterm or final exam also!

p30: Servlets Demystified (write, deploy, run)

Check the confirmed errata for this page! There is a problem with the XML code for step 3 that you need to fix before you type it in.

Note that deploying the code on this page is part of a class participation assignment (work/part/P02.html). The instructions given here assume you are deploying this servlet on strauss according to the instructions given in that file.

The directory tree shown is rooted under "project1". It is probably a good idea to put this directory under ~/cisc474, i.e.:

p31: (p. 30 continued)

When building this directory tree (the one on step 4, build it directly under your home directory, i.e.

Then in step 5, note that the "your path" part should be replaced with the value of the environment variable CATALINA_HOME, and that this command should be executed in the project1 directory, i.e..

Steps 6 and 7 involve copying the Ch1Servlet.class file to WEB-INF/classes, and the web.xml file to WEB-INF, then starting the Tomcat server:

Step 7 involves starting up Tomcat:

Note that in step 8, you need to substitute your port number in place of 8080, and "strauss.udel.edu" in place of "localhost".

For step 9, to shutdown the server, use:

Eventually, you'll be expected to be able to make these adjustments from what the "book says" to what "you have to do on strauss" on your own without this handholding.

p32: Actually, trying to format HTML inside a servlet's out.println() pretty much sucks
p33: She doesn't know about JSP

Pages 32 and 33 should be read together. They are central to understanding why Java Server Pages (JSPs) are a good idea.

Later, you'll understand that the concept of a servlet and the concept of a JSP have an interesting relationship; one that is crucial to understand. For now, it is ok to think of them as two separate things

p34: JSP is what happened when somebody introduced Java to HTML

This pages fills in more detail about the points made on p. 32 and p. 33.

The Q and A at the bottom of p. 34 is also important, though you might find the answer given sort of "hard to swallow" at this early stage. It still may seem to you at this point that a developer would still have to know both HTML and Java to write a JSP. In the end, this turns out not to be the case. However, this point wont be fully clear until around the middle of Chapter 7 when we cover the Expression Language (EL) and tag libraries. Until then, you'll have to take this part on faith.

p35: Bullet Points

Check the confirmed errata for this page!

Be sure to fix the error in these bullet points, but after that, they are a great thing to review and study from for the midterm and final exams!

End of CISC474 reading notes for HFSJ, Chapter 1