html servlet flow

Thread view:

Jeff Kish - 16 Jun 2006 02:21 GMT

Hi.

I'm looking at the lessons in:

http://pdf.moreservlets.com/More-Servlets-and-JSP-Chapter-02.pdf

The servlet java class is at the bottom.

There is some html that I can target in my browser that uses the
servlet... the html looks like this:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE>Collecting Three Parameters</TITLE>
</HEAD>
<BODY BGCOLOR="#FDF5E6">
<H1 ALIGN="CENTER">Collecting Three Parameters</H1>
<FORM ACTION="/servlet/moreservlets.ThreeParams">
First Parameter: <INPUT TYPE="TEXT" NAME="param1"><BR>
Second Parameter: <INPUT TYPE="TEXT" NAME="param2"><BR>
Third Parameter: <INPUT TYPE="TEXT" NAME="param3"><BR>
<CENTER><INPUT TYPE="SUBMIT"></CENTER>
</FORM>
</BODY>
</HTML>

my question is.. what exactly is going on internally?
Specifically, I enter in my browser:

http://ThreeParamsForm.html

and I get first a form that allows the user to enter 3 values.

Then when you click on the
submit query button the second form comes up showing the three params
and their values.

It appears to me that when I enter the ThreeParamsForm.html in the
browser, Tomcat says, ok..load the page ThreeParamsForm.html and send
it to the browser.

I assume it is the browser which process the html page, and I guess it
reads all the html, and associates the clicking of the button or
hitting of the return key with invoking the servlet (that is what
input_type="submit" gets you, right?)

Then the act of hitting enter or clicking on the submit button causes
the Tomcat to put the param1,param2,param3 values in session level
data (I guess?) and does a 'get', causing the doget method to be
invoked, which has access to the (session?) level param1,2,3
variables.

Is this correct, or am I missing something?.
Are these session level variables, or something else?
If they are session level, then if there was another submit button
with yet another servlet, would that servlet have access to the same
data?

thanks

bottom

package moreservlets;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
/** Simple servlet that reads three parameters from the
* form data.
*/
public class ThreeParams extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String title = "Reading Three Request Parameters";
out.println(ServletUtilities.headWithTitle(title) +
"<BODY BGCOLOR=\"#FDF5E6\">\n" +
"<H1 ALIGN=\"CENTER\">" + title + "</H1>\n" +
"<UL>\n" +
" <LI><B>param1</B>: "
+ request.getParameter("param1") + "\n" +
" <LI><B>param2</B>: "
+ request.getParameter("param2") + "\n" +
" <LI><B>param3</B>: "
+ request.getParameter("param3") + "\n" +
"</UL>\n" +
"</BODY></HTML>");
}
}

Reply to this Message

Jeff Kish - 16 Jun 2006 02:48 GMT

>Hi.
>
>I'm looking at the lessons in:
>
>http://pdf.moreservlets.com/More-Servlets-and-JSP-Chapter-02.pdf

<snip>

>my question is.. what exactly is going on internally?
>Specifically, I enter in my browser:
>
>http://ThreeParamsForm.html

<snip>

>Then the act of hitting enter or clicking on the submit button causes
>the Tomcat to put the param1,param2,param3 values in session level
[quoted text clipped - 7 lines]
>with yet another servlet, would that servlet have access to the same
>data?

<snip>

Sorry for the bandwidth waste, I just figured out the params are from
the URL.

I'm still trying to get my head around what is going on between the
browser and Tomcat.

Still appreciate any elucidation, still studying.

Thanks

Reply to this Message

Oliver Wong - 16 Jun 2006 17:47 GMT

> I'm still trying to get my head around what is going on between the
> browser and Tomcat.
>
> Still appreciate any elucidation, still studying.

The browser submits an HTTP request, and the server sends an HTTP
response. That response usually contains HTML, but it could respond with
anything (including images, flash animations, PDFs, etc.)

The server is free to send back any content it wants, and the browser is
free to submit any HTTP request it wants.

When writing websites, you have to provide enough information in your
responses so that the user can accomplish whatever tasks it is they want
done. You also have to take into account the fact that users are free to
send any request they want, and so you have to be able to handle
non-sensical requests and not assume requests will arrive in any particular
order or anything like that.

- Oliver

