Server-side:
Webapps
Parke Godfrey
1 October 2012
CSE-2041
Parke Godfrey
1 October 2012
CSE-2041
These slides are based in part on ones from the following sources.
CGI as protocol — part of the HTTP protocol
Yes.
CGI as app (program) — called by the Web server
No.
Can be handled many ways now.
Is abstracted in many “Web” programming stacks.
E.g., .Net, Java Beans, Tomcat, ...
We will focus on the “simple” case of CGI programs in LAMP.
Just on the Web server itself.
Child server that handles the HTTP client request
“becomes” the app.
No validation!
Child server “forks” the app.
Can validate.
Multi-tier: Run a separate App Server.
Child Web server uses the app service.
Usually validates.
This multi-tier approach is analogous to the database service.
Client does not see the app server directly.
Server-side
Need to capture the “input” from the client.
HTTP headers and parameters
Two methods to pass parameters:
GET
POST
Client-side
How to generate the “output” to go to the server?
GET sends the parameters as part of the URL, URL encoded.
Some issues with GET are
poor UI,
exposed (no confidentiality),
search engines do not index dynamic-looking URL’s, and
limit on URL length.
A good point is that the URL — with the parameters in place — is bookmark-able.
Good for simple, “idempotent” applications.
Parameters are passed as payload — in the request, from client to server.
no practicial length limit
confidentiality
search engines will index the URL
For CGI programs / webapps:
parameters are passed from the web server to the CGI program as its standard input; and
the web server sets other information about the HTTP session and from the request headers as environment variables for potential use by the CGI program.
Capturing the request headers.
Found in the environment
prefixed by HTTP_
Capturing other session information.
Also found in the environment under various names. E.g.,
REMOTE_USER
for the client user,
if the HTTP session is authenticated,
REQUEST_METHOD
says the HTTP method call that was used,
such as GET
or POST
.
Capturing parameters.
For method GET
,
found in the QUERY_STRING
environment variable.
For method POST
,
found on the standard input.
Parsing the parameters.
Use &
and =
as delimiters,
and tokenize.
URL encoding.
Why is it done, and how to undo it.
Two (at least!) systems involved.
Standard debugging methods often are not available.
Errors can arise from many different places.
server-side
from the CGI program
from the server itself
client-side
in the use of protocols (protocol errors)
network malfunctions and other factors
As such, debugging webapps can be much more difficult that for stand-alone programs.
“server-side”
Mock the input to the CGI program from the command line.
client-side
Look closely at what the client gets; e.g., view the source.
protocols
Use Firebug
in Firefox
—
and tools like it
—
to see what is being passed back and forth.
other tools
Build and collect little tools to help.
E.g., an echo
CGI.
(Hard, of course, as you are just getting started.)
Part of HTTP.
Passed as a header.
request (from client):
(one instance of)
header called Cookie:
.
Returns as the value all the “cookies” set previously for that server domain, and (optionally) for that path.
response (from server):
(potentially multiple instances of)
header called Set-Cookie:
.
Specifies “cookies” the server / webapp wants the client to keep.
These will be delivered back on subsequent visits.
Problems with cookies (from a webapp point of view)?
Cookie policy set by the browser. It might remove them.
Different people can share the same browser.
Not shared across browsers on the same machine.
Set-Cookie:
|
name=value ;
|
expires=wd, d-m-y h:m:s TZ;
|
|
path=prefix of current URL;
|
|
domain=.xxx.xxx;
|
|
secure
|
|
Content-Type:
|
mime
|
optional
Host:
|
hostname ;
|
Cookie:
|
name=value;
name=value;
...
;
|
Why not just use hidden fields in the “page” that the server delivers?
This is good for “intra-session”.
Cookies are good also for “inter-session”.
Other ways of saving state?