Splash - A javascript rendering service¶
Splash is a javascript rendering service. It’s a lightweight web browser with an HTTP API, implemented in Python using Twisted and QT. The (twisted) QT reactor is used to make the sever fully asynchronous allowing to take advantage of webkit concurrency via QT main loop. Some of Splash features:
- process multiple webpages in parallel;
- get HTML results and/or take screenshots;
- turn OFF images or use Adblock Plus rules to make rendering faster;
- execute custom JavaScript in page context;
- transparently plug into existing software using Proxy interface;
- get detailed rendering info in HAR format.
Documentation¶
Installation¶
Linux + Docker¶
Install Docker.
Pull the image:
$ sudo docker pull scrapinghub/splash
Start the container:
$ sudo docker run -p 5023:5023 -p 8050:8050 -p 8051:8051 scrapinghub/splash
Splash is now available at 0.0.0.0 at ports 8050 (http), 8051 (https) and 5023 (telnet).
OS X + Docker¶
Install Docker (via Boot2Docker).
Pull the image:
$ docker pull scrapinghub/splash
Start the container:
$ docker run -p 5023:5023 -p 8050:8050 -p 8051:8051 scrapinghub/splash
Figure out the ip address of boot2docker:
$ boot2docker ip The VM's Host only interface IP address is: 192.168.59.103
Splash is available at the returned IP address at ports 8050 (http), 8051 (https) and 5023 (telnet).
Ubuntu 12.04 (manual way)¶
Install system dependencies:
$ sudo add-apt-repository -y ppa:pi-rho/security $ sudo apt-get update $ sudo apt-get install libre2-dev $ sudo apt-get install netbase ca-certificates python \ python-dev build-essential libicu48 \ xvfb libqt4-webkit python-twisted python-qt4
TODO: install Python dependencies using pip, clone repo, chdir to it, start splash.
To run the server execute the following command:
python -m splash.server
Run python -m splash.server --help to see options available.
By default, Splash API endpoints listen to port 8050 on all available IPv4 addresses. To change the port use --port option:
python -m splash.server --port=5000
Requirements¶
# install PyQt4 (Splash is tested on PyQT 4.9.x) and the following packages:
twisted
qt4reactor
psutil
adblockparser >= 0.2
-e git+https://github.com/axiak/pyre2.git#egg=re2
xvfbwrapper
# for scripting support
lupa >= 1.1
# the following libraries are only required by tests
pytest
pyOpenSSL
requests >= 1.0
Pillow
jsonschema >= 2.0
strict-rfc3339
Splash Versions¶
docker pull scrapinghub/splash will give you the latest stable Splash release. To obtain the latest development version use docker pull scrapinghub/splash:master. Specific Splash versions are also available, e.g. docker pull scrapinghub/splash:1.2.1.
Customizing Dockerized Splash¶
Passing Custom Options¶
To run Splash with custom options pass them to docker run. For example, let’s increase log verbosity:
$ docker run -p 8050:8050 scrapinghub/splash -v3
To see all possible options pass --help. Not all options will work the same inside Docker: changing ports doesn’t make sense (use docker run options instead), and paths are paths in the container.
Folders Sharing¶
To set custom Request Filters use -v Docker option. First, create a folder with request filters on your local filesystem, then make it available to the container:
$ docker run -p 8050:8050 -v <filters-dir>:/etc/splash/filters scrapinghub/splash
Docker Data Volume Containers can also be used. Check https://docs.docker.com/userguide/dockervolumes/ for more info.
Proxy Profiles and Javascript Profiles can be added the same way:
$ docker run -p 8050:8050 \
-v <proxy-profiles-dir>:/etc/splash/proxy-profiles \
-v <js-profiles-dir>:/etc/splash/js-profiles \
scrapinghub/splash
Warning
Folder sharing (-v option) doesn’t work on OS X and Windows (see https://github.com/docker/docker/issues/4023). It should be fixed in future Docker & Boot2Docker releases. For now use one of the workarounds mentioned in issue comments or clone Splash repo and customize its Dockerfile.
Splash in Production¶
In production you may want to daemonize Splash, start it on boot and restart on failures. Since Docker 1.2 an easy way to do this is to use --restart and -d options together:
$ docker run -d -p 8050:8050 --restart=always scrapinghub/splash
Another way to do that is to use standard tools like upstart, systemd or supervisor.
Splash HTTP API¶
Consult with Installation to get Splash up and running.
Splash is controlled via HTTP API. For all endpoints below parameters may be sent either as GET arguments or encoded to JSON and POSTed with Content-Type: application/json header.
The most versatile endpoint that provides all Splash features is execute (WARNING: it is still experimental). Other endpoints may be easier to use in specific cases - for example, render.png returns a screenshot in PNG format that can be used as img src without any further processing, and render.json is convenient if you don’t need to interact with a page.
The following endpoints are supported:
render.html¶
Return the HTML of the javascript-rendered page.
Arguments:
- url : string : required
- The url to render (required)
- baseurl : string : optional
The base url to render the page with.
If given, base HTML content will be feched from the URL given in the url argument, and render using this as the base url.
- timeout : float : optional
- A timeout (in seconds) for the render (defaults to 30)
- wait : float : optional
- Time (in seconds) to wait for updates after page is loaded (defaults to 0). Increase this value if you expect pages to contain setInterval/setTimeout javascript calls, because with wait=0 callbacks of setInterval/setTimeout won’t be executed. Non-zero ‘wait’ is also required for PNG rendering when viewport=full (see later).
- proxy : string : optional
- Proxy profile name. See Proxy Profiles.
- js : string : optional
- Javascript profile name. See Javascript Profiles.
js_source : string : optional
JavaScript code to be executed in page context. See Executing custom Javascript code within page context.
- filters : string : optional
- Comma-separated list of request filter names. See Request Filters
- allowed_domains : string : optional
- Comma-separated list of allowed domain names. If present, Splash won’t load anything neither from domains not in this list nor from subdomains of domains not in this list.
- viewport : string : optional
View width and height (in pixels) of the browser viewport to render the web page. Format is “<width>x<heigth>”, e.g. 800x600. It also accepts ‘full’ as value; viewport=full means that the whole page (possibly very tall) will be rendered. Default value is 1024x768.
‘viewport’ parameter is more important for PNG rendering; it is supported for all rendering endpoints because javascript code execution can depend on viewport size.
Note
viewport=full requires non-zero ‘wait’ parameter. This is an unfortunate restriction, but it seems that this is the only way to make rendering work reliably with viewport=full.
- images : integer : optional
Whether to download images. Possible values are 1 (download images) and 0 (don’t downoad images). Default is 1.
Note that cached images may be displayed even if this parameter is 0. You can also use Request Filters to strip unwanted contents based on URL.
headers : JSON array or object : optional
HTTP headers to set for the first outgoing request. This option is only supported for application/json POST requests. Value could be either a JSON array with (header_name, header_value) pairs or a JSON object with header names as keys and header values as values.
Examples¶
Curl example:
curl 'http://localhost:8050/render.html?url=http://domain.com/page-with-javascript.html&timeout=10&wait=0.5'
The result is always encoded to utf-8. Always decode HTML data returned by render.html endpoint from utf-8 even if there are tags like
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
in the result.
render.png¶
Return a image (in PNG format) of the javascript-rendered page.
Arguments:
Same as render.html plus the following ones:
- width : integer : optional
- Resize the rendered image to the given width (in pixels) keeping the aspect ratio.
- height : integer : optional
- Crop the renderd image to the given height (in pixels). Often used in conjunction with the width argument to generate fixed-size thumbnails.
Examples¶
Curl examples:
# render with timeout
curl 'http://localhost:8050/render.png?url=http://domain.com/page-with-javascript.html&timeout=10'
# 320x240 thumbnail
curl 'http://localhost:8050/render.png?url=http://domain.com/page-with-javascript.html&width=320&height=240'
render.har¶
Return information about Splash interaction with a website in HAR format. It includes information about requests made, responses received, timings, headers, cookies, etc.
You can use online HAR viewer to visualize information returned from this endpoint; it will be very similar to “Network” tabs in Firefox and Chrome developer tools.
Currently this endpoint doesn’t expose raw request and response contents; only meta-information like headers and timings is available.
Arguments for this endpoint are the same as for render.html.
render.json¶
Return a json-encoded dictionary with information about javascript-rendered webpage. It can include HTML, PNG and other information, based on arguments passed.
Arguments:
Same as render.png plus the following ones:
- html : integer : optional
- Whether to include HTML in output. Possible values are 1 (include) and 0 (exclude). Default is 0.
- png : integer : optional
- Whether to include PNG in output. Possible values are 1 (include) and 0 (exclude). Default is 0.
- iframes : integer : optional
- Whether to include information about child frames in output. Possible values are 1 (include) and 0 (exclude). Default is 0.
- script : integer : optional
- Whether to include the result of the executed javascript final statement in output (see Executing custom Javascript code within page context). Possible values are 1 (include) and 0 (exclude). Default is 0.
- console : integer : optional
- Whether to include the executed javascript console messages in output. Possible values are 1 (include) and 0 (exclude). Default is 0.
- history : integer : optional
Whether to include the history of requests/responses for webpage main frame. Possible values are 1 (include) and 0 (exclude). Default is 0.
Use it to get HTTP status codes, cookies and headers. Only information about “main” requests/responses is returned (i.e. information about related resources like images and AJAX queries is not returned). To get information about all requests and responses use ‘har’ argument.
- har : integer : optional
- Whether to include HAR in output. Possible values are 1 (include) and 0 (exclude). Default is 0. If this option is ON the result will contain the same data as render.har provides under ‘har’ key.
Examples¶
By default, URL, requested URL, page title and frame geometry is returned:
{
"url": "http://crawlera.com/",
"geometry": [0, 0, 640, 480],
"requestedUrl": "http://crawlera.com/",
"title": "Crawlera"
}
Add ‘html=1’ to request to add HTML to the result:
{
"url": "http://crawlera.com/",
"geometry": [0, 0, 640, 480],
"requestedUrl": "http://crawlera.com/",
"html": "<!DOCTYPE html><!--[if IE 8]>....",
"title": "Crawlera"
}
Add ‘png=1’ to request to add base64-encoded PNG screenshot to the result:
{
"url": "http://crawlera.com/",
"geometry": [0, 0, 640, 480],
"requestedUrl": "http://crawlera.com/",
"png": "iVBORw0KGgoAAAAN...",
"title": "Crawlera"
}
Setting both ‘html=1’ and ‘png=1’ allows to get HTML and a screenshot at the same time - this guarantees that the screenshot matches the HTML.
By adding “iframes=1” information about iframes could be obtained:
{
"geometry": [0, 0, 640, 480],
"frameName": "",
"title": "Scrapinghub | Autoscraping",
"url": "http://scrapinghub.com/autoscraping.html",
"childFrames": [
{
"title": "Tutorial: Scrapinghub's autoscraping tool - YouTube",
"url": "",
"geometry": [235, 502, 497, 310],
"frameName": "<!--framePath //<!--frame0-->-->",
"requestedUrl": "http://www.youtube.com/embed/lSJvVqDLOOs?version=3&rel=1&fs=1&showsearch=0&showinfo=1&iv_load_policy=1&wmode=transparent",
"childFrames": []
}
],
"requestedUrl": "http://scrapinghub.com/autoscraping.html"
}
Note that iframes can be nested.
Pass both ‘html=1’ and ‘iframes=1’ to get HTML for all iframes as well as for the main page:
{
"geometry": [0, 0, 640, 480],
"frameName": "",
"html": "<!DOCTYPE html...",
"title": "Scrapinghub | Autoscraping",
"url": "http://scrapinghub.com/autoscraping.html",
"childFrames": [
{
"title": "Tutorial: Scrapinghub's autoscraping tool - YouTube",
"url": "",
"html": "<!DOCTYPE html>...",
"geometry": [235, 502, 497, 310],
"frameName": "<!--framePath //<!--frame0-->-->",
"requestedUrl": "http://www.youtube.com/embed/lSJvVqDLOOs?version=3&rel=1&fs=1&showsearch=0&showinfo=1&iv_load_policy=1&wmode=transparent",
"childFrames": []
}
],
"requestedUrl": "http://scrapinghub.com/autoscraping.html"
}
Unlike ‘html=1’, ‘png=1’ does not affect data in childFrames.
When executing JavaScript code (see Executing custom Javascript code within page context) add the parameter ‘script=1’ to the request to include the code output in the result:
{
"url": "http://crawlera.com/",
"geometry": [0, 0, 640, 480],
"requestedUrl": "http://crawlera.com/",
"title": "Crawlera",
"script": "result of script..."
}
The JavaScript code supports the console.log() function to log messages. Add ‘console=1’ to the request to include the console output in the result:
{
"url": "http://crawlera.com/",
"geometry": [0, 0, 640, 480],
"requestedUrl": "http://crawlera.com/",
"title": "Crawlera",
"script": "result of script...",
"console": ["first log message", "second log message", ...]
}
Curl examples:
# full information
curl 'http://localhost:8050/render.json?url=http://domain.com/page-with-iframes.html&png=1&html=1&iframes=1'
# HTML and meta information of page itself and all its iframes
curl 'http://localhost:8050/render.json?url=http://domain.com/page-with-iframes.html&html=1&iframes=1'
# only meta information (like page/iframes titles and urls)
curl 'http://localhost:8050/render.json?url=http://domain.com/page-with-iframes.html&iframes=1'
# render html and 320x240 thumbnail at once; do not return info about iframes
curl 'http://localhost:8050/render.json?url=http://domain.com/page-with-iframes.html&html=1&png=1&width=320&height=240'
# Render page and execute simple Javascript function, display the js output
curl -X POST -H 'content-type: application/javascript' \
-d 'function getAd(x){ return x; } getAd("abc");' \
'http://localhost:8050/render.json?url=http://domain.com&script=1'
# Render page and execute simple Javascript function, display the js output and the console output
curl -X POST -H 'content-type: application/javascript' \
-d 'function getAd(x){ return x; }; console.log("some log"); console.log("another log"); getAd("abc");' \
'http://localhost:8050/render.json?url=http://domain.com&script=1&console=1'
execute¶
Warning
This endpoint is experimental. API could change in future releases.
Execute a custom rendering script and return a result.
render.html, render.png, render.har and render.json endpoints cover many common use cases, but sometimes they are not enough. This endpoint allows to write custom Splash Scripts.
Arguments:
- lua_source : string : required
- Browser automation script. See Splash Scripts Tutorial for more info.
- timeout : float : optional
- Same as ‘timeout’ argument for render.html.
- allowed_domains : string : optional
- Same as ‘allowed_domains’ argument for render.html.
- proxy : string : optional
- Same as ‘proxy’ argument for render.html.
- filters : string : optional
- Same as ‘filters’ argument for render.html.
Executing custom Javascript code within page context¶
Note
See also: executing JavaScript in Splash scripts
Splash supports executing JavaScript code within the context of the page. The JavaScript code is executed after the page finished loading (including any delay defined by ‘wait’) but before the page is rendered. This allow to use the javascript code to modify the page being rendered.
To execute JavaScript code use js_source parameter. It should contain JavaScript code to be executed.
Note that browsers and proxies limit the amount of data can be sent using GET, so it is a good idea to use content-type: application/json POST request.
Curl example:
# Render page and modify its title dynamically
curl -X POST -H 'content-type: application/json' \
-d '{"js_source": "document.title=\"My Title\";", "url": "http://example.com"}' \
'http://localhost:8050/render.html'
Another way to do it is to use a POST request with the content-type set to ‘application/javascript’. The body of the request should contain the code to be executed.
Curl example:
# Render page and modify its title dynamically
curl -X POST -H 'content-type: application/javascript' \
-d 'document.title="My Title";' \
'http://localhost:8050/render.html?url=http://domain.com'
To get the result of a javascript function executed within page context use render.json endpoint with script = 1 parameter.
In Splash-as-a-proxy mode use X-Splash-js-source header instead of a POST request.
Javascript Profiles¶
Splash supports “javascript profiles” that allows to preload javascript files. Javascript files defined in a profile are executed after the page is loaded and before any javascript code defined in the request.
The preloaded files can be used in the user’s POST’ed code.
To enable javascript profiles support, run splash server with the --js-profiles-path=<path to a folder with js profiles> option:
python -m splash.server --js-profiles-path=/etc/splash/js-profiles
Note
See also: Splash Versions.
Then create a directory with the name of the profile and place inside it the javascript files to load (note they must be utf-8 encoded). The files are loaded in the order they appear in the filesystem. Directory example:
/etc/splash/js-profiles/
mywebsite/
lib1.js
To apply this javascript profile add the parameter js=mywebsite to the request:
curl -X POST -H 'content-type: application/javascript' \
-d 'myfunc("Hello");' \
'http://localhost:8050/render.html?js=mywebsite&url=http://domain.com'
Note that this example assumes that myfunc is a javascript function defined in lib1.js.
Javascript Security¶
If Splash is started with --js-cross-domain-access option
python -m splash.server --js-cross-domain-access
then javascript code is allowed to access the content of iframes loaded from a security origin diferent to the original page (browsers usually disallow that). This feature is useful for scraping, e.g. to extract the html of a iframe page. An example of its usage:
curl -X POST -H 'content-type: application/javascript' \
-d 'function getContents(){ var f = document.getElementById("external"); return f.contentDocument.getElementsByTagName("body")[0].innerHTML; }; getContents();' \
'http://localhost:8050/render.html?url=http://domain.com'
The javascript function ‘getContents’ will look for a iframe with the id ‘external’ and extract its html contents.
Note that allowing cross origin javascript calls is a potential security issue, since it is possible that secret information (i.e cookies) is exposed when this support is enabled; also, some websites don’t load when cross-domain security is disabled, so this feature is OFF by default.
Request Filters¶
Splash supports filtering requests based on Adblock Plus rules. You can use filters from EasyList to remove ads and tracking codes (and thus speedup page loading), and/or write filters manually to block some of the requests (e.g. to prevent rendering of images, mp3 files, custom fonts, etc.)
To activate request filtering support start splash with --filters-path option:
python -m splash.server --filters-path=/etc/splash/filters
Note
See also: Splash Versions.
The folder --filters-path points to should contain .txt files with filter rules in Adblock Plus format. You may download easylist.txt from EasyList and put it there, or create .txt files with your own rules.
For example, let’s create a filter that will prevent custom fonts in ttf and woff formats from loading (due to qt bugs they may cause splash to segfault on Mac OS X):
! put this to a /etc/splash/filters/nofonts.txt file
! comments start with an exclamation mark
.ttf|
.woff|
To use this filter in a request add filters=nofonts parameter to the query:
curl 'http://localhost:8050/render.png?url=http://domain.com/page-with-fonts.html&filters=nofonts'
You can apply several filters; separate them by comma:
curl 'http://localhost:8050/render.png?url=http://domain.com/page-with-fonts.html&filters=nofonts,easylist'
If default.txt file is present in --filters-path folder it is used by default when filters argument is not specified. Pass filters=none if you don’t want default filters to be applied.
To learn about Adblock Plus filter syntax check these links:
Splash doesn’t support full Adblock Plus filters syntax, there are some limitations:
- element hiding rules are not supported; filters can prevent network request from happening, but they can’t hide parts of an already loaded page;
- only domain option is supported.
Unsupported rules are silently discarded.
Note
If you want to stop downloading images check ‘images’ parameter. It doesn’t require URL-based filters to work, and it can filter images that are hard to detect using URL-based patterns.
Warning
It is very important to have pyre2 library installed if you are going to use filters with a large number of rules (this is the case for files downloaded from EasyList).
Without pyre2 library splash (via adblockparser) relies on re module from stdlib, and it can be 1000x+ times slower than re2 - it may be faster to download files than to discard them if you have a large number of rules and don’t use re2. With re2 matching becomes very fast.
Make sure you are not using re2==0.2.20 installed from PyPI (it is broken); use the latest version from github.
Proxy Profiles¶
Splash supports “proxy profiles” that allows to set proxy handling rules per-request using proxy parameter.
To enable proxy profiles support, run splash server with --proxy-profiles-path=<path to a folder with proxy profiles> option:
python -m splash.server --proxy-profiles-path=/etc/splash/proxy-profiles
Note
See also: Splash Versions.
Then create an INI file with “proxy profile” config inside the specified folder, e.g. /etc/splash/proxy-profiles/mywebsite.ini. Example contents of this file:
[proxy]
; required
host=proxy.crawlera.com
port=8010
; optional, default is no auth
username=username
password=password
[rules]
; optional, default ".*"
whitelist=
.*mywebsite\.com.*
; optional, default is no blacklist
blacklist=
.*\.js.*
.*\.css.*
.*\.png
whitelist and blacklist are newline-separated lists of regexes. If URL matches one of whitelist patterns and matches none of blacklist patterns, proxy specified in [proxy] section is used; no proxy is used otherwise.
Then, to apply proxy rules according to this profile, add proxy=mywebsite parameter to request:
curl 'http://localhost:8050/render.html?url=http://mywebsite.com/page-with-javascript.html&proxy=mywebsite'
If default.ini profile is present, it will be used when proxy argument is not specified. If you have default.ini profile but don’t want to apply it pass none as proxy value.
Splash as a Proxy¶
Splash supports working as HTTP proxy. In this mode all the HTTP requests received will be proxied and the response will be rendered based in the following HTTP headers:
- X-Splash-render : string : required
- The render mode to use, valid modes are: html, png and json. These modes have the same behavior as the endpoints: render.html, render.png and render.json respectively.
- X-Splash-js-source : string
- Allow to execute custom javascript code in page context. See Executing custom Javascript code within page context.
- X-Splash-js : string
- Same as ‘js’ argument for render.html. See Javascript Profiles.
- X-Splash-timeout : string
- Same as ‘timeout’ argument for render.html.
- X-Splash-wait : string
- Same as ‘wait’ argument for render.html.
- X-Splash-proxy : string
- Same as ‘proxy’ argument for render.html.
- X-Splash-filters : string
- Same as ‘filters’ argument for render.html.
- X-Splash-allowed-domains : string
- Same as ‘allowed_domains’ argument for render.html.
- X-Splash-viewport : string
- Same as ‘viewport’ argument for render.html.
- X-Splash-images : string
- Same as ‘images’ argument for render.html.
- X-Splash-width : string
- Same as ‘width’ argument for render.png.
- X-Splash-height : string
- Same as ‘height’ argument for render.png.
- X-Splash-html : string
- Same as ‘html’ argument for render.json.
- X-Splash-png : string
- Same as ‘png’ argument for render.json.
- X-Splash-iframes : string
- Same as ‘iframes’ argument for render.json.
- X-Splash-script : string
- Same as ‘script’ argument for render.json.
- X-Splash-console : string
- Same as ‘console’ argument for render.json.
- X-Splash-history : string
- Same as ‘history’ argument for render.json.
- X-Splash-har : string
- Same as ‘har’ argument for render.json.
Note
Proxying of HTTPS requests is not supported.
Curl examples:
# Display json stats
curl -x localhost:8051 -H 'X-Splash-render: json' \
http://www.domain.com
# Get the html page and screenshot
curl -x localhost:8051 \
-H "X-Splash-render: json" \
-H "X-Splash-html: 1" \
-H "X-Splash-png: 1" \
http://www.mywebsite.com
# Execute JS and return output
curl -x localhost:8051 \
-H 'X-Splash-render: json' \
-H 'X-Splash-script: 1' \
-H 'X-Splash-js-source: function test(x){ return x; } test("abc");' \
http://www.domain.com
# Send POST request to site and save screenshot of results
curl -X POST -d '{"key":"val"}' -x localhost:8051 -o screenshot.png \
-H 'X-Splash-render: png' \
http://www.domain.com
Splash proxy mode is enabled by default; it uses port 8051. To change the port use --proxy-portnum option:
python -m splash.server --proxy-portnum=8888
To disable Splash proxy mode run splash server with --disable-proxy option:
python -m splash.server --disable-proxy
Splash Scripts Tutorial¶
Warning
Scripting support is an experimental feature for early adopters; API could change in future releases.
Intro¶
Splash can execute custom rendering scripts written in Lua programming language. This allows to use Splash as a browser automation tool similar to PhantomJS. To execute a script and get the result back send it to execute endpoint in a lua_source argument.
Note
Most likely you’ll be able to follow Splash scripting examples even without knowing Lua. Nevertheless, the language worths learning - with Lua you can, for example, write Redis, Nginx, Apache, World of Warcraft scripts, create mobile apps using Moai or Corona SDK or use state of the arts Deep Learning framework Torch7. It is easy to get started and there are good online resources available like Learn Lua in 15 minutes tutorial and Programming in Lua book.
Let’s start with a basic example:
function main(splash)
splash:go("http://example.com")
splash:wait(0.5)
local title = splash:runjs("document.title")
return {title=title}
end
If we submit this script to execute endpoint in a lua_source argument, Splash will go to example.com website, wait until it loads, then wait 0.5s more, then get page title (by evaluating a JavaScript snippet in page context), and then return the result as a JSON encoded object.
Note
Splash UI provides an easy way to try scripts: there is a code editor for Lua and a button to submit a script to execute. Visit http://127.0.0.1:8050/ (or whatever host/port Splash is listening to).
Entry Point: the “main” Function¶
The script must provide “main” function; this function is called by Splash. The result of this function is returned as an HTTP response. Script could contain other helper functions and statements, but ‘main’ is required.
In the first example ‘main’ function returned a Lua table (an associative array similar to JavaScript Object or Python dict). Such results are returned as JSON. This will return {"hello":"world!"} string as an HTTP response:
function main(splash)
return {hello="world!"}
end
Script can also return a string:
function main(splash)
return 'hello'
end
Strings are returned as-is (unlike tables they are not encoded to JSON). Let’s check it with curl:
$ curl 'http://127.0.0.1:8050/execute?lua_source=function+main%28splash%29%0D%0A++return+%27hello%27%0D%0Aend'
hello
“main” function receives an object that allows to control the “browser tab”. All Splash features are exposed using this object. By a convention, this argument is called “splash”, but you are not required to follow this convention:
function main(please)
please:go("http://example.com")
please:wait(0.5)
return "ok"
end
Where Are My Callbacks?¶
Here is a part of the first example:
splash:go("http://example.com")
splash:wait(0.5)
local title = splash:runjs("document.title")
The code looks like a standard procedural code; there are no callbacks or fancy control flow structures. It doesn’t mean Splash works in a synchronous way; under the hood it is still async. When you call splash.wait(0.5), Splash switches from the script to other tasks, and comes back after 0.5s.
It is possible to use loops, conditional statements, functions as usual in Splash scripts; this enables a more straightforward code.
Let’s check an example PhantomJS script:
var users = ["PhantomJS", "ariyahidayat", /*...*/];
function followers(user, callback) {
var page = require('webpage').create();
page.open('http://mobile.twitter.com/' + user, function (status) {
if (status === 'fail') {
console.log(user + ': ?');
} else {
var data = page.evaluate(function () {
return document.querySelector('div.profile td.stat.stat-last div.statnum').innerText;
});
console.log(user + ': ' + data);
}
page.close();
callback.apply();
});
}
function process() {
if (users.length > 0) {
var user = users[0];
users.splice(0, 1);
followers(user, process);
} else {
phantom.exit();
}
}
process();
The code is arguably tricky: process function implements a loop by creating a chain of callbacks; followers function doesn’t return a value (it would be more complex to implement) - the result is logged to the console instead.
A similar Splash script:
users = {'PhantomJS', 'ariyahidayat'}
function followers(splash, user)
local ok, msg = splash:go('http://mobile.twitter.com/' .. user)
if not ok then
return "?"
end
return splash:runjs([[
document.querySelector('div.profile td.stat.stat-last div.statnum').innerText;
]]);
end
function process(splash, users)
local result = {}
for idx, user in ipairs(users) do
result[user] = followers(splash, user)
end
return result
end
function main(splash)
local users = process(splash, users)
return {users=users}
end
Observations:
- some Lua knowledge is helpful to be productive in Splash Scripts: ipairs, [[multi-line strings]] or string concatenation via .. could be unfamiliar;
- in Splash variant followers function can return a result (a number of twitter followers); also, it doesn’t need a “callback” argument;
- instead of a page.open callback which receives “status” argument there is a “blocking” splash:go call which returns “ok” flag;
- error handling is different: in case of an HTTP 4xx or 5xx error PhantomJS doesn’t return an error code to page.open callback - example script will try to get the followers nevertheless because “status” won’t be “fail”; in Splash this error will be detected and ”?” will be returned;
- process function can use a standard Lua for loop without a need to create a recursive callback chain;
- instead of console messages we’ve got a JSON HTTP API;
- apparently, PhantomJS allows to create multiple page objects and run several page.open requests in parallel (?); Splash only provides a single “browser tab” to a script via its splash parameter of main function (but you’re free to send multiple concurrent requests with Lua scripts to Splash).
There are great PhantomJS wrappers like CasperJS and NightmareJS which (among other things) bring a sync-looking syntax to PhantomJS scripts by providing custom control flow mini-languages. However, they all have their own gotchas and edge cases (loops? moving code to helper functions? error handling?). Splash scripts are standard Lua code.
Note
PhantomJS itself and its wrappers are great, they deserve lots of respect; please don’t take this writeup as an attack on them. These tools are much more mature and feature complete than Splash. Splash tries to look at the problem from a different angle, but for each unique Splash feature there are ten unique PhantomJS features.
Living Without Callbacks¶
In Splash scripts it is not explicit which calls are async and which calls are blocking. It is a common criticism of coroutines/greenlets; check e.g. this article for a good description of the problem. However, we feel that in Splash scripts negative effects are not quite there: scripts are meant to be small, shared state is minimized, and an API is designed to execute a single command at time, so in most cases the control flow is linear.
If you want to be safe then think of all splash methods as of async; consider that after you call splash:foo() a webpage being rendered can change. Often that’s the point of calling a method, e.g. splash:wait(time) or splash:go(url) only make sense because webpage changes after calling them, but still - keep it in mind.
Currently the only async methods are splash:go and splash:wait. Most splash methods are currently not async, but thinking of them as of async will allow your scripts to work if we ever change that.
Note
For the curious, Splash uses Lua coroutines under the hood.
Internally, “main” function is executed as a coroutine by Splash, and some of the splash:foo() methods use coroutine.yield. See http://www.lua.org/pil/9.html for Lua coroutines tutorial.
Calling Splash Methods¶
Unlike many languages, in Lua methods are usually separated from an object using a colon :; to call “foo” method of “splash” object use splash:foo() syntax. See http://www.lua.org/pil/16.html for more details.
There are two main ways to call Lua methods in Splash scripts: using positional and named arguments. To call a method using positional arguments use parentheses splash:foo(val1, val2), to call it with named arguments use curly braces: splash:foo{name1=val1, name2=val2}:
-- Examples of positional arguments:
splash:go("http://example.com")
splash:wait(0.5, false)
local title = splash:runjs("document.title")
-- The same using keyword arguments:
splash:go{url="http://example.com"}
splash:wait{time=0.5, cancel_on_redirect=false}
local title = splash:runjs{source="document.title"}
-- Mixed arguments example:
splash:wait{0.5, cancel_on_redirect=false}
For the convenience all splash methods are designed to support both styles of calling. But note that generally this convention is not followed in Lua. There are no “real” named arguments in Lua, and most Lua functions (including the ones from the standard library) choose to support only one style of calling. Check http://www.lua.org/pil/5.3.html for more info.
Error Handling¶
There are two ways to report errors in Lua: raise an exception and return an error flag. See http://www.lua.org/pil/8.3.html.
Splash uses the following convention:
- for developer errors (e.g. incorrect function arguments) exception is raised;
- for errors outside developer control (e.g. a non-responding remote website) status flag is returned: functions that can fail return ok, reason pairs which developer can either handle or ignore.
If main results in an unhandled exception then Splash returns HTTP 400 response with an error message.
It is possible to raise an exception manually using Lua error function:
error("A message to be returned in a HTTP 400 response")
To handle Lua exceptions (and prevent Splash from returning HTTP 400 response) use Lua pcall; see http://www.lua.org/pil/8.4.html.
To convert “status flag” errors to exceptions Lua assert function can be used. For example, if you expect a website to work and don’t want to handle errors manually, then assert allows to stop processing and return HTTP 400 if the assumption is wrong:
local ok, msg = splash:go("http://example.com")
if not ok then
-- handle error somehow, e.g.
error(msg)
end
-- a shortcut for the code above: use assert
assert(splash:go("http://example.com"))
Splash Scripts Reference¶
Warning
Scripting support is an experimental feature for early adopters; API could change in future releases.
splash object is passed to main function; via this object a script can control the browser. Think of it as of an API to a single browser tab.
splash:go¶
Go to an URL. This is similar to entering an URL in a browser address bar, pressing Enter and waiting until page loads.
Signature: ok, reason = splash.go{url, baseurl=nil}
Parameters:
- url - URL to load;
- baseurl - base URL to use, optional. When baseurl argument is passed the page is still loaded from url, but it is rendered as if it was loaded from baseurl: relative resource paths will be relative to baseurl, and the browser will think baseurl is in address bar.
Returns: ok, reason pair. If ok is nil then error happened during page load; reason provides an information about error type.
Two types of errors are reported (ok can be nil in two cases):
- There is nothing to render. This can happen if a host doesn’t exist, server dropped connection, etc. In this case reason is "error".
- Server returned a response with 4xx or 5xx HTTP status code. reason is "http<code>" in this case, i.e. for HTTP 404 Not Found reason is "http404".
Error handling example:
local ok, reason = splash:go("http://example.com")
if not ok:
if reason:sub(0,4) == 'http' then
-- handle HTTP errors
else
-- handle other errors
end
end
-- process the page
-- assert can be used as a shortcut for error handling
assert(splash:go("http://example.com"))
Errors (ok==nil) are only reported when “main” webpage request failed. If a request to a related resource failed then no error is reported by splash:go. To detect and handle such errors (e.g. broken image/js/css links, ajax requests failed to load) use splash:har.
splash:go follows all HTTP redirects before returning the result, but it doesn’t follow HTML <meta http-equiv="refresh" ...> redirects or redirects initiated by JavaScript code. To give the webpage time to follow those redirects use splash:wait.
splash:wait¶
Wait for time seconds. When script is waiting WebKit continues processing the webpage.
Signature: ok, reason = splash:wait{time, cancel_on_redirect=false, cancel_on_error=true}
Parameters:
- time - time to wait, in seconds;
- cancel_on_redirect - if true (not a default) and a redirect happened while waiting, then splash:wait stops earlier and returns nil, "redirect". Redirect could be initiated by <meta http-equiv="refresh" ...> HTML tags or by JavaScript code.
- cancel_on_error - if true (default) and an error which prevents page from being rendered happened while waiting (e.g. an internal WebKit error or a network error like a redirect to a non-resolvable host) then splash:wait stops earlier and returns nil, "error".
Returns: ok, reason pair. If ok is nil then the timer was stopped prematurely, and reason contains a string with a reason. Possible reasons are "error" and "redirect".
Usage example:
-- go to example.com, wait 0.5s, return rendered html, ignore all errors.
function main(splash)
splash:go("http://example.com")
splash:wait(0.5)
return {html=splash:html()}
end
By default wait timer continues to tick when redirect happens. cancel_on_redirect option can be used to restart the timer after each redirect. For example, here is a function that waits for a given time after each page load in case of redirects:
function wait_restarting_on_redirects(splash, time, max_redirects)
local redirects_remaining = max_redirects
while redirects_remaining do
local ok, reason = self:wait{time=time, cancel_on_redirect=true}
if reason ~= 'redirect' then
return ok, reason
end
redirects_remaining = redirects_remaining - 1
end
return nil, "too_many_redirects"
end
splash:jsfunc¶
Convert JavaScript function to a Lua callable.
Signature: lua_func = splash:jsfunc(func)
Parameters:
- func - a string which defines a JavaScript function.
Returns: a function that can be called from Lua to execute JavaScript code in page context.
Example:
function main(splash)
local get_div_count = splash:jsfunc([[
function (){
var body = document.body;
var divs = body.getElementsByTagName('div');
return divs.length;
}
]])
splash:go(splash.args.url)
return get_div_count()
end
Note how Lua [[ ]] string syntax is helpful here.
JavaScript functions may accept arguments:
local vec_len = splash:jsfunc([[
function(x, y) {
return Math.sqrt(x*x + y*y)
}
]])
return {res=vec_len(5, 4)}
Global JavaScript functions can be wrapped directly:
local pow = splash:jsfunc("Math.pow")
local twenty_five = pow(5, 2) -- 5^2 is 25
local thousand = pow(10, 3) -- 10^3 is 1000
Lua strings, numbers, booleans and tables can be passed as arguments; they are converted to JS strings/numbers/booleans/objects. Currently it is not possible to pass other Lua objects. For example, it is not possible to pass a wrapped JavaScript function or a regular Lua function as an argument to another wrapped JavaScript function.
Lua → JavaScript conversion rules:
Lua | JavaScript |
---|---|
string | string |
number | number |
boolean | boolean |
table | Object |
nil | undefined |
Function result is converted from JavaScript to Lua data type. Only simple JS objects are supported. For example, returning a function or a JQuery selector from a wrapped function won’t work.
JavaScript → Lua conversion rules:
JavaScript | Lua |
---|---|
string | string |
number | number |
boolean | boolean |
Object | table |
Array | table |
undefined | nil |
null | "" (an empty string) |
Date | string: date’s ISO8601 representation, e.g. 1958-05-21T10:12:00Z |
RegExp | table {_jstype='RegExp', caseSensitive=true/false, pattern='my-regexp'} |
function | an empty table {} (don’t rely on it) |
Function arguments and return values are passed by value. For example, if you modify an argument from inside a JavaScript function then the caller Lua code won’t see the changes, and if you return a global JS object and modify it in Lua then object won’t be changed in webpage context.
Note
The rule of thumb: if an argument or a return value can be serialized via JSON, then it is fine.
If a JavaScript function throws an error, it is re-throwed as a Lua error. To handle errors it is better to use JavaScript try/catch because some of the information about the error can be lost in JavaScript → Lua conversion.
splash:runjs¶
Execute a JavaScript snippet in page context and return the result of the last statement.
Signature: result = splash:runjs(snippet)
Parameters:
- snippet - a string with JavaScript source code to execute.
Returns: the result of the last statement in snippet, converted from JavaScript to Lua data types.
JavaScript → Lua conversion rules are the same as for splash:jsfunc.
splash:runjs is useful to evaluate short snippets of code or to execute some code without defining a wrapper function.
Example:
local title = splash:runjs("document.title")
splash:jsfunc() is more versatile because it allows to pass arguments to JavaScript functions; to do that with splash:runjs string formatting must be used. Compare:
-- Lua function to scroll window to (x, y) position.
function scroll_to(splash, x, y)
local js = string.format(
"window.scrollTo(%s, %s);",
tonumber(x),
tonumber(y)
)
return splash:runjs(js)
end
-- a simpler version using splash:jsfunc
function scroll_to2(splash, x, y)
local window_scroll = splash:jsfunc("window.scrollTo")
return window_scroll(x, y)
end
splash:html¶
Return a HTML snapshot of a current page (as a string).
Signature: html = splash:html()
Returns: contents of a current page (as a string).
Example:
-- A simplistic implementation of render.html endpoint
function main(splash)
splash:set_result_content_type("text/html; charset=utf-8")
assert(splash:go(splash.args.url))
return splash:html()
end
Nothing prevents us from taking multiple HTML snapshots. For example, let’s visit first 10 pages on a website, and for each page store initial HTML snapshot and an HTML snapshot after waiting 0.5s:
-- Given an url, this function returns a table with
-- two HTML snapshots: HTML right after page is loaded,
-- and HTML after waiting 0.5s.
function page_info(splash, url)
local ok, msg = splash:go(url)
if not ok then
return {ok=false, reason=msg}
end
local res = {before=splash:html()}
assert(splash:wait(0.5)) -- this shouldn't fail, so we wrap it in assert
res.after = splash:html() -- the same as res["after"] = splash:html()
res.ok = true
return res
end
-- visit first 10 http://example.com/pages/<num> pages,
-- return their html snapshots
function main(splash)
local result = {}
for i=1,10 do
local url = "http://example.com/pages/" .. page_num
result[i] = page_info(splash, url)
end
return result
end
splash:png¶
Return a width x height screenshot of a current page in PNG format.
Signature: png = splash:png{width=nil, height=nil}
Parameters:
- width - optional, width of a screenshot in pixels;
- height - optional, height of a screenshot in pixels.
Returns: PNG screenshot data.
TODO: document what default values mean
width and height arguments set a size of the resulting image, not a size of an area screenshot is taken of. For example, if the viewport is 1024px wide then splash:png{width=100} will return a screenshot of the whole viewport, but an image will be downscaled to 100px width.
To set the viewport size use splash:set_viewport method.
If the result of splash:png() is returned directly as a result of “main” function, the screenshot is returned as binary data:
-- A simplistic implementation of render.png endpoint
function main(splash)
splash:set_result_content_type("image/png")
assert(splash:go(splash.args.url))
return splash:png{
width=splash.args.width,
height=splash.args.height
}
end
If the result of splash:png() is returned as a table value, it is encoded to base64 to make it possible to embed in JSON and build a data:uri on a client (magic!):
function main(splash)
assert(splash:go(splash.args.url))
return {png=splash:png()}
end
If your script returns the result of splash:png() in a top-level "png" key (as we’ve done in a previous example) then Splash UI will display it as an image.
splash:har¶
Signature: har = splash:har()
Returns: information about pages loaded, events happened, network requests sent and responses received in HAR format.
If your script returns the result of splash:har() in a top-level "har" key then Splash UI will give you a nice diagram with network information (similar to “Network” tabs in Firefox or Chrome developer tools):
function main(splash)
assert(splash:go(splash.args.url))
return {har=splash:har()}
end
splash:history¶
Signature: entries = splash:history()
Returns: information about requests/responses for the pages loaded, in HAR entries format.
splash:history doesn’t return information about related resources like images, scripts, stylesheets or AJAX requests. If you need this information use splash:har.
Let’s get a JSON array with HTTP headers of the response we’re displaying:
function main(splash)
assert(splash:go(splash.args.url))
local entries = splash:history()
-- #entries means "entries length"; arrays in Lua start from 1
local last_entry = entries[#entries]
return {
headers = last_entry.response.headers
}
end
splash:set_result_content_type¶
Set Content-Type of a result returned to a client.
Signature: splash:set_result_content_type(content_type)
Parameters:
- content_type - a string with Content-Type header value.
If a table is returned by “main” function then splash:set_result_content_type has no effect: Content-Type of the result is set to application/json.
This function does not set Content-Type header for requests initiated by splash:go; this function is for setting Content-Type header of a result.
Example:
function main(splash)
splash:set_result_content_type("text/xml")
return [[
<?xml version="1.0" encoding="UTF-8"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
]]
end
splash:set_images_enabled¶
Enable/disable images.
Signature: splash:set_images_enabled(enabled)
Parameters:
- enabled - true to enable images, false to disable them.
By default, images are enabled. Disabling of the images can save a lot of network traffic (usually around ~50%) and make rendering faster. Note that this option can affect the JavaScript code inside page: disabling of the images may change sizes and positions of DOM elements, and scripts may read and use them.
Splash uses in-memory cache; cached images will be displayed even when images are disabled. So if you load a page, then disable images, then load a new page, then likely first page will display all images and second page will display some images (the ones common with the first page). Splash cache is shared between scripts executed in the same process, so you can see some images even if they are disabled at the beginning of the script.
Example:
function main(splash)
splash:set_images_enabled(false)
assert(splash:go("http://example.com"))
return {png=splash:png()}
end
splash:set_viewport¶
Set the browser viewport.
Signature: width, height = splash:set_viewport(size)
Parameters:
- size - string, width and height of the viewport. Format is "<width>x<heigth>", e.g. "800x600". It also accepts "full" as a value; "full" means that the viewport size will be auto-detected to fit the whole page (possibly very tall).
Returns: two numbers: width and height the viewport is set to, in pixels.
splash:set_viewport("full") should be called only after page is loaded, and some time passed after that (use splash:wait). This is an unfortunate restriction, but it seems that this is the only way to make rendering work reliably with size=”full”.
splash:png uses the viewport size.
Example:
function main(splash)
assert(splash:go("http://example.com"))
assert(splash:wait(0.5))
splash:set_viewport("full")
return {png=splash:png()}
end
splash.args¶
splash.args is a table with incoming parameters. It contains merged values from the orignal URL string (GET arguments) and values sent using application/json POST request.
Splash Development¶
Contributing¶
Splash is free & open source. Development happens at github: https://github.com/scrapinghub/splash
Functional Tests¶
Run with:
py.test --doctest-modules splash
To speedup test running install pytest-xdist Python package and run Splash tests in parallel:
py.test --doctest-modules -n4 splash
Stress tests¶
There are some stress tests that spawn its own splash server and a mock server to run tests against.
To run the stress tests:
python -m splash.tests.stress
Typical output:
$ python -m splash.tests.stress
Total requests: 1000
Concurrency : 50
Log file : /tmp/splash-stress-48H91h.log
........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Received/Expected (per status code or error):
200: 500/500
504: 200/200
502: 300/300
Changes¶
1.3 (2014-12-04)¶
This release introduces an experimental scripting support.
Other changes:
- manhole is disabled by default in Debian package;
- more objects are tracked in /debug endpoint;
- “history” in render.json now includes “queryString” keys; it makes the output compatible with HAR entry format;
- logging improvements;
- improved timer cancellation.
1.2.1 (2014-10-16)¶
- Dockerfile base image is downgraded to Ubuntu 12.04 to fix random crashes;
- Debian/buildbot config is fixed to make Splash UI available when deployed from deb;
- Qt / PyQt / sip / WebKit / Twisted version numbers are logged at startup.
1.2 (2014-10-14)¶
- All Splash rendering endpoints now accept Content-Type: application/json POST requests with JSON-encoded rendering options as an alternative to using GET parameters;
- headers parameter allows to set HTTP headers (including user-agent) for all endpoints - previously it was possible only in proxy mode;
- js_source parameter allows to execute JS in page context without application/javascript POST requests;
- testing suite is switched to pytest, test running can now be parallelized;
- viewport size changes are logged;
- /debug endpoint provides leak info for more classes;
- Content-Type header parsing is less strict;
- documentation improvements;
- various internal code cleanups.
1.1 (2014-10-10)¶
- An UI is added - it allows to quickly check Splash features.
- Splash can now return requests/responses information in HAR format. See render.har endpoint and har argument of render.json endpoint. A simpler history argument is also available. With HAR support it is possible to get timings for various events, HTTP status code of the responses, HTTP headers, redirect chains, etc.
- Processing of related resources is stopped earlier and more robustly in case of timeouts.
- wait parameter changed its meaning: waiting now restarts after each redirect.
- Dockerfile is improved: image is updated to Ubuntu 14.04; logs are shown immediately; it becomes possible to pass additional options to Splash and customize proxy/js/filter profiles; adblock filters are supported in Docker; versions of Python dependencies are pinned; Splash is started directly (without supervisord).
- Splash now tries to start Xvfb automatically - no need for xvfb-run. This feature requires xvfbwrapper Python package to be installed.
- Debian package improvements: Xvfb viewport matches default Splash viewport, it is possible to change Splash option using SPLASH_OPTS environment variable.
- Documentation is improved: finally, there are some install instructions.
- Logging: verbosity level of several logging events are changed; data-uris are truncated in logs.
- Various cleanups and testing improvements.
1.0 (2014-07-28)¶
Initial release.