Reply to this Message

Jeff Kish - 17 Jun 2006 03:42 GMT

>> I'm still trying to get my head around what is going on between the
>> browser and Tomcat.
[quoted text clipped - 16 lines]
>
> - Oliver

Thanks Oliver.

Is this right?

Say there is a hard coded jsp page, say:
mypage.jsp in the right dir under tomcat,
if the user types in the browswer address bar:
http://tomcat/jmypage.jsp

and presses return, then...

Then the browser packs up the 'mypage.jsp' and
formats it in the protocol of http, and send it to
the address (tomcat here).

Then tomcat recognizes the protocol, unpacks the
request, and sees "mypage.jsp".
Then it looks wherever it is legal for jsp pages to exist,
and starts processing the mypage.jsp?

If it is a simple page, it packs up the code/html in the jsp page into
the response and puts it in http format and sends it to the browser.

When the browser gets the response, it recognizes it is http, unpacks
it, and starts processing the html in the response.

And this 'response' isn't the response parameter in the doGet method,
it is just the general 'response' from the Tomcat.

Extra informatoin like headers etc are in the actual doget 'response'
variable.

Is this at all correct?

Thanks again

Reply to this Message

Mark Space - 18 Jun 2006 07:59 GMT

Well, I don't think of myself as an expert or anything, but I'll give
this a shot.

> Is this right?
>
> Say there is a hard coded jsp page, say:

