Transcript PPT - University of Victoria

Alternative Content
Distribution Methods
Non-CGI/SSI Content Serving
©2006
Scott Miller, University of Victoria
1
4/4/2016
CGI, SSI Building Blocks

All alternative content serving methods use
principles of CGI and SSI
PHP
Fast
CGI
CGI
SSI
Cold
Fusion
JSP
ISAPI/
NSAPI
©2006
ASP
Servlets
ASP.Net
C#
Scott Miller, University of Victoria
2
4/4/2016
Alternatives - #1

Give programmers an API to build custom plugins and extensions to the web server
– MS ISS: ISAPI DLLs
– Netscape: NSAPI library/DLL


Pros: Extremely efficient
Cons:
– API is difficult to learn
– Only portable to specific server software
– Extensions can compromise stability of server
©2006
Scott Miller, University of Victoria
3
4/4/2016
Alternatives - #2

Keep CGI program running and send it
multiple requests rather than
starting/terminating a process each request
– Fast CGI
Pros: Helps compensate for inefficiencies
of CGI
 Cons: Still has other issues with CGI

– Poor content/presentation separation
– Better scaling, but still not great
©2006
Scott Miller, University of Victoria
4
4/4/2016
Alternatives - #3

Add extra features into SSI
– Conditionals
– Iterations
– Native Database support
 Cold Fusion .cfm
 Active Server Pages (ASP) .asp
 PHP .php

Pros:
– Dynamic content generated with minimal programming.
– Scripting languages easy to learn

Cons:
– Programs are embedded in HTML and tend to be very procedural
(not OOP); hard to re-use code
– Not very efficient (~20 concurrent users)
©2006
Scott Miller, University of Victoria
5
4/4/2016
Summary – So Far…

Motivation
– We want to improve the efficiency of CGI/SSI
– We want better separation of content and
presentation

Ideas:
– #1: API to the web server
– #2: Keep CGI process running
– #3: Improve SSI by adding procedural
capabilities
©2006
Scott Miller, University of Victoria
6
4/4/2016
Summary – So Far…

These solutions don’t solve everything!
– Content vs. Presentation still an issue in most
of these solutions
– API has security, stability and steep learning
curve
– Efficiency still isn’t very high for SSI based
attempts
©2006
Scott Miller, University of Victoria
7
4/4/2016
Alternatives - #4


Use an object-oriented, multi-threaded, portable
language with a standard library for web
applications
JAVA!
– javax.servlet package; servlet ≡ server-side applet

Servlets run in a java process which connects to
the web server via a “servlet engine”
– E.g. Apache Tomcat

http://www.foo.org/servlet/Login?user=me
©2006
Scott Miller, University of Victoria
8
4/4/2016
Alternatives - #4
Web
Server
Plug-in for various web servers
• Tomcat, IBM WebSphere, etc.
Servlet
Engine
Java classes
implementing
javax.servlet API
C1
C2
Each servlet is an instance of a Java class
©2006
Scott Miller, University of Victoria
9
4/4/2016
Servlet Approach

Pros:
– Scalable (multithreaded)
– Reusable (OOP)
– Internalization (working with different locales inputs
– currency, character sets, encodings, etc.)
– Very clean, elegant coding model (Java)
– Tables in relational databases can be abstracted by
Java objects (direct manipulation through Java)

Cons:
– Still write HTML as output
©2006
Scott Miller, University of Victoria
10
4/4/2016
Alternatives - #5

Embed powerful programming language
into HTML like SSI
– Java Server Pages (JSP) .jsp
Use special tags to embed java into HTML
so advanced programming can be used
 JSPs are compiled into servlets

– First compilation: slow
– Subsequent executions without needing recompilations: extremely fast
©2006
Scott Miller, University of Victoria
11
4/4/2016
What now?

Now we know the basics to dynamic web
applications
– Web server creates the HTTP request context and
passes it to another program
– External program generates dynamic HTML as output
and sets cookies in HTML headers


These principles can be used towards any web
application technology
Many technologies use similar structures, so
once you learn one, you can use the other
– JSP & ASP, etc.
©2006
Scott Miller, University of Victoria
12
4/4/2016
Web Browsers
Responsibilities
Architecture
Rev 2.0
©2006
Scott Miller, University of Victoria
13
4/4/2016
Web Browsers
One specific (most used) client for HTTP
 Many different “flavours”of browser

