Generating the Server Response: HTTP Status Codes

Java/J2EE Programming Training
Generating the Server Response: HTTP
Status Codes

Classification: Restricted
Agenda
• Format of the HTTP response
• How to set status codes
• What the status codes are good for
• Shortcut methods for redirection and error pages
• A servlet that redirects users to browser-specific pages
• A front end to various search engines

• Request
• GET /servlet/SomeName
HTTP/1.1
• Host: ...
• Header2: ...
• ...
• HeaderN:
• (Blank Line)
• Response
• HTTP/1.1 200 OK
• Content-Type: text/html
• Header2: ...
• ...
• HeaderN: ...
• (Blank Line)
• <!DOCTYPE ...>
• <HTML>
• <HEAD>...</HEAD>
• <BODY>
• ...
• </BODY></HTML>
HTTP Request/Response

• response.setStatus(int statusCode)
– Use a constant for the code, not an explicit int.
Constants are in HttpServletResponse
– Names derived from standard message.
E.g., SC_OK, SC_NOT_FOUND, etc.
• response.sendError(int code,
String message)
– Wraps message inside small HTML document
• response.sendRedirect(String url)
– Sets status code to 302
– Sets Location response header also
Setting Status Codes

• 200 (OK)
– Everything is fine; document follows.
– Default for servlets.
• 204 (No Content)
– Browser should keep displaying previous document.
• 301 (Moved Permanently)
– Requested document permanently moved elsewhere (indicated in
Location header).
– Browsers go to new location automatically.
Common HTTP 1.1 Status Codes

• 302 (Found)
– Requested document temporarily moved elsewhere (indicated in Location
header).
– Browsers go to new location automatically.
– Servlets should use sendRedirect, not setStatus, when setting this header.
See example.
• 401 (Unauthorized)
– Browser tried to access password-protected page without proper
Authorization header.
• 404 (Not Found)
– No such page. Servlets should use sendError to set this.
– Problem: Internet Explorer and small (< 512KB) error pages. IE ignores
error page by default.
– Fun and games: http://www.plinko.net/404/
Common HTTP 1.1 Status Codes (Continued)

• public class WrongDestination extends HttpServlet {
• public void doGet(HttpServletRequest request,
• HttpServletResponse response)
• throws ServletException, IOException {
• String userAgent = request.getHeader("User-Agent");
• if ((userAgent != null) &&
• (userAgent.indexOf("MSIE") != -1)) {
• response.sendRedirect("http://home.netscape.com");
• } else {
• response.sendRedirect("http://www.microsoft.com");
• }
• }
• }
A Servlet That Redirects Users to Browser-Specific Pages

A Servlet That Redirects Users to Browser-Specific Pages

Generating the Server Response:
HTTP Response Headers

Agenda
• Format of the HTTP response
• Setting response headers
• Understanding what response headers are good for
• Building Excel spread sheets
• Sending incremental updates
to the browser

• public void setHeader(String headerName,
String headerValue)
– Sets an arbitrary header
• public void setDateHeader(String name,
long millisecs)
– Converts milliseconds since 1970 to a date string
in GMT format
• public void setIntHeader(String name,
int headerValue)
– Prevents need to convert int to String before calling setHeader
• addHeader, addDateHeader, addIntHeader
– Adds new occurrence of header instead of replacing
Setting Arbitrary Response Headers

• setContentType
– Sets the Content-Type header.
– Servlets almost always use this.
– See table of common MIME types.
• setContentLength
– Sets the Content-Length header.
– Used for persistent HTTP connections.
– See Connection request header.
• addCookie
– Adds a value to the Set-Cookie header.
– See separate section on cookies.
• sendRedirect
– Sets the Location header (plus changes status code).
Setting Arbitrary Response Headers

Type Meaning
application/msword Microsoft Word document
application/octet-stream Unrecognized or binary data
application/pdf Acrobat (.pdf) file
application/postscript PostScript file
application/vnd.ms-excel Excel spreadsheet
application/vnd.ms-powerpoint Powerpoint presentation
application/x-gzip Gzip archive
application/x-java-archive JAR file
application/x-java-vm Java bytecode (.class) file
application/zip Zip archive
audio/basic Sound file in .au or .snd format
audio/x-aiff AIFF sound file
audio/x-wav Microsoft Windows sound file
audio/midi MIDI sound file
text/css HTML cascading style sheet
text/html HTML document
text/plain Plain text
text/xml XML document
image/gif GIF image
image/jpeg JPEG image
image/png PNG image
image/tiff TIFF image
video/mpeg MPEG video clip
video/quicktime QuickTime video clip
Common MIME Types

