You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Steve McCarthy <sj...@teamon.com> on 2002/05/09 20:55:38 UTC
Prove me wrong - take this quiz
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Prove me wrong - take this quiz
Posted by Bojan Smojver <bo...@binarix.com>.
On Fri, 2002-05-10 at 04:55, Steve McCarthy wrote:
> I have been frustrated in multiple attempts to report this very glaring bug
Gee, I would have never guessed that one ;-)
Bojan
PS. Sorry, had to have some fun...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem with Servlet and Graphics
Posted by Jun Inamori <ju...@oop-reserch.com>.
Hi,
On Jun04, 2002 12:09 -0400, Desarrollo e Investigacin wrote:
>
> I've been worked with Servlet and i tried to generate
> a JPG image but Tomcat Displays this error:
>
> java.lang.InternalError: Can't connect to X11 window
> server using ':0' as the value of the DISPLAY variable.
> at
> sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
................
> I use the Tomcat 4.0.4-b3, Java 1.4.0, Linux Red Hat 7.2
Because you are using JDK 1.4, please try:
-Djava.awt.headless=true
option in your start-up script.
For details, please read:
http://java.sun.com/products/java-media/2D/forDevelopers/java2dfaq.html#xvfb
Happy Java programming!
----------------------------------
Jun Inamori
OOP-Reserch
E-mail: jun@oop-reserch.com
URL: http://www.oop-reserch.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Problem with Servlet and Graphics
Posted by Desarrollo e Investigación <de...@catenaria.cl>.
I've been worked with Servlet and i tried to generate a JPG image but
Tomcat Displays this error:
java.lang.InternalError: Can't connect to X11 window server using ':0' as the
value of the DISPLAY variable. at
sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) at
sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:126)
I use the Tomcat 4.0.4-b3, Java 1.4.0, Linux Red Hat 7.2
DesInv (Desarrollo e Investigación, Catenaria)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Prove me wrong - take this quiz
Posted by Pier Fumagalli <pi...@betaversion.org>.
"jean-frederic clere" <jf...@fujitsu-siemens.com> wrote:
>> 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?
IMO, we should fix tomcat and report a bug against watchdog...
BTW, let's try to quote only the relevant part of messages...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Prove me wrong - take this quiz
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Pier Fumagalli wrote:
> "Steve McCarthy" <sj...@teamon.com> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Prove me wrong - take this quiz
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Steve McCarthy" <sj...@teamon.com> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>