– Useful to keep in mind as “universal”
applications don’t work the same on each
browser platform
– Sent in “User-Agent” header

Very object-oriented design
©2006
Scott Miller, University of Victoria
14
4/4/2016
How do we design a client?

Generate and send HTTP requests to web servers in
response to:
– Typing a URL into the location field
– Clicking on a Hyperlink
– Clicking ‘refresh’
– “SUBMIT” action on a form
– <img src = “…/x.jpg”>



Embedded objects in the HTML
Accept HTTP responses from servers and process the
headers
Render the body of response in window
– Parse HTML
– Parse additional content (.jpg, .gif, video, etc.)
©2006
Scott Miller, University of Victoria
15
4/4/2016
Very High Level Flow
User enters
URL, etc.
Server
Processin
g
User sees
pretty page
©2006
User Requests
Resource
GUI processes
action
Browser Generates
Request
Internal Request
Module
Browser Receives
Response
Internal Parsing
Modules
Browser Displays
Resource
Object (HTML,
.jpg) Rendering
Scott Miller, University of Victoria
16
4/4/2016
More Responsibilities
Caching

–
Do I keep a copy in local storage? Do I already have
it there?
Authentication

–
How do I prompt for a username and password?
How do I store them for future use?
State Maintenance

–
How do I deal with cookies?
Embedded Objects

–
©2006
Do I request them automatically?
Scott Miller, University of Victoria
17
4/4/2016
More Responsibilities

HTTP Processing
– Do I implement ALL status codes? Do I properly use
headers?
– Need to FULLY understand/implement full HTTP
specifications

External Processing/Plug-ins
– Can I support complex objects? Do I support plug-ins
for 3rd party media?

Network Subsystem
– Do I know how to deal with TCP, errors, etc.?
©2006
Scott Miller, University of Victoria
18
4/4/2016
System Level Look (Fig 5.3)
Request
GUI
Networking
Request
Generator
Get
File
System
Caching
Cookies
Authentication
Config
©2006
Scott Miller, University of Victoria
19
4/4/2016
System Level Look (Fig 5.3)
Response
Processor
GUI
HTML
Renderer
File
System
Networking
Content
Decoders
Response
Request
Generator
Caching
Cookies
Set
Config
©2006
Scott Miller, University of Victoria
20
4/4/2016
Items to Consider

Browser architecture is HIERARCHY
– Remember “systems” – “A uses B”

MIME Types
– Determines what “content rendering
mechanism” to use
Each request/response is one full cycle.
Networking doesn’t take place in between
 File System involved – there is data to
worry about saving to hard disk space

©2006
Scott Miller, University of Victoria
21
4/4/2016
Persistent Data Rules (Table
5.1)
Caching
Decision
Response
Headers and
User Settings
Access Key
URL
Delete?
Expiry Date
OR
Cache Full
Cookies
User Settings
Domain and
Path
Expiry Date
OR
End of Session
Authorization
Credentials
Always store
them
Server
&
Realm
End of Session
©2006
Scott Miller, University of Victoria
22
4/4/2016
Advanced Ideas

POST method
– Sends data (e.x. upload picture) through body
of request; multipart messages
– Send remote code calls for remote
applications over HTTP; Remote Procedure
Calls
©2006
Scott Miller, University of Victoria
23
4/4/2016
Multipart Message Example
…
Content-Type: multipart/form-data;
boundary=“23tagDSFoj346189F2”
--23tagDSFoj346189F2
Content-Type: application/x-www-form-urlencoded
&filename=….&param=value
--23tagDSFoj346189F2
Content-Type: image/gif
Content-Transfer-Encoding: base64
FsZCB23oYXfy432Faate223GdsgY …
©2006
Scott Miller, University of Victoria
24
4/4/2016
Reading for Next Class
Get finished with Lab 2
 Decide on your Lab 3/4 project!


NEXT CLASS: EXAMPLES OF WEB
LANGUAGES AND HTML
©2006
Scott Miller, University of Victoria
25
4/4/2016