• Cache-Control (1.1) and Pragma (1.0)
– A no-cache value prevents browsers from caching page.
• Content-Disposition
– Lets you request that the browser ask the user to save the response to
disk in a file of the given name
• Content-Disposition: attachment; filename=file-name
• Content-Encoding
– The way document is encoded. See earlier compression example
• Content-Length
– The number of bytes in the response.
– See setContentLength on previous slide.
– Use ByteArrayOutputStream to buffer document before sending it, so
that you can determine size. See discussion of the Connection request
header
Common HTTP 1.1 Response Headers

• Content-Type
– The MIME type of the document being returned.
– Use setContentType to set this header.
• Expires
– The time at which document should be considered out-of-date and thus
should no longer be cached.
– Use setDateHeader to set this header.
• Last-Modified
– The time document was last changed.
– Don’t set this header explicitly; provide a getLastModified method
instead. See lottery number example in book (Chapter 3).
Common HTTP 1.1 Response Headers (Continued)

• Location
– The URL to which browser should reconnect.
– Use sendRedirect instead of setting this directly.
• Refresh
– The number of seconds until browser should reload page. Can also
include URL to connect to.
See following example.
• Set-Cookie
– The cookies that browser should remember. Don’t set this header
directly; use addCookie instead. See next section.
• WWW-Authenticate
– The authorization type and realm needed in Authorization header. See
security chapters in More Servlets & JSP.
Common HTTP 1.1 Response Headers (Continued)

Agenda
• Understanding the benefits and drawbacks of cookies
• Sending outgoing cookies
• Receiving incoming cookies
• Tracking repeat visitors
• Specifying cookie attributes
• Differentiating between session cookies and persistent cookies
• Simplifying cookie usage with utility classes
• Modifying cookie values
• Remembering user preferences

• Idea
– Servlet sends a simple name and value to client.
– Client returns same name and value when it connects to same site (or
same domain, depending on cookie settings).
• Typical Uses of Cookies
– Identifying a user during an e-commerce session
• Servlets have a higher-level API for this task
– Avoiding username and password
– Customizing a site
– Focusing advertising
The Potential of Cookies

Cookies and Focused Advertising

• The problem is privacy, not security.
– Servers can remember your previous actions
– If you give out personal information, servers can link that information to
your previous actions
– Servers can share cookie information through use of a cooperating third
party like doubleclick.net
– Poorly designed sites store sensitive information like credit card numbers
directly in cookie
– JavaScript bugs let hostile sites steal cookies (old browsers)
• Moral for servlet authors
– If cookies are not critical to your task, avoid servlets that totally fail when
cookies are disabled
– Don't put sensitive info in cookies
Some Problems with Cookies

Manually Deleting Cookies (To Simplify Testing)

• Create a Cookie object.
– Call the Cookie constructor with a cookie name and a cookie value, both
of which are strings.
• Cookie c = new Cookie("userID", "a1234");
• Set the maximum age.
– To tell browser to store cookie on disk instead of just in memory, use
setMaxAge (argument is in seconds)
• c.setMaxAge(60*60*24*7); // One week
• Place the Cookie into the HTTP response
– Use response.addCookie.
– If you forget this step, no cookie is sent to the browser!
• response.addCookie(c);
Sending Cookies to the Client

• Call request.getCookies
– This yields an array of Cookie objects.
• Loop down the array, calling getName on each entry until you find the
cookie of interest
– Use the value (getValue) in application-specific way.
– String cookieName = "userID";
– Cookie[] cookies = request.getCookies();
– if (cookies != null) {
– for(int i=0; i<cookies.length; i++) {
– Cookie cookie = cookies[i];
– if (cookieName.equals(cookie.getName())) {
– doSomethingWith(cookie.getValue());
– }
– }
– }
Reading Cookies from the Client

