"Steve McCarthy" <[EMAIL PROTECTED]> wrote:
> 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).
Kewl, let's do this...
> 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
Hmm... A!
> Question 2
>
> What 2xx status codes are defined by RFC 2616?
> A. 200 - 206
Hmm... A
> 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.
Hmm... A
> 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.
Hmm... A
> 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.
Hmm... A
> 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.
Hmm... A
> 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.
Hmm... A
> 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
Hmm... A
> Question 2
> What should the client see in the message body?
> A. The string "an-Cay ou-yay ead-ray is-thay?"
Hmm... A
> 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?"
Hmm... A
> 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?"
Hmm... A
> 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.
DOOH! So, I figured... Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A.
Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A.
> 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.
Hmm... A. Ehgeehehehmmm... Sorry... No, yes, indeed, I followed a little bit
the stuff on 8831, that has been closed _4_ times, and goddamit, you're
absolutely right, and 8916 has been closes _3_ times... Making it 7 times
when a bug was closed for (FWICS) no good reason...
> 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.
Yes you are... But you're not the only one to think that Tomcat's HTTP
behavior is less than compliant to the spec in more than one critical aspect
(the last one was pointed out today by JF, for example)
> <plea> Hoping for some help from committers who can see this behavior is
> wrong and needs to be changed.</plea>
I agree that a patch must be provided and something shall be done to address
an utterly irresponsible and mischievous behavior of ErrorReportValve.
> I can submit a patch if anyone is interested.
That would be appropriate...
> (Ref: bugs 8831 and 8916.)
I've seen the pain...
> Thanks for reading this far,
Was a pleasure... Next time I have to complain on how the "Host:" HTTP/1.1
header I'll write down my own 20 questions...
Pier
--
I think that it's extremely foolish to name a server after the current U.S.
President. B.W. Fitzpatrick
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
