Web#

W3C event model#

W3C defines standard event model to be implemented by browsers [1] — DOM elements can dispatch and listen for events. Interface for this is Event interface [2], defining e.g. EventhTarget.dispatchEvent() and EventTarget.addEventListener(). Events are probably handled by separate thread for asynchronicity.

Phases#

Dispatched events go through 3 phases: capture, target, bubbling [3]. Phase under which event listener function is called is determined by third argument to addEventListener and usually defaults to bubbling.

N.b. Event only propagated from top of DOM heirarchy to target (element dispatcging event) — sibilngs and children never see event.

Custom events#

Custom events (i.e. not generated by browser) can be dispatched with EventTarget.dispatchEvent(). This is however handled synchronously [4].

Cross origin resource sharing#

HTTP response from one server results in further HTTP request to other server (e.g. via JS, HTML link tag, etc.) [5]. Used to be blocked, now more and more accepted [6].

Secondary server decides what resources are accessible. Can see from Access-Control-Allow-Origin value in header HTTP response — wildcard like matching of origins allowed to request resource. Most general is * — allow any server to request this data.

Easy check:

$ curl -v URL 2>&1 1>/dev/null | grep Access

For more security, can also specify resource hash to ensure content has not been tampered with. Do this with integrity attribute [7].

Returned content-type must also be considered — e.g. cannot use text/plain as CSS [8].

Server-Side Scripting#

Server-side scripting — request server to execute code in a scripting language (e.g. Python, PHP, etc) and return result. Requires server process to be able to execute scripts, ideally in any arbitrary scripting language.

As such, interface protocols developed to allow communication between server processes and scripting languages [9].

Protocols#

Common Gateway Interface (CGI)#

Oldest interface. Supported by almost all web servers.

Slow as each new request starts up separate scripting environment (e.g. python shell).

FastCGI and SCGI#

Upgrade to CGI.

One scripting process started and kept alive in background which handles all requests.

Web Server Gateway Interface (WSGI)#

Problem with all these legacy interfaces is that server-side (and web server) code must be tailored for the specific interface. As such, in order to develop server-side code which will work with all interfaces and all servers, would have to develop multiple versions of the server-side code. For example, python code for a wiki engine would need to be written so as to support CGI, FastCGI, SCGI, etc. in order to guarantee that it could be deployed on any web server.

To solve this duplication, the WSGI protocol was developed to act as an intermediate between all existing interfaces and all server-side scripting languages. In this way, when developing server-side code, only need to make it compatible with WSGI to ensure universal operability.

WSGI is defined as a client-server architecture:

WSGI Server

Connects to low-level gateway intefaces (i.e. CGI, FastCGI, etc)

WSGI Client

Connects to server-side code (e.g. Python, PHP, etc)

Practicalities#

Cannot get WSGI working on XAMMP. Tried with hgweb.wsgi and just refuses to work. Apache does not have wsgi module and so cannot interpret WSGIScriptAlias option.

Tried downloading wsgi module binary [10], but does not seem to work either. Looks like there may be fundamental compatibility issues [11]…