• public class RepeatVisitor extends HttpServlet {
• boolean newbie = true;
• Cookie[] cookies = request.getCookies();
• if (cookies != null) {
• for(int i=0; i<cookies.length; i++) {
• Cookie c = cookies[i];
• if ((c.getName().equals("repeatVisitor"))&&
• (c.getValue().equals("yes"))) {
• newbie = false;
• break;
• }
• }
• }
Using Cookies to Detect First-Time Visitors

• String title;
• if (newbie) {
• Cookie returnVisitorCookie =
• new Cookie("repeatVisitor", "yes");
• returnVisitorCookie.setMaxAge(60*60*24*365);
• response.addCookie(returnVisitorCookie);
• title = "Welcome Aboard";
• } else {
• title = "Welcome Back";
• }
• response.setContentType("text/html");
• PrintWriter out = response.getWriter();
• … // (Output page with above title)
Using Cookies to Detect First-Time Visitors (Continued)

Using Cookies to Detect First-Time Visitors (Results)

• getDomain/setDomain
– Lets you specify domain to which cookie applies. Current host must be
part of domain specified.
• getMaxAge/setMaxAge
– Gets/sets the cookie expiration time (in seconds). If you fail to set this,
cookie applies to current browsing session only. See LongLivedCookie
helper class given earlier.
• getName
– Gets the cookie name. There is no setName method; you supply name to
constructor. For incoming cookie array, you use getName to find the
cookie of interest.
Using Cookie Attributes

• getPath/setPath
– Gets/sets the path to which cookie applies. If unspecified, cookie applies
to URLs that are within or below directory containing current page.
• getSecure/setSecure
– Gets/sets flag indicating whether cookie should apply only to SSL
connections or to all connections.
• getValue/setValue
– Gets/sets value associated with cookie. For new cookies, you supply value
to constructor, not to setValue. For incoming cookie array, you use
getName to find the cookie of interest, then call getValue on the result. If
you set the value of an incoming cookie, you still have to send it back out
with response.addCookie.
Using Cookie Attributes

• public class CookieTest extends HttpServlet {
• for(int i=0; i<3; i++) {
• Cookie cookie =
• new Cookie("Session-Cookie-" + i,
• "Cookie-Value-S" + i);
• // No maxAge (ie maxAge = -1)
• response.addCookie(cookie);
• cookie = new Cookie("Persistent-Cookie-" + i,
• "Cookie-Value-P" + i);
• cookie.setMaxAge(3600);
• response.addCookie(cookie);
• }
Differentiating Session Cookies from Persistent Cookies

Differentiating Session Cookies from Persistent Cookies (Cont)
• … // Start an HTML table
• Cookie[] cookies = request.getCookies();
• if (cookies == null) {
• out.println("<TR><TH COLSPAN=2>No cookies");
• } else {
• Cookie cookie;
• for(int i=0; i<cookies.length; i++) {
• cookie = cookies[i];
• out.println
• ("<TR>n" +
• " <TD>" + cookie.getName() + "n" +
• " <TD>" + cookie.getValue());
• }
• }

• Result of initial visit to CookieTest servlet
– Same result as when visiting the servlet, quitting the browser, waiting an
hour, and revisiting the servlet.

• Result of revisiting CookieTest within an hour of original visit (same browser
session)
– I.e., browser stayed open between the original visit and the visit shown
here

• Implementing session tracking from scratch
• Using basic session tracking
• Understanding the session-tracking API
• Differentiating between server and browser sessions
• Encoding URLs
• Storing immutable objects vs. storing mutable objects
• Tracking user access counts
• Accumulating user purchases
• Implementing a shopping cart
• Building an online store
Agenda

• Idea: associate cookie with data on server
– String sessionID = makeUniqueString();
– HashMap sessionInfo = new HashMap();
– HashMap globalTable = findTableStoringSessions();
– globalTable.put(sessionID, sessionInfo);
– Cookie sessionCookie =
– new Cookie("JSESSIONID", sessionID);
– sessionCookie.setPath("/");
– response.addCookie(sessionCookie);
• Still to be done:
– Extracting cookie that stores session identifier
– Setting appropriate expiration time for cookie
– Associating the hash tables with each request
– Generating the unique session identifiers
Rolling Your Own Session Tracking: Cookies

• Idea
– Client appends some extra data on the end of each URL that identifies the
session
– Server associates that identifier with data it has stored about that session
– E.g., http://host/path/file.html;jsessionid=1234
• Advantage
– Works even if cookies are disabled or unsupported
• Disadvantages
– Must encode all URLs that refer to your own site
– All pages must be dynamically generated
– Fails for bookmarks and links from other sites
Rolling Your Own Session Tracking: URL-Rewriting

• Idea:
– <INPUT TYPE="HIDDEN" NAME="session" VALUE="...">
• Advantage
– Works even if cookies are disabled or unsupported
• Disadvantages
– Lots of tedious processing
– All pages must be the result of form submissions
Rolling Your Own Session Tracking: Hidden Form Fields

• Session objects live on the server
• Sessions automatically associated with client via cookies or URL-rewriting
– Use request.getSession to get session
• Behind the scenes, the system looks at cookie or URL extra info and
sees if it matches the key to some previously stored session object. If
so, it returns that object. If not, it creates a new one, assigns a cookie
or URL info as its key, and returns that new session object.
• Hashtable-like mechanism lets you store arbitrary objects inside session
– setAttribute stores values
– getAttribute retrieves values
Session Tracking in Java

• Access the session object
– Call request.getSession to get HttpSession object
• This is a hashtable associated with the user
• Look up information associated with a session.
– Call getAttribute on the HttpSession object, cast the return value to the
appropriate type, and check whether the result is null.
• Store information in a session.
– Use setAttribute with a key and a value.
• Discard session data.
– Call removeAttribute discards a specific value.
– Call invalidate to discard an entire session.
– Call logout to log the client out of the Web/app server
Session Tracking Basics

• HttpSession session = request.getSession();
• SomeClass value =
• (SomeClass)session.getAttribute("someID");
• if (value == null) {
• value = new SomeClass(...);
• session.setAttribute("someID", value);
• }
• doSomethingWith(value);
– Do not need to call setAttribute again (after modifying value) if the
modified value is the same object. But, if value is immutable, modified
value will be a new object reference, and you must call setAttribute again.
Session Tracking Basics: Sample Code

• Session tracking code:
– No change
• Code that generates hypertext links back to same site:
– Pass URL through response.encodeURL.
• If server is using cookies, this returns URL unchanged
• If server is using URL rewriting, this appends the session info to the
URL
• E.g.:
String url = "order-page.html";
url = response.encodeURL(url);
• Code that does sendRedirect to own site:
– Pass URL through response.encodeRedirectURL
What Changes if Server Uses URL Rewriting?

• getAttribute
– Extracts a previously stored value from a session object. Returns null if no
value is associated with given name.
• setAttribute
– Associates a value with a name. Monitor changes: values implement
HttpSessionBindingListener.
• removeAttribute
– Removes values associated with name.
• getAttributeNames
– Returns names of all attributes in the session.
• getId
– Returns the unique identifier.
HttpSession Methods

• isNew
– Determines if session is new to client (not to page)
• getCreationTime
– Returns time at which session was first created
• getLastAccessedTime
– Returns time at which session was last sent from client
• getMaxInactiveInterval, setMaxInactiveInterval
– Gets or sets the amount of time session should go without access before
being invalidated
• invalidate
– Invalidates current session
• logout
– Invalidates all sessions associated with user
HttpSession Methods (Continued)

• public class ShowSession extends HttpServlet {
• response.setContentType("text/html");
• HttpSession session = request.getSession();
• String heading;
• Integer accessCount =
• (Integer)session.getAttribute("accessCount");
• if (accessCount == null) {
• accessCount = new Integer(0);
• heading = "Welcome, Newcomer";
• } else { heading = "Welcome Back";
• accessCount =
• new Integer(accessCount.intValue() + 1);
• }
• session.setAttribute("accessCount", accessCount);
A Servlet that Shows Per-Client Access Counts

• PrintWriter out = response.getWriter();
• …
• out.println
• (docType +
• "<HTML>n" +
• "<HEAD><TITLE>" + title + "</TITLE></HEAD>n" +
• "<BODY BGCOLOR="#FDF5E6">n" +
• "<CENTER>n" +
• "<H1>" + heading + "</H1>n" +
• "<H2>Information on Your Session:</H2>n" +
• "<TABLE BORDER=1>n" +
• "<TR BGCOLOR="#FFAD00">n" +
• " <TH>Info Type<TH>Valuen" +
• …
• " <TD>Number of Previous Accessesn" +
• " <TD>" + accessCount + "n" +
• "</TABLE>n" +
• "</CENTER></BODY></HTML>");
A Servlet that Shows Per-Client Access Counts (Continued)

A Servlet that Shows Per-Client Access Counts: Result 2

Thank You

Generating the Server Response: HTTP Status Codes

More Related Content

What's hot (20)

Similar to Generating the Server Response: HTTP Status Codes (20)

More from DeeptiJava (13)

Recently uploaded (20)

Generating the Server Response: HTTP Status Codes