What is "hard coded" jsp??? :(

> Then the browser packs up the 'mypage.jsp' and
> formats it in the protocol of http, and send it to
> the address (tomcat here).

Sorta, but I don't like the "packs up" and calling tomcat an address.
There some magic happening with DNS in there too, although most of that
is done by your OS.

> Then tomcat recognizes the protocol, unpacks the
> request, and sees "mypage.jsp".
> Then it looks wherever it is legal for jsp pages to exist,
> and starts processing the mypage.jsp?

Sorta again, but tomcat doesn't really recognize the protocol. That's
done by the OS, usually a deamon, which sends the packet(s) to Tomcat
(or whoever is listening on the port). Of course, if you just send
random bytes to tomcat on port 80, it'll probably not give you anything
back.

> If it is a simple page, it packs up the code/html in the jsp page into
> the response and puts it in http format and sends it to the browser.

Not really. JSP are code, and executed. They are never simple pages.
A plain text file is pretty much sent as-is. I can't remember now how
much the HTTP response header has, but it's pretty minimal for basic
response. It's possible no headers at all are sent for plain text, for
example.

The request headers can be very simple too. I think I once tested a
balky connection by typing "telnet cnn.com 80" on the command line.
When I got a prompt, I typed GET and closed the input channel. I got a
html page from the cnn.com server back before it closed the channel on
it's side.

IE, I sent no headers at all.

> When the browser gets the response, it recognizes it is http, unpacks
> it, and starts processing the html in the response.

Yes, by the time the browser sees the response, it's all just plain text
or plain HTML or just a wvm movie or something (with a small HTTP header
attached in the case of the latter 3).

> And this 'response' isn't the response parameter in the doGet method,
> it is just the general 'response' from the Tomcat.

No, the response is EXACTLY the response parameter of the doGet method.
That is EXACTLY what you are constructing; it is exactly the response
the browser will see. Stuff the string "Hello World" into the response
object and that what the browser will receive (and display). Put random
binary bytes in the response and the browser will display computer
gibberish.

> Extra informatoin like headers etc are in the actual doget 'response'
> variable.

Yes, headers are in the response as well. You need to control the
header so the browswer will know what it is getting. But mostly you
just set the mime-type, most other header parameters are set-up for you.

You really should do a google search for "http tutorial" or similar, I
think it'll help you quite a bit.

Reply to this Message

Oliver Wong - 19 Jun 2006 15:13 GMT

> Is this right?

The general gist of it looks right. As for the details, I'm not sure.
I've never actually done JSP programming, nor used Tomcat.

> Say there is a hard coded jsp page, say:
> mypage.jsp in the right dir under tomcat,
[quoted text clipped - 6 lines]
> formats it in the protocol of http, and send it to
> the address (tomcat here).

Probably browser sends '/jmypage.jsp'. The 'j' is probably a typo, but
the slash is important. A browsers' request is always an absolute path,
AFAIK.

> Then tomcat recognizes the protocol, unpacks the
> request, and sees "mypage.jsp".
> Then it looks wherever it is legal for jsp pages to exist,
> and starts processing the mypage.jsp?

This is *probably* what Tomcat does, but webservers are free to not
actually look for a physical file, but instead generate a response in some
other fashion. Imagine for example, that the browser requests for the url
'/random', and the webserver recognizes this as a special address which
doesn't actually point to a file, but instead indicates that the server
should generate a random 32-bit integer and send its decimal string
representation as a response. None of this would be violating the HTTP
protocol AFAIK.

Most webservers simply look for files matching the provided name, as
you've said though.

> If it is a simple page, it packs up the code/html in the jsp page into
> the response and puts it in http format and sends it to the browser.

Right, but a minor terminology nitpick here: HTTP is not a format, but a
protocol. Traditionally, no transformation is done to the data. The server
sends a message to the browser, whose header says "This is an text/html
file. It's length is 320 bytes." and then immediate starts sending the data
as-is.

More recent servers might negotiate compression schemes. I'm not sure
exactly how it works, but I imagine it's something like when the browser
requests the page, it'll say "GET me /mypage.jsp. Oh and by the way, if you
can gzip it, that'll be lovely." And the server will generate the response
(perhaps by reading the %WEBROOT%/mypage.jsp file), and if it knows how,
it'll gzip it. If it doesn't know how, it just sends the content as is.

> When the browser gets the response, it recognizes it is http, unpacks
> it, and starts processing the html in the response.

The browser doesn't have to do any recongition at this point. It all
happens under one connection. At the IP level, the browser connects to the
server, and does its GET request. The server processes this, sends back its
response, and closes the connection.

> And this 'response' isn't the response parameter in the doGet method,
> it is just the general 'response' from the Tomcat.
>
> Extra informatoin like headers etc are in the actual doget 'response'
> variable.

I didn't understand these last two parts. They sound JSP/Tomcat
specific.

- Oliver

Reply to this Message

Juha Laiho - 18 Jun 2006 10:12 GMT

Jeff Kish <kishjjrjj@charter.net> said:

>Hi.
>
>I'm looking at the lessons in:
>
>http://pdf.moreservlets.com/More-Servlets-and-JSP-Chapter-02.pdf

[...]

Hello,

looks like you need to take a couple of steps back, and get an understanding
of the very basics of the web; that is HTML and HTTP.

Then the next step is to map this knowledge to how servlet containers and
servlets work.

After this, it could be good to look at client-side programming (Javascript,
mostly), to get an idea of what can be done on client-side.

This, combined with understanding of how HTML is rendered to visible pages
on the browser (starting with how the document is structured, and continuing
on how to control the rendering with CSS), brings understanding of what
can be achieved with AJAX (which is currently considered somewhat
state-of-the-art way to build web-based user interfaces).

HTML is the main content for a web page; it brings the structure and text
content of the page. Unfortunately HTML in practice also often contains
visual markup definition, even though it should be limited to just structural
markup. CSS should be used for the visual side.

HTTP is the protocol used to transport requests from the client (browser)
to the server, and responses back to the client. The main protocol level
commands for HTTP are GET and POST (others exist, but they are for other
uses than plain browsing).

HTML forms are pretty well desribed here:
http://www.w3schools.com/html/html_forms.asp
http://www.w3schools.com/tags/tag_form.asp

... and to see what goes on between browser and server, I recommend using
Firefox browser with the TamperData extension; it's a real delight.
Firefox also provides some extensions to edit CSS in real time for the
document being displayed, which helps in understanding various details
in CSS.

Regarding servlets, once you understand the browser-server -interaction
model, the Servlet Specification should be good reading:
http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html

Signature

Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Reply to this Message

Jeff Kish - 03 Jul 2006 04:05 GMT

<snip>

>... and to see what goes on between browser and server, I recommend using
>Firefox browser with the TamperData extension; it's a real delight.
[quoted text clipped - 5 lines]
>model, the Servlet Specification should be good reading:
>http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html

Thanks.
I'm trying to figure out how to install the tamperdata.
I'm reading some books.
I appreciate the time you took to reply.

Reply to this Message

html servlet flow

Free Magazines