Hi, Developers and Developer-ettes!

It is time for a fun quiz to test your knowledge of HTTP, Servlets, and
servlet behavior.  See if you can get them all right!  As a bonus, see if
you can guess how Tomcat handles these situations (as of 5/8/2002).

Section 1  - HTTP
-----------------
Question 1

    HTTP 1.1 specification RFC 2616 defines 5 classes of status codes: 1xx,
    2xx, 3xx, 4xx, and 5xx.

    What do the 2xx codes signify?
       A.  Successful
       B.  Redirection
       C.  Client Error
       D.  Server Error
       E.  Successful only if the status code is 200 or 204, otherwise the
           server is free to change the Content-type and the message body.

Question 2

    What 2xx status codes are defined by RFC 2616?
       A. 200 - 206
       B. several, but only look for 200 and 204.

Question 3

    If an HTTP application returns a 2xx code that is beyond the range of 2xx
    status codes, say 299, is it an error?
       A.  No, it is by definition a success.
       B.  Only 200 and 204 and really successful, other 2xx are errors.


Section 2 - Servlet Container behavior
--------------------------------------
    A servlet wants to write to the client.  It sets the status code to 
    299.  It obtains a PrintWriter from the servlet container and writes to
    it.

Question 1
    Does servlet specification require you to call flush() to ensure that
    the client actually see the bytes?
       A. No, spec does not mandate this behavior for webapps.
       B. "you have to flush your writer. Otherwise, because of timing
           problems, the bytes will not get written" (bug 8916)

Question 2
    Where in servlet spec (or RFC 2616, your choice) does it allow
    the container to replace the message body or content-type header  for an
    application that has set the status code to 2xx?
       A.  It doesn't.  It shouldn't.  That would be clearly wrong.
       B.  200's and 204's are left alone, all other 2xx status codes are
           fair game to have their headers and body replaced.

Question 3
    The servlet spec allows you to write to the output by either obtaining a
    Writer or an OutputStream from the container, but not both.

    Should servlet container behave differently if application writes to
    OutputStream instead of Writer?
       A.  No.  Behavior should be consistent.
       B.  If application returns 2xx other than 200 or 204, and it called
           getWriter(), then the response will be replaced, unless it has
           been committed via flush(), or if the application called
           getOutputStream().

Question 4
    When is it ever acceptable to replace the content-type and message body
    when servlet is returning a 2xx status code?
       A.  As a practical matter, it should never change the headers or body
               for any code less than 400.
       B.  Only for status codes in the range 200-206 for which the RFC
               allows it (I didn't see any), and leave others alone.
       C.  200's and 204's work for me, everything else is fair game for
               silent replacement.


Section 3 - Guess the output
----------------------------
The following code samples are assumed to be in a servlet's service()
method.

    Sample Code 1
    -------------
    response.setStatus(299);
    response.setContentType("application/x-pig-latin");
    response.getWriter().println("an-Cay ou-yay ead-ray is-thay?");

Question 1
    What should the client see in the Content-type header?
       A.  application/x-pig-latin
       B.  text/html
       C.  text/html, and by the way "that's invalid" 
       D.  text/html, "that's invalid",  and "If you don't like it, you can
               disable it [or] write an alternate"

Question 2
    What should the client see in the message body?
       A. The string "an-Cay ou-yay ead-ray is-thay?"
       B. Nicely stylized Tomcat error page.

    Sample Code 2
    -------------
    response.setStatus(299);
    response.setContentType("application/x-pig-latin");
    Writer w = response.getWriter();
    w.println("an-Cay ou-yay ead-ray is-thay?");
    w.flush();


Question 3
    What should the client see in the message body?
       A. The string "an-Cay ou-yay ead-ray is-thay?"
       B. The string "an-Cay ou-yay ead-ray is-thay?", but only because the
           response has been committed and the container's attempt to
           overwrite it failed.

    Sample Code 3
    -------------
    response.setStatus(299);
    response.setContentType("application/x-pig-latin");
    response.getOutputStream().write("an-Cay ou-yay ead-ray is-thay?".getBytes());

Question 4
    What should the client see in the message body?
       A. The string "an-Cay ou-yay ead-ray is-thay?"
       B. The string "an-Cay ou-yay ead-ray is-thay?", but only because the
           application called getOutputSteam(), and the container's attempt
           to overwrite it failed when it called getWriter().

ANSWERS:
--------
Of course, these are loaded questions. :)  "A" is the correct answer to all
of the questions, and the last choice for each question describes current
Tomcat behavior.

I have been frustrated in multiple attempts to report this very glaring bug,
because the reviewer chooses to close the bugs, dismissing them out-of-hand
as "invalid" without addressing a single fact, without being able to muster
a technical argument to where I might be mistaken.

I am pretty sure that I am solid on the specs, and would welcome
technical feedback, backed by relevent spec or RFC, to the contrary.

<plea> Hoping for some help from committers who can see this behavior is
wrong and needs to be changed.</plea>

I can submit a patch if anyone is interested.

    (Ref: bugs 8831 and 8916.)

Thanks for reading this far,

Steve McCarthy




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to