Server-side:
Webapps
Parke Godfrey
1 October 2012
CSE-2041
Server-side:
Credits
These slides are based in part on ones from the following sources.
- Prof. Hamzeh Roumani, CSE2041
CGI (Common Gateway Interface)
Is the dynamic Web all CGI?
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.
Server-side Apps
Where to run?
-
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.
-
Webapps
Components
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?
- HTML forms (example)
Method GET
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.
Method POST
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 Headers & Parameters
within a 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_USERfor the client user, if the HTTP session is authenticated,REQUEST_METHODsays the HTTP method call that was used, such asGETorPOST.
-
-
Capturing parameters.
-
For method
GET, found in theQUERY_STRINGenvironment 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.
-
Programming & Debugging Client-Server Apps
Can be quite painful!
-
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.
-
CGI Program debugging techniques
-
“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
FirebuginFirefox— 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
echoCGI. -
(Hard, of course, as you are just getting started.)
-
Saving State
cookies
—
client browser stores them
-
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.
Cookie Syntax
in response
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
Cookie Syntax
in request
Host:
|
hostname;
|
Cookie:
|
name=value;
name=value;
...
;
|
Saving State
other ways?
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?