Interactive Services

Interactive Services Dr C. P. Jobling (C.P.Jobling@Swansea.ac.uk)

Acknowledgements • Inspiration for CGI introduction “Head First Servlets and JSP”, Basham, Sierra and Bates, O’Reilly, 2004. • Other examples: • HTML for the World-Wide Web, Elizabeth Castro, 5th Edition, Peachpit Press, 2003. CGI and PHP script example. • Basham et al. Beer tasting example.

Basic Web Server Operation Interactive Services Server-side Scripting in PHP Application Frameworks RESTful Web Services Part 3: Server-Side Programming

Last Lecture • Basic Web Server Operation • HTTP Request and Response Messages • Web server operation • Mapping resources to files • Apache configuration lab

This Lecture • The need to serve more than static pages … a conversation • Dynamic content • CGI Operation • More on the HTTP request • CGI Technologies

A static page sits in a directory The server finds it and hands it back to the client. Every client sees the same thing. <html> <html> <html> files files server “Web servers serve static web pages” Ask me for a page, I find it and hand it back. With a few headers. But that’s it. Do NOT ask me to do anything to the page.

“I need more than a web server…” But I want the current time to show up in my page? What if I want a page that has something dynamic? Can I have something like a variable in my HTML? <html><body>The current time is [insertTimeOnServer]</body> </html>

another application on the server Web serverapplication “I need a helper application…” I can handle that date thing for you. server I’m a web server application. I SERVE things. I don’t do computation on the things I serve. But I know an application that does.

“How does that help?” My clients are all web clients. The browser knows only about the web server … so it won’t be able to call that other application

another application on the server Web serverapplication “The server acts as go between” server That’s not a problem. I’ll take care of getting the request to the right helper application. I’ll take that application’s response and send it back to the client. In fact the client never needs to know that someone else did the work.

Two things a web server alone won’t do • If you need Just-in time pages • Pages that don’t exist before the request • Or need to write/save data on the server • Writing data to a file or a database • You can’t rely on a web server alone!

The web server serves only static web pages. The web server can communicate with an helper application which can build non-static just-in-time pages. A dynamic page can be anything from a catalogue to a weblog! Instead of… You want… <html><body>The current time is always4.20 pm on the server.</body> </html> <html><body>The current time is [insertTimeOnServer].</body> </html> Just-in-Time Pages

Handling Data • When the user submits data in a form the web server sees the form data. • It cannot do anything with the data. • To process the form data, to save it to a file or database or even just to use it to generate a response page, the web server needs to call a helper application. • The web server assumes that all the form data is for the helper application. • It simply passes all the data to the helper application and provides a way for the helper application to generate a response for the client.

Handling Data • When the user submits data in a form the web server sees the form data. • It cannot do anything with the data. • To process the form data, to save it to a file or database or even just to use it to generate a response page, the web server needs to call a helper application. • The web server assumes that all the form data is for the helper application. • It simply passes all the data to the helper application and provides a way for the helper application to generate a response for the client. Just in time pages don’t exist before the request arrives. It’s like making a web page out of thin air. The request comes in, the helper application “writes” the HTML, and the web server gives it back to the client..

The Helper Application • The name of a web server helper application is CGI program • CGI stands for “Common Gateway Interface” • It’s the standard mechanism for a web server to pass browser data to a helper application and return the results • CGI protocols are used for all server-side data processing, no matter how it is done. • Data from client has to be sent in the HTTP request. • Processed results have to returned in the HTTP response.

browser user CGI Operation Web server machine request Web serverapplication • User clicks on a link that has a URL to a CGI program instead of astatic page. • Parameters added to HTTP request • HTTP request delivered to server (see previous lecture)

browser Helperapplication user params CGI Operation Web server machine request Web serverapplication • Web server application “sees” that request is for a helper program. • It launches and runs the program • It sends the parameters from the GET or POST request to the helper application.

browser Helperapplication user params CGI Operation Web server machine <html><head></head><body>:</body> </head> Web serverapplication • The helper application constructs new web page (with current date) • Sends the HTML back to the server

browser Helperapplication user CGI Operation HTTP header info Web server machine <html><head></head><body>:</body> </head> Web serverapplication • The helper application is shut down • The client gets back an HTML page that has the current date as part of its now static content

More on the HTTP Request • An example interactive page

The form (client user interface) The parameters: colour and taste The HTML

