Download Exploring Server-Side Programming: CGI, APIs, and Web Frameworks and more Summaries Architecture in PDF only on Docsity!

Server-Side

Web Programming Intro

To make a Web server based program

• You have to get data in (from user-agent to server)
• Then process the data, perform some task, etc.
• You have get data out (from server to user-agent)
  • Input:
    data, URLs, HTTP headers (browser type, IP, cookie, etc.)
  • Output: Some form of data usually HTTP, GIF, JPEG, etc. and the appropriate header (MIME type ,cookie, etc.)
• You will need to fix the stateless nature of HTTP to do anything meaningful - Sessionization via cookies, URLs, hidden fields, etc.
• You should provide features to make programming easy not only do the previous things simply but allow for access to DBs, output HTML and Web site widgets, etc.

Redux - 3 Server-Side Programming Models

• Revisit this again because it is that important –

there are just 3 models at play here really

• #1) Classic CGI model – fork and exec
  • Web server creates new child process, passing it request data as environment variables
  • CGI script issues response using standard I/O stream mechanisms
• #2) Server API model
  • Web server runs additional request handling code inside its own process space
• #3) Web application frameworks
  • Web server calls API application, which may manage request within its own pool of resources and using its native objects

3 Server-Side Programming Models Redux Classic CGI “ fork and exec ” Server API running inside Web server ’ s address space Web application framework running inside Web server process but managing its own pool of resources via IPC

3 Server-Side Programming Models

• Many examples of each
  • Classic CGI
    • Scripts written in Perl
    • Programs written in C
  • Server API
    • Apache modules
    • ISAPI filters and extensions
  • Web application frameworks
    • All descended from Server Side Includes (SSI), original parsed HTML solution that allowed interspersing of executable code with markup
    • ASP, ASP.NET, Cold Fusion, JSP/Servlets, Python, PHP, etc.

Theoretical Trade-offs

• As we saw there are many approaches to accomplishing

Web programming

• No one approach works for all situations
• Speed of ISAPI vs. simplicity of a PHP script
• Some show you low-level details like headers, query strings, etc. very explicitly and some do not
• Some are harder to work with than other
• Trade-off: Configurability vs. Simplicity
• We also see that some higher level frameworks will trade-off ease of programmer effort for overhead and thus speed or scale
• Portability or reliance to a particular platform is also seen
• We start with low level old style CGI to see the

underlying sameness of all server-side Web coding

CGI (Common Gateway Interface)

• Simple standard defining the way for external programs

to be run on Web servers

• In short CGI defines the way that data is read in by

external programs and what is expected to be returned

• Hamburger model
• Useful CGI related resources
• http://www.cgi-resources.com
• http://www.w3.org/CGI/
• O Reilly s CGI Book - http://www.oreilly.com/catalog/cgi2/

CGI and Perl

• CGI is often mentioned in the same breath as

Perl, this is somewhat misleading

• CGI does not specify the usage of a particular

language. If this is the case why Perl?

• Perl was commonly found on UNIX machines which

were the first Web servers

• Perl is very good at string manipulation which is

one of the main tasks when writing a CGI program

• Perl is pretty easy to hack around with
• Of course as an interpretted language you can see

Perl partial to blame for CGI s speed problems

• Soluion: Use mod_perl
• Best Solution: Recompile as a C program

First Example in C

• As said before language is irrelevant in CGI, so we recode helloworld in C as a demo #include <stdio.h> main() { printf("Content-type: text/html \n\n"); printf(""); printf("

  Hello World!

  "); printf(""); }

Don t Reinvent the Wheel

• There isn t much to do in CGI
  • Main tasks read in user submitted data and write out

HTML and headers

• The real programming is outside of this!
• Plenty of room to screw-up
• Assuming that what is sent in is correct or safe
• Not handling error conditions or exposing sensitive

mechanisms.

• Rather than reinventing the wheel you could utilize a

CGI library such as Lincoln Stein s CGI.pm module for

Perl http://search.cpan.org/dist/CGI.pm/

Environment Variables

• These variables correspond to HTTP headers submitted to the running program: - HTTP_ACCEPT, HTTP_USER_AGENT, HTTP_REFERER REMOTE_HOST, REMOTE_ADDR
• Submitted data
  • QUERY_STRING, CONTENT_TYPE, CONTENT_LENGTH, REQUEST_METHOD
• Server or program related data
  • SERVER_NAME, SERVER_SOFTWARE, SERVER_PROTOCOL, SERVER_PORT, DOCUMENT_ROOT, SCRIPT_NAME
• There may be numerous others depending on the server in play.
• In the case of Perl, environment variables are stored in a hash named %ENV so we can easily access or print them as shown in the next example

Environment Variables Example without CGI.pm

#!/usr/bin/perl

print HTTP response header(s)

print "Content-type: text/html \n\n";

print HTML file top

print <<END;

Environment Variables

---

END # Loop over the environment variables foreach $variable (sort keys %ENV) { print "$variable: $ENV{$variable}
\n"; } # Print the HTML file bottom print < END

Back to the URL

http://www.xyz.com/catalog.asp?dept=gadgets&product=

Hostname Resource Query

String

Protocol

HTML Forms

HTTP GET

HTTP POST