Pier Fumagalli wrote:
> "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)
Yep... Fixing TC breaks the watchdog test.
I should I fix TC and report a bug against watchdog?
>
>
>><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]>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