The HTTP request type The host The helper application resource parameters GET /cgi-bin/echo_params.cgi?colour=dark&taste=malty HTTP/1.1Host: localhost: The GET request Request: Data sent in GET • <form method = “get”action=“http://localhost/cgi-bin/echo_params.cgi”>… </form> Execute GET request: http://localhost/beer_get.html

Result of GET request

resource POST /cgi-bin/echo_params.cgi HTTP/1.1Host: localhost: Connection: keep-alive colour=dark&taste=malty the parameters (in payload) The POST request Request: Data sent in POST • <form method = “post”action=“http://localhost/cgi-bin/echo_params.cgi”>… </form> Execute POST request: http://localhost/beer_post.html

Result of POST request

Web Developer’s Tools • Firefox extension Live HTTP Headers allows you to examine the GET and POST request and response headers

GET or POST? • GET • Server limits size of parameter data it will accept • Parameters will appear in browser’s URL window when request is successful • May be good for book marking results of a search, etc. • Not good for security applications (e.g. login data)

GET or POST? • POST • Parameter data is carried in request payload … size essentially unlimited • Data values hidden … do not appear in URL of successful response • Essential for security applications, e.g. login or exchange of credit card information. • Data must be resubmitted … cannot simply bookmark a URL for a POST request, must load form page and resubmit data.

GET or POST? • Apart from limitation on size of a GET request, it actually makes very little difference which request type is used to pass data to server!

What about encryption? • SSL uses tunnelling so head and body of an HTTP message can be encrypted • Packed into a new IP packet • Sent using SSL (using https protocol) so transport secure. • Original data is unpacked on receipt

Limitations on Parameters • Data from a web browser can only be in form of name=value pairs • Always passed as strings • Additional helper application processing required to convert strings to numbers, dates, etc. • May be formatting errors which would require additional request to notify user (in response) and allow corrected request! • Validation required

Limitations on Parameters • Special processing needed to convert multiple values into collection-like data • Data passed to server as duplicate named parameterssamename=value1&samename=value2&samename=value3 • needs to be converted to samename = [value1, value2 value3]by helper application

Limitations on Response • Server application has to return something that the client can render • Usually HTML but other formats possible • Images for graphical data • PDF files, etc. • Only possible client user interface is the HTML form • quite limited when compared to desktop application user interface components (see Ajax lecture)

Other Issues • Complex data-flows needed to build a web application • Application is a sequence of forms and acknowledgement pages • Need to handle session state (server recognizes client and continues conversation where it left off). Tricky for a stateless protocol! • How to do error handling?

Other Issues • Can be inefficient • TCP connection doesn’t stay open for conversation • Has to be re-opened for each exchange. • 2 RTT delay overhead for each request and response in a complex scenario • Can be reduced if you are prepared to use Ajax for partial page renewal

CGI Technologies • Server Side Includes (SSI) • Separate process CGI • In-process CGI

Server-Side Includes (SSI) • Simple CGI technology • Effectively a way to embed data into a web page Local time is  • Server replaces special comments with results of computation • Most often used to build complex web pages from templates <body>:</body>

Server-Side Includes (SSI) • Enabled with a simple Apache directive AddType text/html .shtmlAddOutputFilter INCLUDES .shtml • Apache XSSI (extended SSI) provides some limited conditional execution • Limited access to request parameters so really a just-in-time page generation tool.

CGI Technologies • Server Side Includes (SSI) • Separate process CGI • In-process CGI

Separate process CGI • Separate helper application program processes request parameters and returns response • External program loaded by web server • Request header and parameters passed to program using environment variables

Separate process CGI • Response written to “standard output” • Helper application must construct a valid HTTP response • Adds content-type field and data • Helper application shutdown • If returned response is valid, returned to client • Problems arise if response is malformed (difficult to debug!)

CGI Programming Tools • CGI programs can be written in any language … • … but scripting language Perl has become the standard • CGI.pm (a library) is used to simplify the handling of the request parameters and the construction of the response.

An Example Perl CGI Script Execute script: http://localhost/beer_get.html http://localhost/beer_post.html

Adding a CGI Program to a Webserver • A special directory, by convention called cgi-bin, is provided • A server directive makes the directory a script folder (all contents assumed to be scripts) • Script placed in the script folder • Scripts must be executable by the web server. • Script resource has URI /cgi-bin/script.pl • Note: it is also possible to recognise a script by extension (.cgi is common) • Must be executable • Resource URI would then be /afolder/myscript.cgi

Interactive Services