1. 10/20/2015 ©2006 Scott Miller, University of Victoria 1 Alternative Content Distribution Methods Non-CGI/SSI Content Serving

2. 10/20/2015 ©2006 Scott Miller, University of Victoria 2 CGI, SSI Building Blocks All alternative content serving methods use principles of CGI and SSI CGISSI ISAPI/ NSAPI Servlets Fast CGI JSP ASP.Net C# ASP Cold Fusion PHP

3. 10/20/2015 ©2006 Scott Miller, University of Victoria 3 Alternatives - #1 Give programmers an API to build custom plug- ins 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

4. 10/20/2015 ©2006 Scott Miller, University of Victoria 4 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

5. 10/20/2015 ©2006 Scott Miller, University of Victoria 5 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)

6. 10/20/2015 ©2006 Scott Miller, University of Victoria 6 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

7. 10/20/2015 ©2006 Scott Miller, University of Victoria 7 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

8. 10/20/2015 ©2006 Scott Miller, University of Victoria 8 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

9. 10/20/2015 ©2006 Scott Miller, University of Victoria 9 Alternatives - #4 Web Server Servlet Engine Java classes implementing javax.servlet API C1C2 Plug-in for various web servers Tomcat, IBM WebSphere, etc. Each servlet is an instance of a Java class

10. 10/20/2015 ©2006 Scott Miller, University of Victoria 10 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

11. 10/20/2015 ©2006 Scott Miller, University of Victoria 11 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 re- compilations: extremely fast

12. 10/20/2015 ©2006 Scott Miller, University of Victoria 12 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.

13. 10/20/2015 ©2006 Scott Miller, University of Victoria 13 Web Browsers Responsibilities Architecture Rev 2.0

14. 10/20/2015 ©2006 Scott Miller, University of Victoria 14 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

15. 10/20/2015 ©2006 Scott Miller, University of Victoria 15 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 – 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.)

16. 10/20/2015 ©2006 Scott Miller, University of Victoria 16 Very High Level Flow User Requests Resource Browser Generates Request User enters URL, etc. GUI processes action Internal Request Module Server Processin g Browser Receives Response Internal Parsing Modules Object (HTML,.jpg) Rendering Browser Displays Resource User sees pretty page

17. 10/20/2015 ©2006 Scott Miller, University of Victoria 17 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 –Do I request them automatically?

18. 10/20/2015 ©2006 Scott Miller, University of Victoria 18 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 3 rd party media? Network Subsystem –Do I know how to deal with TCP, errors, etc.?

19. 10/20/2015 ©2006 Scott Miller, University of Victoria 19 System Level Look (Fig 5.3) GUI CachingAuthenticationCookies Config Request Generator Networking Get File System Request

20. 10/20/2015 ©2006 Scott Miller, University of Victoria 20 System Level Look (Fig 5.3) GUI CachingCookies Config Networking File System Response Request Generator Content Decoders HTML Renderer Response Processor Set

21. 10/20/2015 ©2006 Scott Miller, University of Victoria 21 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

22. 10/20/2015 ©2006 Scott Miller, University of Victoria 22 Persistent Data Rules (Table 5.1) DecisionAccess KeyDelete? CachingResponse Headers and User Settings URLExpiry Date OR Cache Full CookiesUser SettingsDomain and Path Expiry Date OR End of Session Authorization Credentials Always store them Server & Realm End of Session

23. 10/20/2015 ©2006 Scott Miller, University of Victoria 23 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

24. 10/20/2015 ©2006 Scott Miller, University of Victoria 24 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 …

25. 10/20/2015 ©2006 Scott Miller, University of Victoria 25 Reading for Next Class Get finished with Lab 2 Decide on your Lab 3/4 project! NEXT CLASS: EXAMPLES OF WEB LANGUAGES AND HTML