From fe3492a98de29942477b061cd02c92246f4bf85a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Mon, 28 Mar 2016 15:36:42 +0200 Subject: Initial commit, new website system --- .gitignore | 3 + CNAME | 1 + _build/Makefile | 104 + _build/config.toml | 11 + _build/content/articles/cowboy2-qs.asciidoc | 184 + .../content/articles/erlang-scalability.asciidoc | 143 + .../content/articles/erlang-validate-utf8.asciidoc | 202 + .../content/articles/erlang.mk-and-relx.asciidoc | 131 + ...rlanger-playbook-september-2015-update.asciidoc | 25 + _build/content/articles/erlanger-playbook.asciidoc | 69 + _build/content/articles/farwest-funded.asciidoc | 37 + .../content/articles/january-2014-status.asciidoc | 159 + _build/content/articles/on-open-source.asciidoc | 137 + _build/content/articles/ranch-ftp.asciidoc | 220 + _build/content/articles/the-story-so-far.asciidoc | 250 + _build/content/articles/tictactoe.asciidoc | 91 + .../articles/xerl-0.1-empty-modules.asciidoc | 153 + .../content/articles/xerl-0.2-two-modules.asciidoc | 152 + .../articles/xerl-0.3-atomic-expressions.asciidoc | 135 + .../xerl-0.4-expression-separator.asciidoc | 48 + .../articles/xerl-0.5-intermediate-module.asciidoc | 145 + _build/content/docs.asciidoc | 28 + _build/content/donate.asciidoc | 24 + _build/content/services.asciidoc | 95 + _build/content/slogan.asciidoc | 7 + _build/content/talks.asciidoc | 14 + _build/data/projects/bullet.toml | 8 + _build/data/projects/cowboy.toml | 10 + _build/data/projects/cowlib.toml | 8 + _build/data/projects/erlang.mk.toml | 9 + _build/data/projects/gun.toml | 10 + _build/data/projects/ranch.toml | 10 + _build/data/talks.toml | 86 + _build/static/CNAME | 1 + _build/static/docs/db.json | 1 + .../en/cowboy/1.0/guide/architecture/index.html | 202 + .../en/cowboy/1.0/guide/broken_clients/index.html | 212 + .../docs/en/cowboy/1.0/guide/cookies/index.html | 273 + .../cowboy/1.0/guide/erlang_beginners/index.html | 196 + .../docs/en/cowboy/1.0/guide/erlang_web/index.html | 248 + .../en/cowboy/1.0/guide/getting_started/index.html | 299 + .../docs/en/cowboy/1.0/guide/hooks/index.html | 239 + .../en/cowboy/1.0/guide/http_handlers/index.html | 279 + .../en/cowboy/1.0/guide/http_req_life/index.html | 251 + .../docs/en/cowboy/1.0/guide/http_req_resp.png | Bin 0 -> 33228 bytes .../docs/en/cowboy/1.0/guide/http_req_resp.svg | 558 + _build/static/docs/en/cowboy/1.0/guide/index.html | 250 + .../en/cowboy/1.0/guide/introduction/index.html | 212 + .../en/cowboy/1.0/guide/loop_handlers/index.html | 264 + .../en/cowboy/1.0/guide/middlewares/index.html | 226 + .../docs/en/cowboy/1.0/guide/modern_web/index.html | 282 + .../en/cowboy/1.0/guide/multipart_intro/index.html | 198 + .../en/cowboy/1.0/guide/multipart_req/index.html | 261 + .../static/docs/en/cowboy/1.0/guide/req/index.html | 390 + .../docs/en/cowboy/1.0/guide/req_body/index.html | 296 + .../en/cowboy/1.0/guide/resource_design/index.html | 294 + .../docs/en/cowboy/1.0/guide/resp/index.html | 327 + .../static/docs/en/cowboy/1.0/guide/rest_cond.png | Bin 0 -> 111628 bytes .../static/docs/en/cowboy/1.0/guide/rest_cond.svg | 1656 +++ .../docs/en/cowboy/1.0/guide/rest_conneg.png | Bin 0 -> 78133 bytes .../docs/en/cowboy/1.0/guide/rest_conneg.svg | 1135 ++ .../docs/en/cowboy/1.0/guide/rest_delete.png | Bin 0 -> 122185 bytes .../docs/en/cowboy/1.0/guide/rest_delete.svg | 1718 +++ .../en/cowboy/1.0/guide/rest_flowcharts/index.html | 304 + .../docs/en/cowboy/1.0/guide/rest_get_head.png | Bin 0 -> 99942 bytes .../docs/en/cowboy/1.0/guide/rest_get_head.svg | 1523 ++ .../en/cowboy/1.0/guide/rest_handlers/index.html | 289 + .../docs/en/cowboy/1.0/guide/rest_options.png | Bin 0 -> 8539 bytes .../docs/en/cowboy/1.0/guide/rest_options.svg | 387 + .../en/cowboy/1.0/guide/rest_principles/index.html | 238 + .../en/cowboy/1.0/guide/rest_put_post_patch.png | Bin 0 -> 218656 bytes .../en/cowboy/1.0/guide/rest_put_post_patch.svg | 2856 ++++ .../static/docs/en/cowboy/1.0/guide/rest_start.png | Bin 0 -> 118210 bytes .../static/docs/en/cowboy/1.0/guide/rest_start.svg | 1468 ++ .../docs/en/cowboy/1.0/guide/routing/index.html | 365 + .../en/cowboy/1.0/guide/static_handlers/index.html | 280 + .../cowboy/1.0/guide/upgrade_protocol/index.html | 200 + .../en/cowboy/1.0/guide/ws_handlers/index.html | 327 + .../en/cowboy/1.0/guide/ws_protocol/index.html | 194 + _build/static/docs/en/cowboy/1.0/index.html | 206 + .../docs/en/cowboy/1.0/manual/cowboy/index.html | 273 + .../en/cowboy/1.0/manual/cowboy_app/index.html | 188 + .../en/cowboy/1.0/manual/cowboy_handler/index.html | 199 + .../1.0/manual/cowboy_http_handler/index.html | 229 + .../1.0/manual/cowboy_loop_handler/index.html | 245 + .../cowboy/1.0/manual/cowboy_middleware/index.html | 213 + .../cowboy/1.0/manual/cowboy_protocol/index.html | 244 + .../en/cowboy/1.0/manual/cowboy_req/index.html | 854 ++ .../en/cowboy/1.0/manual/cowboy_rest/index.html | 698 + .../en/cowboy/1.0/manual/cowboy_router/index.html | 247 + .../en/cowboy/1.0/manual/cowboy_spdy/index.html | 212 + .../en/cowboy/1.0/manual/cowboy_static/index.html | 194 + .../1.0/manual/cowboy_sub_protocol/index.html | 203 + .../cowboy/1.0/manual/cowboy_websocket/index.html | 208 + .../1.0/manual/cowboy_websocket_handler/index.html | 273 + .../cowboy/1.0/manual/http_status_codes/index.html | 305 + _build/static/docs/en/cowboy/1.0/manual/index.html | 197 + _build/static/res/erlanger-preview.pdf | Bin 0 -> 118131 bytes _build/static/res/tictactoe.erl | 89 + _build/static/talks/PDF/cowboy.pdf | Bin 0 -> 52395 bytes _build/static/talks/PDF/sheriff.pdf | Bin 0 -> 58933 bytes _build/static/talks/bed/bed.ezdoc | 432 + _build/static/talks/bed/bed.html | 767 + _build/static/talks/bed/pics/family_business.jpg | Bin 0 -> 52468 bytes _build/static/talks/bed/pics/mind_blown.jpg | Bin 0 -> 144843 bytes _build/static/talks/bed/pics/rest.jpg | Bin 0 -> 34610 bytes _build/static/talks/bed/pics/wondering.jpg | Bin 0 -> 51067 bytes _build/static/talks/bed/ui/default/blank.gif | Bin 0 -> 49 bytes _build/static/talks/bed/ui/default/bodybg.gif | Bin 0 -> 10119 bytes _build/static/talks/bed/ui/default/framing.css | 23 + _build/static/talks/bed/ui/default/iepngfix.htc | 42 + _build/static/talks/bed/ui/default/opera.css | 7 + _build/static/talks/bed/ui/default/outline.css | 15 + _build/static/talks/bed/ui/default/pretty.css | 255 + _build/static/talks/bed/ui/default/print.css | 1 + _build/static/talks/bed/ui/default/s5-core.css | 9 + _build/static/talks/bed/ui/default/slides.css | 3 + _build/static/talks/bed/ui/default/slides.js | 545 + _build/static/talks/bed/ui/img/footer_bg.png | Bin 0 -> 978 bytes _build/static/talks/bed/ui/img/footer_logo.png | Bin 0 -> 2314 bytes _build/static/talks/bed/ui/img/footer_shadow.png | Bin 0 -> 949 bytes _build/static/talks/bed/ui/img/logo.png | Bin 0 -> 4379 bytes _build/static/talks/bed/ui/img/logo.svg | 44 + _build/static/talks/bed/ui/sh/sh99s.css | 341 + _build/static/talks/bed/ui/sh/shBrushErlang.js | 52 + _build/static/talks/bed/ui/sh/shBrushJScript.js | 52 + _build/static/talks/bed/ui/sh/shBrushXml.js | 69 + _build/static/talks/bed/ui/sh/shCore.js | 17 + _build/static/talks/beyond-otp/beyond-otp.html | 562 + .../static/talks/beyond-otp/ui/default/blank.gif | Bin 0 -> 49 bytes .../static/talks/beyond-otp/ui/default/bodybg.gif | Bin 0 -> 10119 bytes .../static/talks/beyond-otp/ui/default/framing.css | 23 + .../talks/beyond-otp/ui/default/iepngfix.htc | 42 + .../static/talks/beyond-otp/ui/default/opera.css | 7 + .../static/talks/beyond-otp/ui/default/outline.css | 15 + .../static/talks/beyond-otp/ui/default/pretty.css | 255 + .../static/talks/beyond-otp/ui/default/print.css | 1 + .../static/talks/beyond-otp/ui/default/s5-core.css | 9 + .../static/talks/beyond-otp/ui/default/slides.css | 3 + .../static/talks/beyond-otp/ui/default/slides.js | 545 + .../static/talks/beyond-otp/ui/img/footer_bg.png | Bin 0 -> 978 bytes .../static/talks/beyond-otp/ui/img/footer_logo.png | Bin 0 -> 2314 bytes .../talks/beyond-otp/ui/img/footer_shadow.png | Bin 0 -> 949 bytes _build/static/talks/beyond-otp/ui/img/logo.png | Bin 0 -> 4379 bytes _build/static/talks/beyond-otp/ui/img/logo.svg | 44 + _build/static/talks/beyond-otp/ui/sh/sh99s.css | 341 + .../static/talks/beyond-otp/ui/sh/shBrushErlang.js | 52 + _build/static/talks/beyond-otp/ui/sh/shCore.js | 17 + _build/static/talks/cowboy-0.8/cowboy-0.8.html | 612 + _build/static/talks/cowboy-0.8/pics/adgear.png | Bin 0 -> 74256 bytes _build/static/talks/cowboy-0.8/pics/cowboy.png | Bin 0 -> 178106 bytes .../talks/cowboy-0.8/pics/popularity-feb-2013.png | Bin 0 -> 25896 bytes .../static/talks/cowboy-0.8/ui/default/blank.gif | Bin 0 -> 49 bytes .../static/talks/cowboy-0.8/ui/default/bodybg.gif | Bin 0 -> 10119 bytes .../static/talks/cowboy-0.8/ui/default/framing.css | 23 + .../talks/cowboy-0.8/ui/default/iepngfix.htc | 42 + .../static/talks/cowboy-0.8/ui/default/opera.css | 7 + .../static/talks/cowboy-0.8/ui/default/outline.css | 15 + .../static/talks/cowboy-0.8/ui/default/pretty.css | 254 + .../static/talks/cowboy-0.8/ui/default/print.css | 1 + .../static/talks/cowboy-0.8/ui/default/s5-core.css | 9 + .../static/talks/cowboy-0.8/ui/default/slides.css | 3 + .../static/talks/cowboy-0.8/ui/default/slides.js | 545 + .../static/talks/cowboy-0.8/ui/img/footer_bg.png | Bin 0 -> 978 bytes .../static/talks/cowboy-0.8/ui/img/footer_logo.png | Bin 0 -> 2314 bytes .../talks/cowboy-0.8/ui/img/footer_shadow.png | Bin 0 -> 949 bytes _build/static/talks/cowboy-0.8/ui/img/logo.png | Bin 0 -> 4379 bytes _build/static/talks/cowboy-0.8/ui/img/logo.svg | 44 + _build/static/talks/cowboy-2/CONTRIBUTING.md | 23 + _build/static/talks/cowboy-2/Gruntfile.js | 170 + _build/static/talks/cowboy-2/LICENSE | 19 + _build/static/talks/cowboy-2/README.md | 1050 ++ _build/static/talks/cowboy-2/css/print/paper.css | 202 + _build/static/talks/cowboy-2/css/print/pdf.css | 157 + _build/static/talks/cowboy-2/css/reveal.css | 1175 ++ _build/static/talks/cowboy-2/css/reveal.scss | 1319 ++ _build/static/talks/cowboy-2/css/theme/README.md | 23 + _build/static/talks/cowboy-2/css/theme/beige.css | 271 + _build/static/talks/cowboy-2/css/theme/black.css | 267 + _build/static/talks/cowboy-2/css/theme/blood.css | 285 + _build/static/talks/cowboy-2/css/theme/league.css | 273 + _build/static/talks/cowboy-2/css/theme/moon.css | 271 + _build/static/talks/cowboy-2/css/theme/night.css | 265 + _build/static/talks/cowboy-2/css/theme/serif.css | 267 + _build/static/talks/cowboy-2/css/theme/simple.css | 267 + _build/static/talks/cowboy-2/css/theme/sky.css | 274 + .../static/talks/cowboy-2/css/theme/solarized.css | 271 + .../talks/cowboy-2/css/theme/source/beige.scss | 39 + .../talks/cowboy-2/css/theme/source/black.scss | 49 + .../talks/cowboy-2/css/theme/source/blood.scss | 79 + .../talks/cowboy-2/css/theme/source/league.scss | 34 + .../talks/cowboy-2/css/theme/source/moon.scss | 57 + .../talks/cowboy-2/css/theme/source/night.scss | 35 + .../talks/cowboy-2/css/theme/source/serif.scss | 35 + .../talks/cowboy-2/css/theme/source/simple.scss | 38 + .../talks/cowboy-2/css/theme/source/sky.scss | 46 + .../talks/cowboy-2/css/theme/source/solarized.scss | 63 + .../talks/cowboy-2/css/theme/source/white.scss | 49 + .../talks/cowboy-2/css/theme/template/mixins.scss | 29 + .../cowboy-2/css/theme/template/settings.scss | 43 + .../talks/cowboy-2/css/theme/template/theme.scss | 349 + _build/static/talks/cowboy-2/css/theme/white.css | 267 + _build/static/talks/cowboy-2/index.html | 644 + _build/static/talks/cowboy-2/js/reveal.js | 4508 ++++++ _build/static/talks/cowboy-2/lib/css/zenburn.css | 117 + .../talks/cowboy-2/lib/font/league-gothic/LICENSE | 2 + .../lib/font/league-gothic/league-gothic.css | 10 + .../lib/font/league-gothic/league-gothic.eot | Bin 0 -> 25696 bytes .../lib/font/league-gothic/league-gothic.ttf | Bin 0 -> 64256 bytes .../lib/font/league-gothic/league-gothic.woff | Bin 0 -> 30764 bytes .../cowboy-2/lib/font/source-sans-pro/LICENSE | 45 + .../source-sans-pro/source-sans-pro-italic.eot | Bin 0 -> 75720 bytes .../source-sans-pro/source-sans-pro-italic.ttf | Bin 0 -> 238084 bytes .../source-sans-pro/source-sans-pro-italic.woff | Bin 0 -> 98556 bytes .../source-sans-pro/source-sans-pro-regular.eot | Bin 0 -> 88070 bytes .../source-sans-pro/source-sans-pro-regular.ttf | Bin 0 -> 288008 bytes .../source-sans-pro/source-sans-pro-regular.woff | Bin 0 -> 114324 bytes .../source-sans-pro/source-sans-pro-semibold.eot | Bin 0 -> 89897 bytes .../source-sans-pro/source-sans-pro-semibold.ttf | Bin 0 -> 284640 bytes .../source-sans-pro/source-sans-pro-semibold.woff | Bin 0 -> 115648 bytes .../source-sans-pro-semibolditalic.eot | Bin 0 -> 75706 bytes .../source-sans-pro-semibolditalic.ttf | Bin 0 -> 240944 bytes .../source-sans-pro-semibolditalic.woff | Bin 0 -> 98816 bytes .../lib/font/source-sans-pro/source-sans-pro.css | 39 + _build/static/talks/cowboy-2/lib/js/classList.js | 2 + _build/static/talks/cowboy-2/lib/js/head.min.js | 8 + _build/static/talks/cowboy-2/lib/js/html5shiv.js | 7 + _build/static/talks/cowboy-2/package.json | 49 + .../talks/cowboy-2/plugin/highlight/highlight.js | 30 + _build/static/talks/cowboy-2/plugin/leap/leap.js | 159 + .../talks/cowboy-2/plugin/markdown/example.html | 129 + .../talks/cowboy-2/plugin/markdown/example.md | 31 + .../talks/cowboy-2/plugin/markdown/markdown.js | 393 + .../talks/cowboy-2/plugin/markdown/marked.js | 6 + _build/static/talks/cowboy-2/plugin/math/math.js | 64 + .../talks/cowboy-2/plugin/multiplex/client.js | 13 + .../talks/cowboy-2/plugin/multiplex/index.js | 56 + .../talks/cowboy-2/plugin/multiplex/master.js | 51 + .../talks/cowboy-2/plugin/notes-server/client.js | 60 + .../talks/cowboy-2/plugin/notes-server/index.js | 66 + .../talks/cowboy-2/plugin/notes-server/notes.html | 396 + .../static/talks/cowboy-2/plugin/notes/notes.html | 406 + _build/static/talks/cowboy-2/plugin/notes/notes.js | 122 + .../talks/cowboy-2/plugin/print-pdf/print-pdf.js | 48 + .../talks/cowboy-2/plugin/remotes/remotes.js | 39 + .../static/talks/cowboy-2/plugin/search/search.js | 196 + .../static/talks/cowboy-2/plugin/zoom-js/zoom.js | 278 + .../talks/cowboy-2/test/examples/assets/image1.png | Bin 0 -> 21991 bytes .../talks/cowboy-2/test/examples/assets/image2.png | Bin 0 -> 10237 bytes .../talks/cowboy-2/test/examples/barebones.html | 41 + .../cowboy-2/test/examples/embedded-media.html | 49 + .../static/talks/cowboy-2/test/examples/math.html | 185 + .../cowboy-2/test/examples/slide-backgrounds.html | 144 + .../cowboy-2/test/examples/slide-transitions.html | 101 + _build/static/talks/cowboy-2/test/qunit-1.12.0.css | 244 + _build/static/talks/cowboy-2/test/qunit-1.12.0.js | 2212 +++ .../test/test-markdown-element-attributes.html | 134 + .../test/test-markdown-element-attributes.js | 46 + .../test/test-markdown-slide-attributes.html | 128 + .../test/test-markdown-slide-attributes.js | 47 + .../static/talks/cowboy-2/test/test-markdown.html | 52 + _build/static/talks/cowboy-2/test/test-markdown.js | 15 + _build/static/talks/cowboy-2/test/test-pdf.html | 83 + _build/static/talks/cowboy-2/test/test-pdf.js | 15 + _build/static/talks/cowboy-2/test/test.html | 85 + _build/static/talks/cowboy-2/test/test.js | 589 + _build/static/talks/cowboy-d3/cowboy-d3.html | 565 + _build/static/talks/cowboy-d3/ui/default/blank.gif | Bin 0 -> 49 bytes .../static/talks/cowboy-d3/ui/default/bodybg.gif | Bin 0 -> 10119 bytes .../static/talks/cowboy-d3/ui/default/framing.css | 23 + .../static/talks/cowboy-d3/ui/default/iepngfix.htc | 42 + _build/static/talks/cowboy-d3/ui/default/opera.css | 7 + .../static/talks/cowboy-d3/ui/default/outline.css | 15 + .../static/talks/cowboy-d3/ui/default/pretty.css | 255 + _build/static/talks/cowboy-d3/ui/default/print.css | 1 + .../static/talks/cowboy-d3/ui/default/s5-core.css | 9 + .../static/talks/cowboy-d3/ui/default/slides.css | 3 + _build/static/talks/cowboy-d3/ui/default/slides.js | 545 + _build/static/talks/cowboy-d3/ui/img/footer_bg.png | Bin 0 -> 978 bytes .../static/talks/cowboy-d3/ui/img/footer_logo.png | Bin 0 -> 2314 bytes .../talks/cowboy-d3/ui/img/footer_shadow.png | Bin 0 -> 949 bytes _build/static/talks/cowboy-d3/ui/img/logo.png | Bin 0 -> 4379 bytes _build/static/talks/cowboy-d3/ui/img/logo.svg | 44 + _build/static/talks/cowboy-d3/ui/sh/sh99s.css | 341 + .../static/talks/cowboy-d3/ui/sh/shBrushErlang.js | 52 + .../static/talks/cowboy-d3/ui/sh/shBrushJScript.js | 52 + _build/static/talks/cowboy-d3/ui/sh/shBrushXml.js | 69 + _build/static/talks/cowboy-d3/ui/sh/shCore.js | 17 + .../talks/cowboy-websocket/cowboy-websocket.html | 159 + .../talks/cowboy-websocket/ui/default/blank.gif | Bin 0 -> 49 bytes .../talks/cowboy-websocket/ui/default/bodybg.gif | Bin 0 -> 10119 bytes .../talks/cowboy-websocket/ui/default/framing.css | 23 + .../talks/cowboy-websocket/ui/default/iepngfix.htc | 42 + .../talks/cowboy-websocket/ui/default/opera.css | 7 + .../talks/cowboy-websocket/ui/default/outline.css | 15 + .../talks/cowboy-websocket/ui/default/pretty.css | 254 + .../talks/cowboy-websocket/ui/default/print.css | 1 + .../talks/cowboy-websocket/ui/default/s5-core.css | 9 + .../talks/cowboy-websocket/ui/default/slides.css | 3 + .../talks/cowboy-websocket/ui/default/slides.js | 545 + .../talks/cowboy-websocket/ui/img/footer_bg.png | Bin 0 -> 978 bytes .../talks/cowboy-websocket/ui/img/footer_logo.png | Bin 0 -> 2314 bytes .../cowboy-websocket/ui/img/footer_shadow.png | Bin 0 -> 949 bytes .../static/talks/cowboy-websocket/ui/img/logo.png | Bin 0 -> 4379 bytes .../static/talks/cowboy-websocket/ui/img/logo.svg | 44 + _build/static/talks/cowboy/Makefile | 6 + _build/static/talks/cowboy/all.ld | 14327 +++++++++++++++++++ _build/static/talks/cowboy/all.lt | 664 + _build/static/talks/cowboy/lout.li | 1179 ++ _build/static/talks/cowboy/myslides | 412 + .../talks/erlang-cowboy/erlang-cowboy-fr-unis.html | 469 + .../talks/erlang-cowboy/ui/default/blank.gif | Bin 0 -> 49 bytes .../talks/erlang-cowboy/ui/default/bodybg.gif | Bin 0 -> 10119 bytes .../talks/erlang-cowboy/ui/default/framing.css | 23 + .../talks/erlang-cowboy/ui/default/iepngfix.htc | 42 + .../talks/erlang-cowboy/ui/default/opera.css | 7 + .../talks/erlang-cowboy/ui/default/outline.css | 15 + .../talks/erlang-cowboy/ui/default/pretty.css | 254 + .../talks/erlang-cowboy/ui/default/print.css | 1 + .../talks/erlang-cowboy/ui/default/s5-core.css | 9 + .../talks/erlang-cowboy/ui/default/slides.css | 3 + .../talks/erlang-cowboy/ui/default/slides.js | 545 + .../talks/erlang-cowboy/ui/img/footer_bg.png | Bin 0 -> 978 bytes .../talks/erlang-cowboy/ui/img/footer_logo.png | Bin 0 -> 2314 bytes .../talks/erlang-cowboy/ui/img/footer_shadow.png | Bin 0 -> 949 bytes _build/static/talks/erlang-cowboy/ui/img/logo.png | Bin 0 -> 4379 bytes _build/static/talks/erlang-cowboy/ui/img/logo.svg | 44 + .../erlang-tokyo-2012-09/erlang-tokyo-2012-09.html | 244 + .../talks/erlang-tokyo-2012-09/pics/bullet.png | Bin 0 -> 60504 bytes .../talks/erlang-tokyo-2012-09/pics/cowboy.png | Bin 0 -> 178106 bytes .../erlang-tokyo-2012-09/ui/default/blank.gif | Bin 0 -> 49 bytes .../erlang-tokyo-2012-09/ui/default/bodybg.gif | Bin 0 -> 10119 bytes .../erlang-tokyo-2012-09/ui/default/framing.css | 23 + .../erlang-tokyo-2012-09/ui/default/iepngfix.htc | 42 + .../erlang-tokyo-2012-09/ui/default/opera.css | 7 + .../erlang-tokyo-2012-09/ui/default/outline.css | 15 + .../erlang-tokyo-2012-09/ui/default/pretty.css | 254 + .../erlang-tokyo-2012-09/ui/default/print.css | 1 + .../erlang-tokyo-2012-09/ui/default/s5-core.css | 9 + .../erlang-tokyo-2012-09/ui/default/slides.css | 3 + .../erlang-tokyo-2012-09/ui/default/slides.js | 545 + .../erlang-tokyo-2012-09/ui/img/footer_bg.png | Bin 0 -> 978 bytes .../erlang-tokyo-2012-09/ui/img/footer_logo.png | Bin 0 -> 2314 bytes .../erlang-tokyo-2012-09/ui/img/footer_shadow.png | Bin 0 -> 949 bytes .../talks/erlang-tokyo-2012-09/ui/img/logo.png | Bin 0 -> 4379 bytes .../talks/erlang-tokyo-2012-09/ui/img/logo.svg | 44 + _build/static/talks/farwest/farwest.html | 438 + _build/static/talks/farwest/ui/default/blank.gif | Bin 0 -> 49 bytes _build/static/talks/farwest/ui/default/bodybg.gif | Bin 0 -> 10119 bytes _build/static/talks/farwest/ui/default/framing.css | 23 + .../static/talks/farwest/ui/default/iepngfix.htc | 42 + _build/static/talks/farwest/ui/default/opera.css | 7 + _build/static/talks/farwest/ui/default/outline.css | 15 + _build/static/talks/farwest/ui/default/pretty.css | 254 + _build/static/talks/farwest/ui/default/print.css | 1 + _build/static/talks/farwest/ui/default/s5-core.css | 9 + _build/static/talks/farwest/ui/default/slides.css | 3 + _build/static/talks/farwest/ui/default/slides.js | 545 + _build/static/talks/farwest/ui/img/footer_bg.png | Bin 0 -> 978 bytes _build/static/talks/farwest/ui/img/footer_logo.png | Bin 0 -> 2314 bytes .../static/talks/farwest/ui/img/footer_shadow.png | Bin 0 -> 949 bytes _build/static/talks/farwest/ui/img/logo.png | Bin 0 -> 4379 bytes _build/static/talks/farwest/ui/img/logo.svg | 44 + _build/static/talks/oscon2012/oscon2012.html | 583 + _build/static/talks/oscon2012/pics/cowboy.png | Bin 0 -> 2100459 bytes .../static/talks/oscon2012/pics/erlang_movie.jpg | Bin 0 -> 521473 bytes _build/static/talks/oscon2012/pics/hello_world.png | Bin 0 -> 24660 bytes _build/static/talks/oscon2012/pics/horse.png | Bin 0 -> 601945 bytes _build/static/talks/oscon2012/pics/php_fcgi.png | Bin 0 -> 12538 bytes .../static/talks/oscon2012/pics/raspberry_pi.png | Bin 0 -> 24049 bytes _build/static/talks/oscon2012/pics/real_load.png | Bin 0 -> 64918 bytes _build/static/talks/oscon2012/pics/static.png | Bin 0 -> 30282 bytes _build/static/talks/oscon2012/pics/web_today.gif | Bin 0 -> 86733 bytes .../static/talks/oscon2012/pics/web_yesterday.gif | Bin 0 -> 36942 bytes _build/static/talks/oscon2012/pics/wsdemo.png | Bin 0 -> 70602 bytes _build/static/talks/oscon2012/ui/default/blank.gif | Bin 0 -> 49 bytes .../static/talks/oscon2012/ui/default/bodybg.gif | Bin 0 -> 10119 bytes .../static/talks/oscon2012/ui/default/framing.css | 23 + .../static/talks/oscon2012/ui/default/iepngfix.htc | 42 + _build/static/talks/oscon2012/ui/default/opera.css | 7 + .../static/talks/oscon2012/ui/default/outline.css | 15 + .../static/talks/oscon2012/ui/default/pretty.css | 254 + _build/static/talks/oscon2012/ui/default/print.css | 1 + .../static/talks/oscon2012/ui/default/s5-core.css | 9 + .../static/talks/oscon2012/ui/default/slides.css | 3 + _build/static/talks/oscon2012/ui/default/slides.js | 545 + _build/static/talks/oscon2012/ui/img/footer_bg.png | Bin 0 -> 978 bytes .../static/talks/oscon2012/ui/img/footer_logo.png | Bin 0 -> 2314 bytes .../talks/oscon2012/ui/img/footer_shadow.png | Bin 0 -> 949 bytes _build/static/talks/oscon2012/ui/img/logo.png | Bin 0 -> 4379 bytes _build/static/talks/oscon2012/ui/img/logo.svg | 44 + .../static/talks/ranch-msgpack/ranch-msgpack.html | 170 + .../talks/ranch-msgpack/ui/default/blank.gif | Bin 0 -> 49 bytes .../talks/ranch-msgpack/ui/default/bodybg.gif | Bin 0 -> 10119 bytes .../talks/ranch-msgpack/ui/default/framing.css | 23 + .../talks/ranch-msgpack/ui/default/iepngfix.htc | 42 + .../talks/ranch-msgpack/ui/default/opera.css | 7 + .../talks/ranch-msgpack/ui/default/outline.css | 15 + .../talks/ranch-msgpack/ui/default/pretty.css | 254 + .../talks/ranch-msgpack/ui/default/print.css | 1 + .../talks/ranch-msgpack/ui/default/s5-core.css | 9 + .../talks/ranch-msgpack/ui/default/slides.css | 3 + .../talks/ranch-msgpack/ui/default/slides.js | 545 + .../talks/ranch-msgpack/ui/img/footer_bg.png | Bin 0 -> 978 bytes .../talks/ranch-msgpack/ui/img/footer_logo.png | Bin 0 -> 2314 bytes .../talks/ranch-msgpack/ui/img/footer_shadow.png | Bin 0 -> 949 bytes _build/static/talks/ranch-msgpack/ui/img/logo.png | Bin 0 -> 4379 bytes _build/static/talks/ranch-msgpack/ui/img/logo.svg | 44 + .../reverse-engineering/reverse-engineering.html | 483 + .../talks/reverse-engineering/ui/default/blank.gif | Bin 0 -> 49 bytes .../reverse-engineering/ui/default/bodybg.gif | Bin 0 -> 10119 bytes .../reverse-engineering/ui/default/framing.css | 23 + .../reverse-engineering/ui/default/iepngfix.htc | 42 + .../talks/reverse-engineering/ui/default/opera.css | 7 + .../reverse-engineering/ui/default/outline.css | 15 + .../reverse-engineering/ui/default/pretty.css | 254 + .../talks/reverse-engineering/ui/default/print.css | 1 + .../reverse-engineering/ui/default/s5-core.css | 9 + .../reverse-engineering/ui/default/slides.css | 3 + .../talks/reverse-engineering/ui/default/slides.js | 545 + .../talks/reverse-engineering/ui/img/footer_bg.png | Bin 0 -> 978 bytes .../reverse-engineering/ui/img/footer_logo.png | Bin 0 -> 2314 bytes .../reverse-engineering/ui/img/footer_shadow.png | Bin 0 -> 949 bytes .../talks/reverse-engineering/ui/img/logo.png | Bin 0 -> 4379 bytes .../talks/reverse-engineering/ui/img/logo.svg | 44 + _build/static/talks/sheriff/Makefile | 6 + _build/static/talks/sheriff/all.ld | 7965 +++++++++++ _build/static/talks/sheriff/all.lt | 426 + _build/static/talks/sheriff/badge.eps | 2957 ++++ _build/static/talks/sheriff/lout.li | 605 + _build/static/talks/sheriff/myslides | 412 + _build/static/talks/sheriff/wilza.eps | 4232 ++++++ .../pics/building_blocks_code.png | Bin 0 -> 34623 bytes .../pics/building_blocks_code.svg | 233 + .../pics/building_blocks_data.png | Bin 0 -> 43175 bytes .../pics/building_blocks_data.svg | 243 + .../thinking-in-erlang/pics/links_crash_1.png | Bin 0 -> 23545 bytes .../thinking-in-erlang/pics/links_crash_1.svg | 231 + .../thinking-in-erlang/pics/links_crash_2.png | Bin 0 -> 27557 bytes .../thinking-in-erlang/pics/links_crash_2.svg | 227 + .../thinking-in-erlang/pics/links_trap_exit_1.png | Bin 0 -> 26560 bytes .../thinking-in-erlang/pics/links_trap_exit_1.svg | 231 + .../thinking-in-erlang/pics/links_trap_exit_2.png | Bin 0 -> 22228 bytes .../thinking-in-erlang/pics/links_trap_exit_2.svg | 203 + .../thinking-in-erlang/thinking-in-erlang.html | 1624 +++ .../talks/thinking-in-erlang/ui/default/blank.gif | Bin 0 -> 49 bytes .../talks/thinking-in-erlang/ui/default/bodybg.gif | Bin 0 -> 10119 bytes .../thinking-in-erlang/ui/default/framing.css | 23 + .../thinking-in-erlang/ui/default/iepngfix.htc | 42 + .../talks/thinking-in-erlang/ui/default/opera.css | 7 + .../thinking-in-erlang/ui/default/outline.css | 15 + .../talks/thinking-in-erlang/ui/default/pretty.css | 255 + .../talks/thinking-in-erlang/ui/default/print.css | 1 + .../thinking-in-erlang/ui/default/s5-core.css | 9 + .../talks/thinking-in-erlang/ui/default/slides.css | 3 + .../talks/thinking-in-erlang/ui/default/slides.js | 545 + .../talks/thinking-in-erlang/ui/img/footer_bg.png | Bin 0 -> 978 bytes .../thinking-in-erlang/ui/img/footer_logo.png | Bin 0 -> 2314 bytes .../thinking-in-erlang/ui/img/footer_shadow.png | Bin 0 -> 949 bytes .../talks/thinking-in-erlang/ui/img/logo.png | Bin 0 -> 4379 bytes .../talks/thinking-in-erlang/ui/img/logo.svg | 44 + .../talks/thinking-in-erlang/ui/sh/sh99s.css | 341 + .../thinking-in-erlang/ui/sh/shBrushErlang.js | 52 + .../talks/thinking-in-erlang/ui/sh/shCore.js | 17 + _build/themes/ninenines/layouts/_default/li.html | 1 + .../themes/ninenines/layouts/_default/single.html | 12 + .../themes/ninenines/layouts/_default/summary.html | 18 + .../themes/ninenines/layouts/_default/terms.html | 19 + .../themes/ninenines/layouts/articles/single.html | 40 + .../ninenines/layouts/docs-index/single.html | 48 + _build/themes/ninenines/layouts/docs/single.html | 60 + _build/themes/ninenines/layouts/index.html | 83 + .../themes/ninenines/layouts/indexes/articles.html | 36 + .../themes/ninenines/layouts/partials/brand.html | 3 + .../ninenines/layouts/partials/copyright.html | 9 + .../themes/ninenines/layouts/partials/disqus.html | 19 + .../themes/ninenines/layouts/partials/footer.html | 26 + .../layouts/partials/google_analytics.html | 12 + _build/themes/ninenines/layouts/partials/head.html | 24 + .../themes/ninenines/layouts/partials/header.html | 39 + .../ninenines/layouts/partials/pagination.html | 11 + .../ninenines/layouts/partials/post_meta.html | 34 + .../ninenines/layouts/partials/prev_next_post.html | 18 + .../themes/ninenines/layouts/partials/social.html | 127 + .../themes/ninenines/layouts/services/single.html | 25 + .../ninenines/layouts/shortcodes/fluid_img.html | 7 + _build/themes/ninenines/layouts/talks/single.html | 44 + _build/themes/ninenines/layouts/taxonomy/tag.html | 14 + .../themes/ninenines/layouts/taxonomy/topic.html | 14 + _build/themes/ninenines/static/css/99s.css | 607 + .../themes/ninenines/static/css/bootstrap.min.css | 632 + _build/themes/ninenines/static/css/sh99s.css | 341 + _build/themes/ninenines/static/img/big_bullet.png | Bin 0 -> 934 bytes _build/themes/ninenines/static/img/body_bg.jpg | Bin 0 -> 8777 bytes .../themes/ninenines/static/img/container_bg.png | Bin 0 -> 977 bytes _build/themes/ninenines/static/img/footer_bg.png | Bin 0 -> 1104 bytes .../ninenines/static/img/footer_bg_light.png | Bin 0 -> 1948 bytes _build/themes/ninenines/static/img/footer_logo.png | Bin 0 -> 2314 bytes .../static/img/glyphicons-halflings-white.png | Bin 0 -> 4352 bytes .../ninenines/static/img/glyphicons-halflings.png | Bin 0 -> 4352 bytes _build/themes/ninenines/static/img/header_bg.jpg | Bin 0 -> 1545 bytes .../ninenines/static/img/header_bg_center.jpg | Bin 0 -> 6380 bytes .../themes/ninenines/static/img/header_center.jpg | Bin 0 -> 4389 bytes _build/themes/ninenines/static/img/header_line.png | Bin 0 -> 961 bytes .../ninenines/static/img/home/carousel_bg_blue.png | Bin 0 -> 7102 bytes .../static/img/home/carousel_light_effect.png | Bin 0 -> 19587 bytes .../ninenines/static/img/home/consulting_ico.jpg | Bin 0 -> 3647 bytes .../themes/ninenines/static/img/home/detail_bg.png | Bin 0 -> 949 bytes .../ninenines/static/img/home/support_ico.jpg | Bin 0 -> 3528 bytes .../ninenines/static/img/home/training_ico.jpg | Bin 0 -> 3281 bytes .../static/img/ico/apple-touch-icon-114.png | Bin 0 -> 5411 bytes .../static/img/ico/apple-touch-icon-57.png | Bin 0 -> 3218 bytes .../static/img/ico/apple-touch-icon-72.png | Bin 0 -> 3724 bytes _build/themes/ninenines/static/img/ico/favicon.ico | Bin 0 -> 1150 bytes _build/themes/ninenines/static/img/ico_github.png | Bin 0 -> 1491 bytes .../themes/ninenines/static/img/ico_github_alt.png | Bin 0 -> 1456 bytes .../themes/ninenines/static/img/ico_linkedin.png | Bin 0 -> 1531 bytes .../ninenines/static/img/ico_linkedin_alt.png | Bin 0 -> 1520 bytes _build/themes/ninenines/static/img/ico_mail.png | Bin 0 -> 1606 bytes .../themes/ninenines/static/img/ico_mail_alt.png | Bin 0 -> 1453 bytes .../themes/ninenines/static/img/ico_microblog.png | Bin 0 -> 1568 bytes .../ninenines/static/img/ico_microblog_alt.png | Bin 0 -> 1532 bytes _build/themes/ninenines/static/img/logo.png | Bin 0 -> 4379 bytes .../ninenines/static/img/projects/bullet-home.png | Bin 0 -> 60308 bytes .../ninenines/static/img/projects/cowboy-home.png | Bin 0 -> 178106 bytes .../ninenines/static/img/projects/cowlib-home.png | Bin 0 -> 128 bytes .../static/img/projects/erlang.mk-home.png | Bin 0 -> 128 bytes .../ninenines/static/img/projects/gun-home.png | Bin 0 -> 128 bytes .../ninenines/static/img/projects/ranch-home.png | Bin 0 -> 223464 bytes .../ninenines/static/img/projects/sheriff-home.png | Bin 0 -> 147818 bytes .../themes/ninenines/static/img/sponsors/kato.png | Bin 0 -> 11820 bytes .../ninenines/static/img/sponsors/shiguredo.png | Bin 0 -> 24602 bytes .../ninenines/static/img/sponsors/soundrop.png | Bin 0 -> 7376 bytes .../ninenines/static/js/bootstrap-carousel.js | 181 + .../ninenines/static/js/bootstrap-dropdown.js | 92 + _build/themes/ninenines/static/js/custom.js | 43 + _build/themes/ninenines/static/js/fuse.min.js | 9 + _build/themes/ninenines/static/js/shCore.js | 17 + .../ninenines/static/js/shlang/shBrushBash.js | 59 + .../ninenines/static/js/shlang/shBrushCpp.js | 97 + .../ninenines/static/js/shlang/shBrushErlang.js | 52 + .../ninenines/static/js/shlang/shBrushJScript.js | 52 + .../ninenines/static/js/shlang/shBrushPlain.js | 33 + _build/themes/ninenines/theme.toml | 5 + articles/cowboy2-qs/index.html | 308 + articles/erlang-scalability/index.html | 293 + articles/erlang-validate-utf8/index.html | 344 + articles/erlang.mk-and-relx/index.html | 271 + .../index.html | 172 + articles/erlanger-playbook/index.html | 225 + articles/farwest-funded/index.html | 180 + articles/index.html | 382 + articles/index.xml | 1919 +++ articles/january-2014-status/index.html | 299 + articles/on-open-source/index.html | 276 + articles/page/1/index.html | 1 + articles/ranch-ftp/index.html | 369 + articles/the-story-so-far/index.html | 383 + articles/tictactoe/index.html | 242 + articles/xerl-0.1-empty-modules/index.html | 297 + articles/xerl-0.2-two-modules/index.html | 302 + articles/xerl-0.3-atomic-expressions/index.html | 306 + articles/xerl-0.4-expression-separator/index.html | 211 + articles/xerl-0.5-intermediate-module/index.html | 289 + categories/index.html | 103 + css/99s.css | 607 + css/bootstrap.min.css | 632 + css/sh99s.css | 341 + docs/db.json | 1 + docs/en/cowboy/1.0/guide/architecture/index.html | 202 + docs/en/cowboy/1.0/guide/broken_clients/index.html | 212 + docs/en/cowboy/1.0/guide/cookies/index.html | 273 + .../cowboy/1.0/guide/erlang_beginners/index.html | 196 + docs/en/cowboy/1.0/guide/erlang_web/index.html | 248 + .../en/cowboy/1.0/guide/getting_started/index.html | 299 + docs/en/cowboy/1.0/guide/hooks/index.html | 239 + docs/en/cowboy/1.0/guide/http_handlers/index.html | 279 + docs/en/cowboy/1.0/guide/http_req_life/index.html | 251 + docs/en/cowboy/1.0/guide/http_req_resp.png | Bin 0 -> 33228 bytes docs/en/cowboy/1.0/guide/http_req_resp.svg | 558 + docs/en/cowboy/1.0/guide/index.html | 250 + docs/en/cowboy/1.0/guide/introduction/index.html | 212 + docs/en/cowboy/1.0/guide/loop_handlers/index.html | 264 + docs/en/cowboy/1.0/guide/middlewares/index.html | 226 + docs/en/cowboy/1.0/guide/modern_web/index.html | 282 + .../en/cowboy/1.0/guide/multipart_intro/index.html | 198 + docs/en/cowboy/1.0/guide/multipart_req/index.html | 261 + docs/en/cowboy/1.0/guide/req/index.html | 390 + docs/en/cowboy/1.0/guide/req_body/index.html | 296 + .../en/cowboy/1.0/guide/resource_design/index.html | 294 + docs/en/cowboy/1.0/guide/resp/index.html | 327 + docs/en/cowboy/1.0/guide/rest_cond.png | Bin 0 -> 111628 bytes docs/en/cowboy/1.0/guide/rest_cond.svg | 1656 +++ docs/en/cowboy/1.0/guide/rest_conneg.png | Bin 0 -> 78133 bytes docs/en/cowboy/1.0/guide/rest_conneg.svg | 1135 ++ docs/en/cowboy/1.0/guide/rest_delete.png | Bin 0 -> 122185 bytes docs/en/cowboy/1.0/guide/rest_delete.svg | 1718 +++ .../en/cowboy/1.0/guide/rest_flowcharts/index.html | 304 + docs/en/cowboy/1.0/guide/rest_get_head.png | Bin 0 -> 99942 bytes docs/en/cowboy/1.0/guide/rest_get_head.svg | 1523 ++ docs/en/cowboy/1.0/guide/rest_handlers/index.html | 289 + docs/en/cowboy/1.0/guide/rest_options.png | Bin 0 -> 8539 bytes docs/en/cowboy/1.0/guide/rest_options.svg | 387 + .../en/cowboy/1.0/guide/rest_principles/index.html | 238 + docs/en/cowboy/1.0/guide/rest_put_post_patch.png | Bin 0 -> 218656 bytes docs/en/cowboy/1.0/guide/rest_put_post_patch.svg | 2856 ++++ docs/en/cowboy/1.0/guide/rest_start.png | Bin 0 -> 118210 bytes docs/en/cowboy/1.0/guide/rest_start.svg | 1468 ++ docs/en/cowboy/1.0/guide/routing/index.html | 365 + .../en/cowboy/1.0/guide/static_handlers/index.html | 280 + .../cowboy/1.0/guide/upgrade_protocol/index.html | 200 + docs/en/cowboy/1.0/guide/ws_handlers/index.html | 327 + docs/en/cowboy/1.0/guide/ws_protocol/index.html | 194 + docs/en/cowboy/1.0/index.html | 1 + docs/en/cowboy/1.0/manual/cowboy/index.html | 273 + docs/en/cowboy/1.0/manual/cowboy_app/index.html | 188 + .../en/cowboy/1.0/manual/cowboy_handler/index.html | 199 + .../1.0/manual/cowboy_http_handler/index.html | 229 + .../1.0/manual/cowboy_loop_handler/index.html | 245 + .../cowboy/1.0/manual/cowboy_middleware/index.html | 213 + .../cowboy/1.0/manual/cowboy_protocol/index.html | 244 + docs/en/cowboy/1.0/manual/cowboy_req/index.html | 854 ++ docs/en/cowboy/1.0/manual/cowboy_rest/index.html | 698 + docs/en/cowboy/1.0/manual/cowboy_router/index.html | 247 + docs/en/cowboy/1.0/manual/cowboy_spdy/index.html | 212 + docs/en/cowboy/1.0/manual/cowboy_static/index.html | 194 + .../1.0/manual/cowboy_sub_protocol/index.html | 203 + .../cowboy/1.0/manual/cowboy_websocket/index.html | 208 + .../1.0/manual/cowboy_websocket_handler/index.html | 273 + .../cowboy/1.0/manual/http_status_codes/index.html | 305 + docs/en/cowboy/1.0/manual/index.html | 197 + docs/en/cowboy/2.0/guide/architecture.asciidoc | 48 + docs/en/cowboy/2.0/guide/architecture/index.html | 191 + docs/en/cowboy/2.0/guide/broken_clients.asciidoc | 61 + docs/en/cowboy/2.0/guide/broken_clients/index.html | 205 + docs/en/cowboy/2.0/guide/constraints.asciidoc | 54 + docs/en/cowboy/2.0/guide/constraints/index.html | 211 + docs/en/cowboy/2.0/guide/cookies.asciidoc | 163 + docs/en/cowboy/2.0/guide/cookies/index.html | 303 + docs/en/cowboy/2.0/guide/erlang_beginners.asciidoc | 36 + .../cowboy/2.0/guide/erlang_beginners/index.html | 175 + docs/en/cowboy/2.0/guide/erlang_web.asciidoc | 176 + docs/en/cowboy/2.0/guide/erlang_web/index.html | 300 + docs/en/cowboy/2.0/guide/getting_started.asciidoc | 141 + .../en/cowboy/2.0/guide/getting_started/index.html | 289 + docs/en/cowboy/2.0/guide/handlers.asciidoc | 105 + docs/en/cowboy/2.0/guide/handlers/index.html | 242 + docs/en/cowboy/2.0/guide/hooks.asciidoc | 46 + docs/en/cowboy/2.0/guide/hooks/index.html | 185 + docs/en/cowboy/2.0/guide/http_req_resp.png | Bin 0 -> 28370 bytes docs/en/cowboy/2.0/guide/http_req_resp.svg | 520 + docs/en/cowboy/2.0/guide/index.html | 326 + docs/en/cowboy/2.0/guide/introduction.asciidoc | 56 + docs/en/cowboy/2.0/guide/introduction/index.html | 193 + docs/en/cowboy/2.0/guide/loop_handlers.asciidoc | 146 + docs/en/cowboy/2.0/guide/loop_handlers/index.html | 284 + docs/en/cowboy/2.0/guide/middlewares.asciidoc | 69 + docs/en/cowboy/2.0/guide/middlewares/index.html | 228 + docs/en/cowboy/2.0/guide/modern_web.asciidoc | 200 + docs/en/cowboy/2.0/guide/modern_web/index.html | 329 + docs/en/cowboy/2.0/guide/multipart.asciidoc | 169 + docs/en/cowboy/2.0/guide/multipart/index.html | 305 + docs/en/cowboy/2.0/guide/overview.asciidoc | 150 + docs/en/cowboy/2.0/guide/overview/index.html | 285 + docs/en/cowboy/2.0/guide/req.asciidoc | 247 + docs/en/cowboy/2.0/guide/req/index.html | 443 + docs/en/cowboy/2.0/guide/req_body.asciidoc | 152 + docs/en/cowboy/2.0/guide/req_body/index.html | 312 + docs/en/cowboy/2.0/guide/resource_design.asciidoc | 221 + .../en/cowboy/2.0/guide/resource_design/index.html | 350 + docs/en/cowboy/2.0/guide/resp.asciidoc | 201 + docs/en/cowboy/2.0/guide/resp/index.html | 357 + docs/en/cowboy/2.0/guide/rest_cond.png | Bin 0 -> 111628 bytes docs/en/cowboy/2.0/guide/rest_cond.svg | 1656 +++ docs/en/cowboy/2.0/guide/rest_conneg.png | Bin 0 -> 78133 bytes docs/en/cowboy/2.0/guide/rest_conneg.svg | 1135 ++ docs/en/cowboy/2.0/guide/rest_delete.png | Bin 0 -> 122185 bytes docs/en/cowboy/2.0/guide/rest_delete.svg | 1718 +++ docs/en/cowboy/2.0/guide/rest_flowcharts.asciidoc | 248 + .../en/cowboy/2.0/guide/rest_flowcharts/index.html | 380 + docs/en/cowboy/2.0/guide/rest_get_head.png | Bin 0 -> 99942 bytes docs/en/cowboy/2.0/guide/rest_get_head.svg | 1523 ++ docs/en/cowboy/2.0/guide/rest_handlers.asciidoc | 133 + docs/en/cowboy/2.0/guide/rest_handlers/index.html | 231 + docs/en/cowboy/2.0/guide/rest_options.png | Bin 0 -> 8539 bytes docs/en/cowboy/2.0/guide/rest_options.svg | 387 + docs/en/cowboy/2.0/guide/rest_principles.asciidoc | 160 + .../en/cowboy/2.0/guide/rest_principles/index.html | 289 + docs/en/cowboy/2.0/guide/rest_put_post_patch.png | Bin 0 -> 218656 bytes docs/en/cowboy/2.0/guide/rest_put_post_patch.svg | 2856 ++++ docs/en/cowboy/2.0/guide/rest_start.png | Bin 0 -> 105640 bytes docs/en/cowboy/2.0/guide/rest_start.svg | 1356 ++ docs/en/cowboy/2.0/guide/routing.asciidoc | 224 + docs/en/cowboy/2.0/guide/routing/index.html | 397 + docs/en/cowboy/2.0/guide/static_files.asciidoc | 171 + docs/en/cowboy/2.0/guide/static_files/index.html | 316 + docs/en/cowboy/2.0/guide/sub_protocols.asciidoc | 68 + docs/en/cowboy/2.0/guide/sub_protocols/index.html | 206 + docs/en/cowboy/2.0/guide/ws_handlers.asciidoc | 196 + docs/en/cowboy/2.0/guide/ws_handlers/index.html | 339 + docs/en/cowboy/2.0/guide/ws_protocol.asciidoc | 43 + docs/en/cowboy/2.0/guide/ws_protocol/index.html | 182 + docs/en/cowboy/2.0/index.html | 1 + docs/en/cowboy/2.0/manual/cowboy/index.html | 328 + docs/en/cowboy/2.0/manual/cowboy_app/index.html | 171 + .../en/cowboy/2.0/manual/cowboy_handler/index.html | 365 + docs/en/cowboy/2.0/manual/cowboy_loop/index.html | 289 + .../cowboy/2.0/manual/cowboy_middleware/index.html | 230 + .../cowboy/2.0/manual/cowboy_protocol/index.html | 279 + docs/en/cowboy/2.0/manual/cowboy_req/index.html | 1423 ++ docs/en/cowboy/2.0/manual/cowboy_rest/index.html | 508 + docs/en/cowboy/2.0/manual/cowboy_router/index.html | 247 + docs/en/cowboy/2.0/manual/cowboy_static/index.html | 188 + .../2.0/manual/cowboy_sub_protocol/index.html | 224 + .../cowboy/2.0/manual/cowboy_websocket/index.html | 352 + .../cowboy/2.0/manual/http_status_codes/index.html | 407 + docs/en/cowboy/2.0/manual/index.html | 209 + docs/en/cowboy/HEAD/guide/index.html | 1 + docs/en/cowboy/HEAD/index.html | 1 + docs/en/cowboy/HEAD/manual/index.html | 1 + docs/en/cowboy/index.html | 1 + docs/en/erlang.mk/1/guide/app.asciidoc | 426 + docs/en/erlang.mk/1/guide/app/index.html | 699 + docs/en/erlang.mk/1/guide/asciidoc.asciidoc | 82 + docs/en/erlang.mk/1/guide/asciidoc/index.html | 230 + docs/en/erlang.mk/1/guide/ci.asciidoc | 6 + docs/en/erlang.mk/1/guide/ci/index.html | 137 + docs/en/erlang.mk/1/guide/common_test.asciidoc | 91 + docs/en/erlang.mk/1/guide/common_test/index.html | 249 + docs/en/erlang.mk/1/guide/compat.asciidoc | 90 + docs/en/erlang.mk/1/guide/compat/index.html | 220 + docs/en/erlang.mk/1/guide/contributing.asciidoc | 116 + docs/en/erlang.mk/1/guide/contributing/index.html | 261 + docs/en/erlang.mk/1/guide/coverage.asciidoc | 6 + docs/en/erlang.mk/1/guide/coverage/index.html | 137 + docs/en/erlang.mk/1/guide/deps.asciidoc | 472 + docs/en/erlang.mk/1/guide/deps/index.html | 768 + docs/en/erlang.mk/1/guide/dialyzer.asciidoc | 73 + docs/en/erlang.mk/1/guide/dialyzer/index.html | 207 + docs/en/erlang.mk/1/guide/edoc.asciidoc | 48 + docs/en/erlang.mk/1/guide/edoc/index.html | 193 + docs/en/erlang.mk/1/guide/escripts.asciidoc | 6 + docs/en/erlang.mk/1/guide/escripts/index.html | 137 + docs/en/erlang.mk/1/guide/eunit.asciidoc | 122 + docs/en/erlang.mk/1/guide/eunit/index.html | 279 + .../en/erlang.mk/1/guide/external_plugins.asciidoc | 77 + .../erlang.mk/1/guide/external_plugins/index.html | 215 + .../1/guide/external_plugins_list.asciidoc | 48 + .../1/guide/external_plugins_list/index.html | 197 + docs/en/erlang.mk/1/guide/getting_started.asciidoc | 299 + .../erlang.mk/1/guide/getting_started/index.html | 462 + docs/en/erlang.mk/1/guide/history.asciidoc | 66 + docs/en/erlang.mk/1/guide/history/index.html | 191 + docs/en/erlang.mk/1/guide/index.html | 298 + docs/en/erlang.mk/1/guide/installation.asciidoc | 124 + docs/en/erlang.mk/1/guide/installation/index.html | 256 + docs/en/erlang.mk/1/guide/limitations.asciidoc | 46 + docs/en/erlang.mk/1/guide/limitations/index.html | 179 + docs/en/erlang.mk/1/guide/overview.asciidoc | 87 + docs/en/erlang.mk/1/guide/overview/index.html | 224 + docs/en/erlang.mk/1/guide/ports.asciidoc | 100 + docs/en/erlang.mk/1/guide/ports/index.html | 288 + docs/en/erlang.mk/1/guide/releases.asciidoc | 70 + docs/en/erlang.mk/1/guide/releases/index.html | 221 + docs/en/erlang.mk/1/guide/shell.asciidoc | 46 + docs/en/erlang.mk/1/guide/shell/index.html | 193 + docs/en/erlang.mk/1/guide/updating.asciidoc | 63 + docs/en/erlang.mk/1/guide/updating/index.html | 198 + docs/en/erlang.mk/1/guide/why.asciidoc | 81 + docs/en/erlang.mk/1/guide/why/index.html | 216 + docs/en/erlang.mk/1/guide/xref.asciidoc | 6 + docs/en/erlang.mk/1/guide/xref/index.html | 137 + docs/en/erlang.mk/1/index.html | 1 + docs/en/erlang.mk/index.html | 1 + docs/en/gun/1.0/guide/connect.asciidoc | 154 + docs/en/gun/1.0/guide/connect/index.html | 302 + docs/en/gun/1.0/guide/http.asciidoc | 362 + docs/en/gun/1.0/guide/http/index.html | 515 + docs/en/gun/1.0/guide/index.html | 172 + docs/en/gun/1.0/guide/introduction.asciidoc | 28 + docs/en/gun/1.0/guide/introduction/index.html | 168 + docs/en/gun/1.0/guide/protocols.asciidoc | 119 + docs/en/gun/1.0/guide/protocols/index.html | 395 + docs/en/gun/1.0/guide/start.asciidoc | 67 + docs/en/gun/1.0/guide/start/index.html | 216 + docs/en/gun/1.0/guide/websocket.asciidoc | 112 + docs/en/gun/1.0/guide/websocket/index.html | 259 + docs/en/gun/1.0/index.html | 1 + docs/en/gun/1.0/manual/gun/index.html | 1734 +++ docs/en/gun/1.0/manual/gun_app/index.html | 168 + docs/en/gun/1.0/manual/index.html | 152 + docs/en/gun/index.html | 1 + docs/en/index.html | 1 + docs/en/ranch/1.2/guide/embedded.asciidoc | 48 + docs/en/ranch/1.2/guide/embedded/index.html | 182 + docs/en/ranch/1.2/guide/index.html | 182 + docs/en/ranch/1.2/guide/internals.asciidoc | 94 + docs/en/ranch/1.2/guide/internals/index.html | 227 + docs/en/ranch/1.2/guide/introduction.asciidoc | 25 + docs/en/ranch/1.2/guide/introduction/index.html | 166 + docs/en/ranch/1.2/guide/listeners.asciidoc | 251 + docs/en/ranch/1.2/guide/listeners/index.html | 421 + docs/en/ranch/1.2/guide/parsers.asciidoc | 92 + docs/en/ranch/1.2/guide/parsers/index.html | 243 + docs/en/ranch/1.2/guide/protocols.asciidoc | 125 + docs/en/ranch/1.2/guide/protocols/index.html | 263 + docs/en/ranch/1.2/guide/ssl_auth.asciidoc | 120 + docs/en/ranch/1.2/guide/ssl_auth/index.html | 292 + docs/en/ranch/1.2/guide/transports.asciidoc | 169 + docs/en/ranch/1.2/guide/transports/index.html | 323 + docs/en/ranch/1.2/index.html | 1 + docs/en/ranch/1.2/manual/index.html | 172 + docs/en/ranch/1.2/manual/ranch/index.html | 557 + docs/en/ranch/1.2/manual/ranch_app/index.html | 177 + docs/en/ranch/1.2/manual/ranch_protocol/index.html | 217 + docs/en/ranch/1.2/manual/ranch_ssl/index.html | 483 + docs/en/ranch/1.2/manual/ranch_tcp/index.html | 408 + .../en/ranch/1.2/manual/ranch_transport/index.html | 628 + docs/en/ranch/index.html | 1 + docs/index.html | 203 + docs/index.xml | 2001 +++ donate/index.html | 374 + img/big_bullet.png | Bin 0 -> 934 bytes img/body_bg.jpg | Bin 0 -> 8777 bytes img/container_bg.png | Bin 0 -> 977 bytes img/footer_bg.png | Bin 0 -> 1104 bytes img/footer_bg_light.png | Bin 0 -> 1948 bytes img/footer_logo.png | Bin 0 -> 2314 bytes img/glyphicons-halflings-white.png | Bin 0 -> 4352 bytes img/glyphicons-halflings.png | Bin 0 -> 4352 bytes img/header_bg.jpg | Bin 0 -> 1545 bytes img/header_bg_center.jpg | Bin 0 -> 6380 bytes img/header_center.jpg | Bin 0 -> 4389 bytes img/header_line.png | Bin 0 -> 961 bytes img/home/carousel_bg_blue.png | Bin 0 -> 7102 bytes img/home/carousel_light_effect.png | Bin 0 -> 19587 bytes img/home/consulting_ico.jpg | Bin 0 -> 3647 bytes img/home/detail_bg.png | Bin 0 -> 949 bytes img/home/support_ico.jpg | Bin 0 -> 3528 bytes img/home/training_ico.jpg | Bin 0 -> 3281 bytes img/ico/apple-touch-icon-114.png | Bin 0 -> 5411 bytes img/ico/apple-touch-icon-57.png | Bin 0 -> 3218 bytes img/ico/apple-touch-icon-72.png | Bin 0 -> 3724 bytes img/ico/favicon.ico | Bin 0 -> 1150 bytes img/ico_github.png | Bin 0 -> 1491 bytes img/ico_github_alt.png | Bin 0 -> 1456 bytes img/ico_linkedin.png | Bin 0 -> 1531 bytes img/ico_linkedin_alt.png | Bin 0 -> 1520 bytes img/ico_mail.png | Bin 0 -> 1606 bytes img/ico_mail_alt.png | Bin 0 -> 1453 bytes img/ico_microblog.png | Bin 0 -> 1568 bytes img/ico_microblog_alt.png | Bin 0 -> 1532 bytes img/logo.png | Bin 0 -> 4379 bytes img/projects/bullet-home.png | Bin 0 -> 60308 bytes img/projects/cowboy-home.png | Bin 0 -> 178106 bytes img/projects/cowlib-home.png | Bin 0 -> 128 bytes img/projects/erlang.mk-home.png | Bin 0 -> 128 bytes img/projects/gun-home.png | Bin 0 -> 128 bytes img/projects/ranch-home.png | Bin 0 -> 223464 bytes img/projects/sheriff-home.png | Bin 0 -> 147818 bytes img/sponsors/kato.png | Bin 0 -> 11820 bytes img/sponsors/shiguredo.png | Bin 0 -> 24602 bytes img/sponsors/soundrop.png | Bin 0 -> 7376 bytes index.html | 527 + index.xml | 1438 ++ js/bootstrap-carousel.js | 181 + js/bootstrap-dropdown.js | 92 + js/custom.js | 43 + js/fuse.min.js | 9 + js/shCore.js | 17 + js/shlang/shBrushBash.js | 59 + js/shlang/shBrushCpp.js | 97 + js/shlang/shBrushErlang.js | 52 + js/shlang/shBrushJScript.js | 52 + js/shlang/shBrushPlain.js | 33 + res/erlanger-preview.pdf | Bin 0 -> 118131 bytes res/tictactoe.erl | 89 + services/index.html | 459 + sitemap.xml | 496 + slogan/index.html | 101 + tags/index.html | 103 + talks/PDF/cowboy.pdf | Bin 0 -> 52395 bytes talks/PDF/sheriff.pdf | Bin 0 -> 58933 bytes talks/bed/bed.ezdoc | 432 + talks/bed/bed.html | 767 + talks/bed/pics/family_business.jpg | Bin 0 -> 52468 bytes talks/bed/pics/mind_blown.jpg | Bin 0 -> 144843 bytes talks/bed/pics/rest.jpg | Bin 0 -> 34610 bytes talks/bed/pics/wondering.jpg | Bin 0 -> 51067 bytes talks/bed/ui/default/blank.gif | Bin 0 -> 49 bytes talks/bed/ui/default/bodybg.gif | Bin 0 -> 10119 bytes talks/bed/ui/default/framing.css | 23 + talks/bed/ui/default/iepngfix.htc | 42 + talks/bed/ui/default/opera.css | 7 + talks/bed/ui/default/outline.css | 15 + talks/bed/ui/default/pretty.css | 255 + talks/bed/ui/default/print.css | 1 + talks/bed/ui/default/s5-core.css | 9 + talks/bed/ui/default/slides.css | 3 + talks/bed/ui/default/slides.js | 545 + talks/bed/ui/img/footer_bg.png | Bin 0 -> 978 bytes talks/bed/ui/img/footer_logo.png | Bin 0 -> 2314 bytes talks/bed/ui/img/footer_shadow.png | Bin 0 -> 949 bytes talks/bed/ui/img/logo.png | Bin 0 -> 4379 bytes talks/bed/ui/img/logo.svg | 44 + talks/bed/ui/sh/sh99s.css | 341 + talks/bed/ui/sh/shBrushErlang.js | 52 + talks/bed/ui/sh/shBrushJScript.js | 52 + talks/bed/ui/sh/shBrushXml.js | 69 + talks/bed/ui/sh/shCore.js | 17 + talks/beyond-otp/beyond-otp.html | 562 + talks/beyond-otp/ui/default/blank.gif | Bin 0 -> 49 bytes talks/beyond-otp/ui/default/bodybg.gif | Bin 0 -> 10119 bytes talks/beyond-otp/ui/default/framing.css | 23 + talks/beyond-otp/ui/default/iepngfix.htc | 42 + talks/beyond-otp/ui/default/opera.css | 7 + talks/beyond-otp/ui/default/outline.css | 15 + talks/beyond-otp/ui/default/pretty.css | 255 + talks/beyond-otp/ui/default/print.css | 1 + talks/beyond-otp/ui/default/s5-core.css | 9 + talks/beyond-otp/ui/default/slides.css | 3 + talks/beyond-otp/ui/default/slides.js | 545 + talks/beyond-otp/ui/img/footer_bg.png | Bin 0 -> 978 bytes talks/beyond-otp/ui/img/footer_logo.png | Bin 0 -> 2314 bytes talks/beyond-otp/ui/img/footer_shadow.png | Bin 0 -> 949 bytes talks/beyond-otp/ui/img/logo.png | Bin 0 -> 4379 bytes talks/beyond-otp/ui/img/logo.svg | 44 + talks/beyond-otp/ui/sh/sh99s.css | 341 + talks/beyond-otp/ui/sh/shBrushErlang.js | 52 + talks/beyond-otp/ui/sh/shCore.js | 17 + talks/cowboy-0.8/cowboy-0.8.html | 612 + talks/cowboy-0.8/pics/adgear.png | Bin 0 -> 74256 bytes talks/cowboy-0.8/pics/cowboy.png | Bin 0 -> 178106 bytes talks/cowboy-0.8/pics/popularity-feb-2013.png | Bin 0 -> 25896 bytes talks/cowboy-0.8/ui/default/blank.gif | Bin 0 -> 49 bytes talks/cowboy-0.8/ui/default/bodybg.gif | Bin 0 -> 10119 bytes talks/cowboy-0.8/ui/default/framing.css | 23 + talks/cowboy-0.8/ui/default/iepngfix.htc | 42 + talks/cowboy-0.8/ui/default/opera.css | 7 + talks/cowboy-0.8/ui/default/outline.css | 15 + talks/cowboy-0.8/ui/default/pretty.css | 254 + talks/cowboy-0.8/ui/default/print.css | 1 + talks/cowboy-0.8/ui/default/s5-core.css | 9 + talks/cowboy-0.8/ui/default/slides.css | 3 + talks/cowboy-0.8/ui/default/slides.js | 545 + talks/cowboy-0.8/ui/img/footer_bg.png | Bin 0 -> 978 bytes talks/cowboy-0.8/ui/img/footer_logo.png | Bin 0 -> 2314 bytes talks/cowboy-0.8/ui/img/footer_shadow.png | Bin 0 -> 949 bytes talks/cowboy-0.8/ui/img/logo.png | Bin 0 -> 4379 bytes talks/cowboy-0.8/ui/img/logo.svg | 44 + talks/cowboy-2/CONTRIBUTING.md | 23 + talks/cowboy-2/Gruntfile.js | 170 + talks/cowboy-2/LICENSE | 19 + talks/cowboy-2/README.md | 1050 ++ talks/cowboy-2/css/print/paper.css | 202 + talks/cowboy-2/css/print/pdf.css | 157 + talks/cowboy-2/css/reveal.css | 1175 ++ talks/cowboy-2/css/reveal.scss | 1319 ++ talks/cowboy-2/css/theme/README.md | 23 + talks/cowboy-2/css/theme/beige.css | 271 + talks/cowboy-2/css/theme/black.css | 267 + talks/cowboy-2/css/theme/blood.css | 285 + talks/cowboy-2/css/theme/league.css | 273 + talks/cowboy-2/css/theme/moon.css | 271 + talks/cowboy-2/css/theme/night.css | 265 + talks/cowboy-2/css/theme/serif.css | 267 + talks/cowboy-2/css/theme/simple.css | 267 + talks/cowboy-2/css/theme/sky.css | 274 + talks/cowboy-2/css/theme/solarized.css | 271 + talks/cowboy-2/css/theme/source/beige.scss | 39 + talks/cowboy-2/css/theme/source/black.scss | 49 + talks/cowboy-2/css/theme/source/blood.scss | 79 + talks/cowboy-2/css/theme/source/league.scss | 34 + talks/cowboy-2/css/theme/source/moon.scss | 57 + talks/cowboy-2/css/theme/source/night.scss | 35 + talks/cowboy-2/css/theme/source/serif.scss | 35 + talks/cowboy-2/css/theme/source/simple.scss | 38 + talks/cowboy-2/css/theme/source/sky.scss | 46 + talks/cowboy-2/css/theme/source/solarized.scss | 63 + talks/cowboy-2/css/theme/source/white.scss | 49 + talks/cowboy-2/css/theme/template/mixins.scss | 29 + talks/cowboy-2/css/theme/template/settings.scss | 43 + talks/cowboy-2/css/theme/template/theme.scss | 349 + talks/cowboy-2/css/theme/white.css | 267 + talks/cowboy-2/index.html | 644 + talks/cowboy-2/js/reveal.js | 4508 ++++++ talks/cowboy-2/lib/css/zenburn.css | 117 + talks/cowboy-2/lib/font/league-gothic/LICENSE | 2 + .../lib/font/league-gothic/league-gothic.css | 10 + .../lib/font/league-gothic/league-gothic.eot | Bin 0 -> 25696 bytes .../lib/font/league-gothic/league-gothic.ttf | Bin 0 -> 64256 bytes .../lib/font/league-gothic/league-gothic.woff | Bin 0 -> 30764 bytes talks/cowboy-2/lib/font/source-sans-pro/LICENSE | 45 + .../source-sans-pro/source-sans-pro-italic.eot | Bin 0 -> 75720 bytes .../source-sans-pro/source-sans-pro-italic.ttf | Bin 0 -> 238084 bytes .../source-sans-pro/source-sans-pro-italic.woff | Bin 0 -> 98556 bytes .../source-sans-pro/source-sans-pro-regular.eot | Bin 0 -> 88070 bytes .../source-sans-pro/source-sans-pro-regular.ttf | Bin 0 -> 288008 bytes .../source-sans-pro/source-sans-pro-regular.woff | Bin 0 -> 114324 bytes .../source-sans-pro/source-sans-pro-semibold.eot | Bin 0 -> 89897 bytes .../source-sans-pro/source-sans-pro-semibold.ttf | Bin 0 -> 284640 bytes .../source-sans-pro/source-sans-pro-semibold.woff | Bin 0 -> 115648 bytes .../source-sans-pro-semibolditalic.eot | Bin 0 -> 75706 bytes .../source-sans-pro-semibolditalic.ttf | Bin 0 -> 240944 bytes .../source-sans-pro-semibolditalic.woff | Bin 0 -> 98816 bytes .../lib/font/source-sans-pro/source-sans-pro.css | 39 + talks/cowboy-2/lib/js/classList.js | 2 + talks/cowboy-2/lib/js/head.min.js | 8 + talks/cowboy-2/lib/js/html5shiv.js | 7 + talks/cowboy-2/package.json | 49 + talks/cowboy-2/plugin/highlight/highlight.js | 30 + talks/cowboy-2/plugin/leap/leap.js | 159 + talks/cowboy-2/plugin/markdown/example.html | 129 + talks/cowboy-2/plugin/markdown/example.md | 31 + talks/cowboy-2/plugin/markdown/markdown.js | 393 + talks/cowboy-2/plugin/markdown/marked.js | 6 + talks/cowboy-2/plugin/math/math.js | 64 + talks/cowboy-2/plugin/multiplex/client.js | 13 + talks/cowboy-2/plugin/multiplex/index.js | 56 + talks/cowboy-2/plugin/multiplex/master.js | 51 + talks/cowboy-2/plugin/notes-server/client.js | 60 + talks/cowboy-2/plugin/notes-server/index.js | 66 + talks/cowboy-2/plugin/notes-server/notes.html | 396 + talks/cowboy-2/plugin/notes/notes.html | 406 + talks/cowboy-2/plugin/notes/notes.js | 122 + talks/cowboy-2/plugin/print-pdf/print-pdf.js | 48 + talks/cowboy-2/plugin/remotes/remotes.js | 39 + talks/cowboy-2/plugin/search/search.js | 196 + talks/cowboy-2/plugin/zoom-js/zoom.js | 278 + talks/cowboy-2/test/examples/assets/image1.png | Bin 0 -> 21991 bytes talks/cowboy-2/test/examples/assets/image2.png | Bin 0 -> 10237 bytes talks/cowboy-2/test/examples/barebones.html | 41 + talks/cowboy-2/test/examples/embedded-media.html | 49 + talks/cowboy-2/test/examples/math.html | 185 + .../cowboy-2/test/examples/slide-backgrounds.html | 144 + .../cowboy-2/test/examples/slide-transitions.html | 101 + talks/cowboy-2/test/qunit-1.12.0.css | 244 + talks/cowboy-2/test/qunit-1.12.0.js | 2212 +++ .../test/test-markdown-element-attributes.html | 134 + .../test/test-markdown-element-attributes.js | 46 + .../test/test-markdown-slide-attributes.html | 128 + .../test/test-markdown-slide-attributes.js | 47 + talks/cowboy-2/test/test-markdown.html | 52 + talks/cowboy-2/test/test-markdown.js | 15 + talks/cowboy-2/test/test-pdf.html | 83 + talks/cowboy-2/test/test-pdf.js | 15 + talks/cowboy-2/test/test.html | 85 + talks/cowboy-2/test/test.js | 589 + talks/cowboy-d3/cowboy-d3.html | 565 + talks/cowboy-d3/ui/default/blank.gif | Bin 0 -> 49 bytes talks/cowboy-d3/ui/default/bodybg.gif | Bin 0 -> 10119 bytes talks/cowboy-d3/ui/default/framing.css | 23 + talks/cowboy-d3/ui/default/iepngfix.htc | 42 + talks/cowboy-d3/ui/default/opera.css | 7 + talks/cowboy-d3/ui/default/outline.css | 15 + talks/cowboy-d3/ui/default/pretty.css | 255 + talks/cowboy-d3/ui/default/print.css | 1 + talks/cowboy-d3/ui/default/s5-core.css | 9 + talks/cowboy-d3/ui/default/slides.css | 3 + talks/cowboy-d3/ui/default/slides.js | 545 + talks/cowboy-d3/ui/img/footer_bg.png | Bin 0 -> 978 bytes talks/cowboy-d3/ui/img/footer_logo.png | Bin 0 -> 2314 bytes talks/cowboy-d3/ui/img/footer_shadow.png | Bin 0 -> 949 bytes talks/cowboy-d3/ui/img/logo.png | Bin 0 -> 4379 bytes talks/cowboy-d3/ui/img/logo.svg | 44 + talks/cowboy-d3/ui/sh/sh99s.css | 341 + talks/cowboy-d3/ui/sh/shBrushErlang.js | 52 + talks/cowboy-d3/ui/sh/shBrushJScript.js | 52 + talks/cowboy-d3/ui/sh/shBrushXml.js | 69 + talks/cowboy-d3/ui/sh/shCore.js | 17 + talks/cowboy-websocket/cowboy-websocket.html | 159 + talks/cowboy-websocket/ui/default/blank.gif | Bin 0 -> 49 bytes talks/cowboy-websocket/ui/default/bodybg.gif | Bin 0 -> 10119 bytes talks/cowboy-websocket/ui/default/framing.css | 23 + talks/cowboy-websocket/ui/default/iepngfix.htc | 42 + talks/cowboy-websocket/ui/default/opera.css | 7 + talks/cowboy-websocket/ui/default/outline.css | 15 + talks/cowboy-websocket/ui/default/pretty.css | 254 + talks/cowboy-websocket/ui/default/print.css | 1 + talks/cowboy-websocket/ui/default/s5-core.css | 9 + talks/cowboy-websocket/ui/default/slides.css | 3 + talks/cowboy-websocket/ui/default/slides.js | 545 + talks/cowboy-websocket/ui/img/footer_bg.png | Bin 0 -> 978 bytes talks/cowboy-websocket/ui/img/footer_logo.png | Bin 0 -> 2314 bytes talks/cowboy-websocket/ui/img/footer_shadow.png | Bin 0 -> 949 bytes talks/cowboy-websocket/ui/img/logo.png | Bin 0 -> 4379 bytes talks/cowboy-websocket/ui/img/logo.svg | 44 + talks/cowboy/Makefile | 6 + talks/cowboy/all.ld | 14327 +++++++++++++++++++ talks/cowboy/all.lt | 664 + talks/cowboy/lout.li | 1179 ++ talks/cowboy/myslides | 412 + talks/erlang-cowboy/erlang-cowboy-fr-unis.html | 469 + talks/erlang-cowboy/ui/default/blank.gif | Bin 0 -> 49 bytes talks/erlang-cowboy/ui/default/bodybg.gif | Bin 0 -> 10119 bytes talks/erlang-cowboy/ui/default/framing.css | 23 + talks/erlang-cowboy/ui/default/iepngfix.htc | 42 + talks/erlang-cowboy/ui/default/opera.css | 7 + talks/erlang-cowboy/ui/default/outline.css | 15 + talks/erlang-cowboy/ui/default/pretty.css | 254 + talks/erlang-cowboy/ui/default/print.css | 1 + talks/erlang-cowboy/ui/default/s5-core.css | 9 + talks/erlang-cowboy/ui/default/slides.css | 3 + talks/erlang-cowboy/ui/default/slides.js | 545 + talks/erlang-cowboy/ui/img/footer_bg.png | Bin 0 -> 978 bytes talks/erlang-cowboy/ui/img/footer_logo.png | Bin 0 -> 2314 bytes talks/erlang-cowboy/ui/img/footer_shadow.png | Bin 0 -> 949 bytes talks/erlang-cowboy/ui/img/logo.png | Bin 0 -> 4379 bytes talks/erlang-cowboy/ui/img/logo.svg | 44 + .../erlang-tokyo-2012-09/erlang-tokyo-2012-09.html | 244 + talks/erlang-tokyo-2012-09/pics/bullet.png | Bin 0 -> 60504 bytes talks/erlang-tokyo-2012-09/pics/cowboy.png | Bin 0 -> 178106 bytes talks/erlang-tokyo-2012-09/ui/default/blank.gif | Bin 0 -> 49 bytes talks/erlang-tokyo-2012-09/ui/default/bodybg.gif | Bin 0 -> 10119 bytes talks/erlang-tokyo-2012-09/ui/default/framing.css | 23 + talks/erlang-tokyo-2012-09/ui/default/iepngfix.htc | 42 + talks/erlang-tokyo-2012-09/ui/default/opera.css | 7 + talks/erlang-tokyo-2012-09/ui/default/outline.css | 15 + talks/erlang-tokyo-2012-09/ui/default/pretty.css | 254 + talks/erlang-tokyo-2012-09/ui/default/print.css | 1 + talks/erlang-tokyo-2012-09/ui/default/s5-core.css | 9 + talks/erlang-tokyo-2012-09/ui/default/slides.css | 3 + talks/erlang-tokyo-2012-09/ui/default/slides.js | 545 + talks/erlang-tokyo-2012-09/ui/img/footer_bg.png | Bin 0 -> 978 bytes talks/erlang-tokyo-2012-09/ui/img/footer_logo.png | Bin 0 -> 2314 bytes .../erlang-tokyo-2012-09/ui/img/footer_shadow.png | Bin 0 -> 949 bytes talks/erlang-tokyo-2012-09/ui/img/logo.png | Bin 0 -> 4379 bytes talks/erlang-tokyo-2012-09/ui/img/logo.svg | 44 + talks/farwest/farwest.html | 438 + talks/farwest/ui/default/blank.gif | Bin 0 -> 49 bytes talks/farwest/ui/default/bodybg.gif | Bin 0 -> 10119 bytes talks/farwest/ui/default/framing.css | 23 + talks/farwest/ui/default/iepngfix.htc | 42 + talks/farwest/ui/default/opera.css | 7 + talks/farwest/ui/default/outline.css | 15 + talks/farwest/ui/default/pretty.css | 254 + talks/farwest/ui/default/print.css | 1 + talks/farwest/ui/default/s5-core.css | 9 + talks/farwest/ui/default/slides.css | 3 + talks/farwest/ui/default/slides.js | 545 + talks/farwest/ui/img/footer_bg.png | Bin 0 -> 978 bytes talks/farwest/ui/img/footer_logo.png | Bin 0 -> 2314 bytes talks/farwest/ui/img/footer_shadow.png | Bin 0 -> 949 bytes talks/farwest/ui/img/logo.png | Bin 0 -> 4379 bytes talks/farwest/ui/img/logo.svg | 44 + talks/index.html | 152 + talks/oscon2012/oscon2012.html | 583 + talks/oscon2012/pics/cowboy.png | Bin 0 -> 2100459 bytes talks/oscon2012/pics/erlang_movie.jpg | Bin 0 -> 521473 bytes talks/oscon2012/pics/hello_world.png | Bin 0 -> 24660 bytes talks/oscon2012/pics/horse.png | Bin 0 -> 601945 bytes talks/oscon2012/pics/php_fcgi.png | Bin 0 -> 12538 bytes talks/oscon2012/pics/raspberry_pi.png | Bin 0 -> 24049 bytes talks/oscon2012/pics/real_load.png | Bin 0 -> 64918 bytes talks/oscon2012/pics/static.png | Bin 0 -> 30282 bytes talks/oscon2012/pics/web_today.gif | Bin 0 -> 86733 bytes talks/oscon2012/pics/web_yesterday.gif | Bin 0 -> 36942 bytes talks/oscon2012/pics/wsdemo.png | Bin 0 -> 70602 bytes talks/oscon2012/ui/default/blank.gif | Bin 0 -> 49 bytes talks/oscon2012/ui/default/bodybg.gif | Bin 0 -> 10119 bytes talks/oscon2012/ui/default/framing.css | 23 + talks/oscon2012/ui/default/iepngfix.htc | 42 + talks/oscon2012/ui/default/opera.css | 7 + talks/oscon2012/ui/default/outline.css | 15 + talks/oscon2012/ui/default/pretty.css | 254 + talks/oscon2012/ui/default/print.css | 1 + talks/oscon2012/ui/default/s5-core.css | 9 + talks/oscon2012/ui/default/slides.css | 3 + talks/oscon2012/ui/default/slides.js | 545 + talks/oscon2012/ui/img/footer_bg.png | Bin 0 -> 978 bytes talks/oscon2012/ui/img/footer_logo.png | Bin 0 -> 2314 bytes talks/oscon2012/ui/img/footer_shadow.png | Bin 0 -> 949 bytes talks/oscon2012/ui/img/logo.png | Bin 0 -> 4379 bytes talks/oscon2012/ui/img/logo.svg | 44 + talks/ranch-msgpack/ranch-msgpack.html | 170 + talks/ranch-msgpack/ui/default/blank.gif | Bin 0 -> 49 bytes talks/ranch-msgpack/ui/default/bodybg.gif | Bin 0 -> 10119 bytes talks/ranch-msgpack/ui/default/framing.css | 23 + talks/ranch-msgpack/ui/default/iepngfix.htc | 42 + talks/ranch-msgpack/ui/default/opera.css | 7 + talks/ranch-msgpack/ui/default/outline.css | 15 + talks/ranch-msgpack/ui/default/pretty.css | 254 + talks/ranch-msgpack/ui/default/print.css | 1 + talks/ranch-msgpack/ui/default/s5-core.css | 9 + talks/ranch-msgpack/ui/default/slides.css | 3 + talks/ranch-msgpack/ui/default/slides.js | 545 + talks/ranch-msgpack/ui/img/footer_bg.png | Bin 0 -> 978 bytes talks/ranch-msgpack/ui/img/footer_logo.png | Bin 0 -> 2314 bytes talks/ranch-msgpack/ui/img/footer_shadow.png | Bin 0 -> 949 bytes talks/ranch-msgpack/ui/img/logo.png | Bin 0 -> 4379 bytes talks/ranch-msgpack/ui/img/logo.svg | 44 + talks/reverse-engineering/reverse-engineering.html | 483 + talks/reverse-engineering/ui/default/blank.gif | Bin 0 -> 49 bytes talks/reverse-engineering/ui/default/bodybg.gif | Bin 0 -> 10119 bytes talks/reverse-engineering/ui/default/framing.css | 23 + talks/reverse-engineering/ui/default/iepngfix.htc | 42 + talks/reverse-engineering/ui/default/opera.css | 7 + talks/reverse-engineering/ui/default/outline.css | 15 + talks/reverse-engineering/ui/default/pretty.css | 254 + talks/reverse-engineering/ui/default/print.css | 1 + talks/reverse-engineering/ui/default/s5-core.css | 9 + talks/reverse-engineering/ui/default/slides.css | 3 + talks/reverse-engineering/ui/default/slides.js | 545 + talks/reverse-engineering/ui/img/footer_bg.png | Bin 0 -> 978 bytes talks/reverse-engineering/ui/img/footer_logo.png | Bin 0 -> 2314 bytes talks/reverse-engineering/ui/img/footer_shadow.png | Bin 0 -> 949 bytes talks/reverse-engineering/ui/img/logo.png | Bin 0 -> 4379 bytes talks/reverse-engineering/ui/img/logo.svg | 44 + talks/sheriff/Makefile | 6 + talks/sheriff/all.ld | 7965 +++++++++++ talks/sheriff/all.lt | 426 + talks/sheriff/badge.eps | 2957 ++++ talks/sheriff/lout.li | 605 + talks/sheriff/myslides | 412 + talks/sheriff/wilza.eps | 4232 ++++++ .../pics/building_blocks_code.png | Bin 0 -> 34623 bytes .../pics/building_blocks_code.svg | 233 + .../pics/building_blocks_data.png | Bin 0 -> 43175 bytes .../pics/building_blocks_data.svg | 243 + talks/thinking-in-erlang/pics/links_crash_1.png | Bin 0 -> 23545 bytes talks/thinking-in-erlang/pics/links_crash_1.svg | 231 + talks/thinking-in-erlang/pics/links_crash_2.png | Bin 0 -> 27557 bytes talks/thinking-in-erlang/pics/links_crash_2.svg | 227 + .../thinking-in-erlang/pics/links_trap_exit_1.png | Bin 0 -> 26560 bytes .../thinking-in-erlang/pics/links_trap_exit_1.svg | 231 + .../thinking-in-erlang/pics/links_trap_exit_2.png | Bin 0 -> 22228 bytes .../thinking-in-erlang/pics/links_trap_exit_2.svg | 203 + talks/thinking-in-erlang/thinking-in-erlang.html | 1624 +++ talks/thinking-in-erlang/ui/default/blank.gif | Bin 0 -> 49 bytes talks/thinking-in-erlang/ui/default/bodybg.gif | Bin 0 -> 10119 bytes talks/thinking-in-erlang/ui/default/framing.css | 23 + talks/thinking-in-erlang/ui/default/iepngfix.htc | 42 + talks/thinking-in-erlang/ui/default/opera.css | 7 + talks/thinking-in-erlang/ui/default/outline.css | 15 + talks/thinking-in-erlang/ui/default/pretty.css | 255 + talks/thinking-in-erlang/ui/default/print.css | 1 + talks/thinking-in-erlang/ui/default/s5-core.css | 9 + talks/thinking-in-erlang/ui/default/slides.css | 3 + talks/thinking-in-erlang/ui/default/slides.js | 545 + talks/thinking-in-erlang/ui/img/footer_bg.png | Bin 0 -> 978 bytes talks/thinking-in-erlang/ui/img/footer_logo.png | Bin 0 -> 2314 bytes talks/thinking-in-erlang/ui/img/footer_shadow.png | Bin 0 -> 949 bytes talks/thinking-in-erlang/ui/img/logo.png | Bin 0 -> 4379 bytes talks/thinking-in-erlang/ui/img/logo.svg | 44 + talks/thinking-in-erlang/ui/sh/sh99s.css | 341 + talks/thinking-in-erlang/ui/sh/shBrushErlang.js | 52 + talks/thinking-in-erlang/ui/sh/shCore.js | 17 + training/index.html | 1 + 1248 files changed, 266959 insertions(+) create mode 100644 .gitignore create mode 100644 CNAME create mode 100644 _build/Makefile create mode 100644 _build/config.toml create mode 100644 _build/content/articles/cowboy2-qs.asciidoc create mode 100644 _build/content/articles/erlang-scalability.asciidoc create mode 100644 _build/content/articles/erlang-validate-utf8.asciidoc create mode 100644 _build/content/articles/erlang.mk-and-relx.asciidoc create mode 100644 _build/content/articles/erlanger-playbook-september-2015-update.asciidoc create mode 100644 _build/content/articles/erlanger-playbook.asciidoc create mode 100644 _build/content/articles/farwest-funded.asciidoc create mode 100644 _build/content/articles/january-2014-status.asciidoc create mode 100644 _build/content/articles/on-open-source.asciidoc create mode 100644 _build/content/articles/ranch-ftp.asciidoc create mode 100644 _build/content/articles/the-story-so-far.asciidoc create mode 100644 _build/content/articles/tictactoe.asciidoc create mode 100644 _build/content/articles/xerl-0.1-empty-modules.asciidoc create mode 100644 _build/content/articles/xerl-0.2-two-modules.asciidoc create mode 100644 _build/content/articles/xerl-0.3-atomic-expressions.asciidoc create mode 100644 _build/content/articles/xerl-0.4-expression-separator.asciidoc create mode 100644 _build/content/articles/xerl-0.5-intermediate-module.asciidoc create mode 100644 _build/content/docs.asciidoc create mode 100644 _build/content/donate.asciidoc create mode 100644 _build/content/services.asciidoc create mode 100644 _build/content/slogan.asciidoc create mode 100644 _build/content/talks.asciidoc create mode 100644 _build/data/projects/bullet.toml create mode 100644 _build/data/projects/cowboy.toml create mode 100644 _build/data/projects/cowlib.toml create mode 100644 _build/data/projects/erlang.mk.toml create mode 100644 _build/data/projects/gun.toml create mode 100644 _build/data/projects/ranch.toml create mode 100644 _build/data/talks.toml create mode 100644 _build/static/CNAME create mode 100644 _build/static/docs/db.json create mode 100644 _build/static/docs/en/cowboy/1.0/guide/architecture/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/broken_clients/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/cookies/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/erlang_beginners/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/erlang_web/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/getting_started/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/hooks/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/http_handlers/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/http_req_life/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/http_req_resp.png create mode 100644 _build/static/docs/en/cowboy/1.0/guide/http_req_resp.svg create mode 100644 _build/static/docs/en/cowboy/1.0/guide/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/introduction/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/loop_handlers/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/middlewares/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/modern_web/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/multipart_intro/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/multipart_req/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/req/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/req_body/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/resource_design/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/resp/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_cond.png create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_cond.svg create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_conneg.png create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_conneg.svg create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_delete.png create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_delete.svg create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_flowcharts/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_get_head.png create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_get_head.svg create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_handlers/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_options.png create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_options.svg create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_principles/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_put_post_patch.png create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_put_post_patch.svg create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_start.png create mode 100644 _build/static/docs/en/cowboy/1.0/guide/rest_start.svg create mode 100644 _build/static/docs/en/cowboy/1.0/guide/routing/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/static_handlers/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/upgrade_protocol/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/ws_handlers/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/guide/ws_protocol/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_app/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_handler/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_http_handler/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_loop_handler/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_middleware/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_req/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_rest/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_router/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_spdy/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_static/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_sub_protocol/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_websocket/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/cowboy_websocket_handler/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/http_status_codes/index.html create mode 100644 _build/static/docs/en/cowboy/1.0/manual/index.html create mode 100644 _build/static/res/erlanger-preview.pdf create mode 100644 _build/static/res/tictactoe.erl create mode 100644 _build/static/talks/PDF/cowboy.pdf create mode 100644 _build/static/talks/PDF/sheriff.pdf create mode 100644 _build/static/talks/bed/bed.ezdoc create mode 100644 _build/static/talks/bed/bed.html create mode 100644 _build/static/talks/bed/pics/family_business.jpg create mode 100644 _build/static/talks/bed/pics/mind_blown.jpg create mode 100644 _build/static/talks/bed/pics/rest.jpg create mode 100644 _build/static/talks/bed/pics/wondering.jpg create mode 100644 _build/static/talks/bed/ui/default/blank.gif create mode 100755 _build/static/talks/bed/ui/default/bodybg.gif create mode 100644 _build/static/talks/bed/ui/default/framing.css create mode 100644 _build/static/talks/bed/ui/default/iepngfix.htc create mode 100644 _build/static/talks/bed/ui/default/opera.css create mode 100644 _build/static/talks/bed/ui/default/outline.css create mode 100644 _build/static/talks/bed/ui/default/pretty.css create mode 100644 _build/static/talks/bed/ui/default/print.css create mode 100644 _build/static/talks/bed/ui/default/s5-core.css create mode 100644 _build/static/talks/bed/ui/default/slides.css create mode 100644 _build/static/talks/bed/ui/default/slides.js create mode 100644 _build/static/talks/bed/ui/img/footer_bg.png create mode 100644 _build/static/talks/bed/ui/img/footer_logo.png create mode 100644 _build/static/talks/bed/ui/img/footer_shadow.png create mode 100644 _build/static/talks/bed/ui/img/logo.png create mode 100644 _build/static/talks/bed/ui/img/logo.svg create mode 100644 _build/static/talks/bed/ui/sh/sh99s.css create mode 100644 _build/static/talks/bed/ui/sh/shBrushErlang.js create mode 100644 _build/static/talks/bed/ui/sh/shBrushJScript.js create mode 100644 _build/static/talks/bed/ui/sh/shBrushXml.js create mode 100644 _build/static/talks/bed/ui/sh/shCore.js create mode 100644 _build/static/talks/beyond-otp/beyond-otp.html create mode 100644 _build/static/talks/beyond-otp/ui/default/blank.gif create mode 100755 _build/static/talks/beyond-otp/ui/default/bodybg.gif create mode 100644 _build/static/talks/beyond-otp/ui/default/framing.css create mode 100644 _build/static/talks/beyond-otp/ui/default/iepngfix.htc create mode 100644 _build/static/talks/beyond-otp/ui/default/opera.css create mode 100644 _build/static/talks/beyond-otp/ui/default/outline.css create mode 100644 _build/static/talks/beyond-otp/ui/default/pretty.css create mode 100644 _build/static/talks/beyond-otp/ui/default/print.css create mode 100644 _build/static/talks/beyond-otp/ui/default/s5-core.css create mode 100644 _build/static/talks/beyond-otp/ui/default/slides.css create mode 100644 _build/static/talks/beyond-otp/ui/default/slides.js create mode 100644 _build/static/talks/beyond-otp/ui/img/footer_bg.png create mode 100644 _build/static/talks/beyond-otp/ui/img/footer_logo.png create mode 100644 _build/static/talks/beyond-otp/ui/img/footer_shadow.png create mode 100644 _build/static/talks/beyond-otp/ui/img/logo.png create mode 100644 _build/static/talks/beyond-otp/ui/img/logo.svg create mode 100644 _build/static/talks/beyond-otp/ui/sh/sh99s.css create mode 100644 _build/static/talks/beyond-otp/ui/sh/shBrushErlang.js create mode 100644 _build/static/talks/beyond-otp/ui/sh/shCore.js create mode 100644 _build/static/talks/cowboy-0.8/cowboy-0.8.html create mode 100644 _build/static/talks/cowboy-0.8/pics/adgear.png create mode 100644 _build/static/talks/cowboy-0.8/pics/cowboy.png create mode 100644 _build/static/talks/cowboy-0.8/pics/popularity-feb-2013.png create mode 100644 _build/static/talks/cowboy-0.8/ui/default/blank.gif create mode 100755 _build/static/talks/cowboy-0.8/ui/default/bodybg.gif create mode 100644 _build/static/talks/cowboy-0.8/ui/default/framing.css create mode 100644 _build/static/talks/cowboy-0.8/ui/default/iepngfix.htc create mode 100644 _build/static/talks/cowboy-0.8/ui/default/opera.css create mode 100644 _build/static/talks/cowboy-0.8/ui/default/outline.css create mode 100644 _build/static/talks/cowboy-0.8/ui/default/pretty.css create mode 100644 _build/static/talks/cowboy-0.8/ui/default/print.css create mode 100644 _build/static/talks/cowboy-0.8/ui/default/s5-core.css create mode 100644 _build/static/talks/cowboy-0.8/ui/default/slides.css create mode 100644 _build/static/talks/cowboy-0.8/ui/default/slides.js create mode 100644 _build/static/talks/cowboy-0.8/ui/img/footer_bg.png create mode 100644 _build/static/talks/cowboy-0.8/ui/img/footer_logo.png create mode 100644 _build/static/talks/cowboy-0.8/ui/img/footer_shadow.png create mode 100644 _build/static/talks/cowboy-0.8/ui/img/logo.png create mode 100644 _build/static/talks/cowboy-0.8/ui/img/logo.svg create mode 100644 _build/static/talks/cowboy-2/CONTRIBUTING.md create mode 100644 _build/static/talks/cowboy-2/Gruntfile.js create mode 100644 _build/static/talks/cowboy-2/LICENSE create mode 100644 _build/static/talks/cowboy-2/README.md create mode 100644 _build/static/talks/cowboy-2/css/print/paper.css create mode 100644 _build/static/talks/cowboy-2/css/print/pdf.css create mode 100644 _build/static/talks/cowboy-2/css/reveal.css create mode 100644 _build/static/talks/cowboy-2/css/reveal.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/README.md create mode 100644 _build/static/talks/cowboy-2/css/theme/beige.css create mode 100644 _build/static/talks/cowboy-2/css/theme/black.css create mode 100644 _build/static/talks/cowboy-2/css/theme/blood.css create mode 100644 _build/static/talks/cowboy-2/css/theme/league.css create mode 100644 _build/static/talks/cowboy-2/css/theme/moon.css create mode 100644 _build/static/talks/cowboy-2/css/theme/night.css create mode 100644 _build/static/talks/cowboy-2/css/theme/serif.css create mode 100644 _build/static/talks/cowboy-2/css/theme/simple.css create mode 100644 _build/static/talks/cowboy-2/css/theme/sky.css create mode 100644 _build/static/talks/cowboy-2/css/theme/solarized.css create mode 100644 _build/static/talks/cowboy-2/css/theme/source/beige.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/source/black.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/source/blood.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/source/league.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/source/moon.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/source/night.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/source/serif.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/source/simple.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/source/sky.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/source/solarized.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/source/white.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/template/mixins.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/template/settings.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/template/theme.scss create mode 100644 _build/static/talks/cowboy-2/css/theme/white.css create mode 100644 _build/static/talks/cowboy-2/index.html create mode 100644 _build/static/talks/cowboy-2/js/reveal.js create mode 100644 _build/static/talks/cowboy-2/lib/css/zenburn.css create mode 100644 _build/static/talks/cowboy-2/lib/font/league-gothic/LICENSE create mode 100644 _build/static/talks/cowboy-2/lib/font/league-gothic/league-gothic.css create mode 100755 _build/static/talks/cowboy-2/lib/font/league-gothic/league-gothic.eot create mode 100755 _build/static/talks/cowboy-2/lib/font/league-gothic/league-gothic.ttf create mode 100755 _build/static/talks/cowboy-2/lib/font/league-gothic/league-gothic.woff create mode 100644 _build/static/talks/cowboy-2/lib/font/source-sans-pro/LICENSE create mode 100755 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-italic.eot create mode 100755 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-italic.ttf create mode 100755 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-italic.woff create mode 100755 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-regular.eot create mode 100755 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-regular.ttf create mode 100755 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-regular.woff create mode 100755 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-semibold.eot create mode 100755 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-semibold.ttf create mode 100755 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-semibold.woff create mode 100755 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-semibolditalic.eot create mode 100755 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-semibolditalic.ttf create mode 100755 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-semibolditalic.woff create mode 100644 _build/static/talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro.css create mode 100644 _build/static/talks/cowboy-2/lib/js/classList.js create mode 100644 _build/static/talks/cowboy-2/lib/js/head.min.js create mode 100644 _build/static/talks/cowboy-2/lib/js/html5shiv.js create mode 100644 _build/static/talks/cowboy-2/package.json create mode 100644 _build/static/talks/cowboy-2/plugin/highlight/highlight.js create mode 100644 _build/static/talks/cowboy-2/plugin/leap/leap.js create mode 100644 _build/static/talks/cowboy-2/plugin/markdown/example.html create mode 100644 _build/static/talks/cowboy-2/plugin/markdown/example.md create mode 100755 _build/static/talks/cowboy-2/plugin/markdown/markdown.js create mode 100644 _build/static/talks/cowboy-2/plugin/markdown/marked.js create mode 100755 _build/static/talks/cowboy-2/plugin/math/math.js create mode 100644 _build/static/talks/cowboy-2/plugin/multiplex/client.js create mode 100644 _build/static/talks/cowboy-2/plugin/multiplex/index.js create mode 100644 _build/static/talks/cowboy-2/plugin/multiplex/master.js create mode 100644 _build/static/talks/cowboy-2/plugin/notes-server/client.js create mode 100644 _build/static/talks/cowboy-2/plugin/notes-server/index.js create mode 100644 _build/static/talks/cowboy-2/plugin/notes-server/notes.html create mode 100644 _build/static/talks/cowboy-2/plugin/notes/notes.html create mode 100644 _build/static/talks/cowboy-2/plugin/notes/notes.js create mode 100644 _build/static/talks/cowboy-2/plugin/print-pdf/print-pdf.js create mode 100644 _build/static/talks/cowboy-2/plugin/remotes/remotes.js create mode 100644 _build/static/talks/cowboy-2/plugin/search/search.js create mode 100644 _build/static/talks/cowboy-2/plugin/zoom-js/zoom.js create mode 100644 _build/static/talks/cowboy-2/test/examples/assets/image1.png create mode 100644 _build/static/talks/cowboy-2/test/examples/assets/image2.png create mode 100644 _build/static/talks/cowboy-2/test/examples/barebones.html create mode 100644 _build/static/talks/cowboy-2/test/examples/embedded-media.html create mode 100644 _build/static/talks/cowboy-2/test/examples/math.html create mode 100644 _build/static/talks/cowboy-2/test/examples/slide-backgrounds.html create mode 100644 _build/static/talks/cowboy-2/test/examples/slide-transitions.html create mode 100644 _build/static/talks/cowboy-2/test/qunit-1.12.0.css create mode 100644 _build/static/talks/cowboy-2/test/qunit-1.12.0.js create mode 100644 _build/static/talks/cowboy-2/test/test-markdown-element-attributes.html create mode 100644 _build/static/talks/cowboy-2/test/test-markdown-element-attributes.js create mode 100644 _build/static/talks/cowboy-2/test/test-markdown-slide-attributes.html create mode 100644 _build/static/talks/cowboy-2/test/test-markdown-slide-attributes.js create mode 100644 _build/static/talks/cowboy-2/test/test-markdown.html create mode 100644 _build/static/talks/cowboy-2/test/test-markdown.js create mode 100644 _build/static/talks/cowboy-2/test/test-pdf.html create mode 100644 _build/static/talks/cowboy-2/test/test-pdf.js create mode 100644 _build/static/talks/cowboy-2/test/test.html create mode 100644 _build/static/talks/cowboy-2/test/test.js create mode 100644 _build/static/talks/cowboy-d3/cowboy-d3.html create mode 100644 _build/static/talks/cowboy-d3/ui/default/blank.gif create mode 100755 _build/static/talks/cowboy-d3/ui/default/bodybg.gif create mode 100644 _build/static/talks/cowboy-d3/ui/default/framing.css create mode 100644 _build/static/talks/cowboy-d3/ui/default/iepngfix.htc create mode 100644 _build/static/talks/cowboy-d3/ui/default/opera.css create mode 100644 _build/static/talks/cowboy-d3/ui/default/outline.css create mode 100644 _build/static/talks/cowboy-d3/ui/default/pretty.css create mode 100644 _build/static/talks/cowboy-d3/ui/default/print.css create mode 100644 _build/static/talks/cowboy-d3/ui/default/s5-core.css create mode 100644 _build/static/talks/cowboy-d3/ui/default/slides.css create mode 100644 _build/static/talks/cowboy-d3/ui/default/slides.js create mode 100644 _build/static/talks/cowboy-d3/ui/img/footer_bg.png create mode 100644 _build/static/talks/cowboy-d3/ui/img/footer_logo.png create mode 100644 _build/static/talks/cowboy-d3/ui/img/footer_shadow.png create mode 100644 _build/static/talks/cowboy-d3/ui/img/logo.png create mode 100644 _build/static/talks/cowboy-d3/ui/img/logo.svg create mode 100644 _build/static/talks/cowboy-d3/ui/sh/sh99s.css create mode 100644 _build/static/talks/cowboy-d3/ui/sh/shBrushErlang.js create mode 100644 _build/static/talks/cowboy-d3/ui/sh/shBrushJScript.js create mode 100644 _build/static/talks/cowboy-d3/ui/sh/shBrushXml.js create mode 100644 _build/static/talks/cowboy-d3/ui/sh/shCore.js create mode 100644 _build/static/talks/cowboy-websocket/cowboy-websocket.html create mode 100644 _build/static/talks/cowboy-websocket/ui/default/blank.gif create mode 100755 _build/static/talks/cowboy-websocket/ui/default/bodybg.gif create mode 100644 _build/static/talks/cowboy-websocket/ui/default/framing.css create mode 100644 _build/static/talks/cowboy-websocket/ui/default/iepngfix.htc create mode 100644 _build/static/talks/cowboy-websocket/ui/default/opera.css create mode 100644 _build/static/talks/cowboy-websocket/ui/default/outline.css create mode 100644 _build/static/talks/cowboy-websocket/ui/default/pretty.css create mode 100644 _build/static/talks/cowboy-websocket/ui/default/print.css create mode 100644 _build/static/talks/cowboy-websocket/ui/default/s5-core.css create mode 100644 _build/static/talks/cowboy-websocket/ui/default/slides.css create mode 100644 _build/static/talks/cowboy-websocket/ui/default/slides.js create mode 100644 _build/static/talks/cowboy-websocket/ui/img/footer_bg.png create mode 100644 _build/static/talks/cowboy-websocket/ui/img/footer_logo.png create mode 100644 _build/static/talks/cowboy-websocket/ui/img/footer_shadow.png create mode 100644 _build/static/talks/cowboy-websocket/ui/img/logo.png create mode 100644 _build/static/talks/cowboy-websocket/ui/img/logo.svg create mode 100644 _build/static/talks/cowboy/Makefile create mode 100644 _build/static/talks/cowboy/all.ld create mode 100644 _build/static/talks/cowboy/all.lt create mode 100644 _build/static/talks/cowboy/lout.li create mode 100644 _build/static/talks/cowboy/myslides create mode 100644 _build/static/talks/erlang-cowboy/erlang-cowboy-fr-unis.html create mode 100644 _build/static/talks/erlang-cowboy/ui/default/blank.gif create mode 100755 _build/static/talks/erlang-cowboy/ui/default/bodybg.gif create mode 100644 _build/static/talks/erlang-cowboy/ui/default/framing.css create mode 100644 _build/static/talks/erlang-cowboy/ui/default/iepngfix.htc create mode 100644 _build/static/talks/erlang-cowboy/ui/default/opera.css create mode 100644 _build/static/talks/erlang-cowboy/ui/default/outline.css create mode 100644 _build/static/talks/erlang-cowboy/ui/default/pretty.css create mode 100644 _build/static/talks/erlang-cowboy/ui/default/print.css create mode 100644 _build/static/talks/erlang-cowboy/ui/default/s5-core.css create mode 100644 _build/static/talks/erlang-cowboy/ui/default/slides.css create mode 100644 _build/static/talks/erlang-cowboy/ui/default/slides.js create mode 100644 _build/static/talks/erlang-cowboy/ui/img/footer_bg.png create mode 100644 _build/static/talks/erlang-cowboy/ui/img/footer_logo.png create mode 100644 _build/static/talks/erlang-cowboy/ui/img/footer_shadow.png create mode 100644 _build/static/talks/erlang-cowboy/ui/img/logo.png create mode 100644 _build/static/talks/erlang-cowboy/ui/img/logo.svg create mode 100644 _build/static/talks/erlang-tokyo-2012-09/erlang-tokyo-2012-09.html create mode 100644 _build/static/talks/erlang-tokyo-2012-09/pics/bullet.png create mode 100644 _build/static/talks/erlang-tokyo-2012-09/pics/cowboy.png create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/default/blank.gif create mode 100755 _build/static/talks/erlang-tokyo-2012-09/ui/default/bodybg.gif create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/default/framing.css create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/default/iepngfix.htc create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/default/opera.css create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/default/outline.css create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/default/pretty.css create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/default/print.css create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/default/s5-core.css create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/default/slides.css create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/default/slides.js create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/img/footer_bg.png create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/img/footer_logo.png create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/img/footer_shadow.png create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/img/logo.png create mode 100644 _build/static/talks/erlang-tokyo-2012-09/ui/img/logo.svg create mode 100644 _build/static/talks/farwest/farwest.html create mode 100644 _build/static/talks/farwest/ui/default/blank.gif create mode 100755 _build/static/talks/farwest/ui/default/bodybg.gif create mode 100644 _build/static/talks/farwest/ui/default/framing.css create mode 100644 _build/static/talks/farwest/ui/default/iepngfix.htc create mode 100644 _build/static/talks/farwest/ui/default/opera.css create mode 100644 _build/static/talks/farwest/ui/default/outline.css create mode 100644 _build/static/talks/farwest/ui/default/pretty.css create mode 100644 _build/static/talks/farwest/ui/default/print.css create mode 100644 _build/static/talks/farwest/ui/default/s5-core.css create mode 100644 _build/static/talks/farwest/ui/default/slides.css create mode 100644 _build/static/talks/farwest/ui/default/slides.js create mode 100644 _build/static/talks/farwest/ui/img/footer_bg.png create mode 100644 _build/static/talks/farwest/ui/img/footer_logo.png create mode 100644 _build/static/talks/farwest/ui/img/footer_shadow.png create mode 100644 _build/static/talks/farwest/ui/img/logo.png create mode 100644 _build/static/talks/farwest/ui/img/logo.svg create mode 100644 _build/static/talks/oscon2012/oscon2012.html create mode 100644 _build/static/talks/oscon2012/pics/cowboy.png create mode 100644 _build/static/talks/oscon2012/pics/erlang_movie.jpg create mode 100644 _build/static/talks/oscon2012/pics/hello_world.png create mode 100644 _build/static/talks/oscon2012/pics/horse.png create mode 100644 _build/static/talks/oscon2012/pics/php_fcgi.png create mode 100644 _build/static/talks/oscon2012/pics/raspberry_pi.png create mode 100644 _build/static/talks/oscon2012/pics/real_load.png create mode 100644 _build/static/talks/oscon2012/pics/static.png create mode 100644 _build/static/talks/oscon2012/pics/web_today.gif create mode 100644 _build/static/talks/oscon2012/pics/web_yesterday.gif create mode 100644 _build/static/talks/oscon2012/pics/wsdemo.png create mode 100644 _build/static/talks/oscon2012/ui/default/blank.gif create mode 100755 _build/static/talks/oscon2012/ui/default/bodybg.gif create mode 100644 _build/static/talks/oscon2012/ui/default/framing.css create mode 100644 _build/static/talks/oscon2012/ui/default/iepngfix.htc create mode 100644 _build/static/talks/oscon2012/ui/default/opera.css create mode 100644 _build/static/talks/oscon2012/ui/default/outline.css create mode 100644 _build/static/talks/oscon2012/ui/default/pretty.css create mode 100644 _build/static/talks/oscon2012/ui/default/print.css create mode 100644 _build/static/talks/oscon2012/ui/default/s5-core.css create mode 100644 _build/static/talks/oscon2012/ui/default/slides.css create mode 100644 _build/static/talks/oscon2012/ui/default/slides.js create mode 100644 _build/static/talks/oscon2012/ui/img/footer_bg.png create mode 100644 _build/static/talks/oscon2012/ui/img/footer_logo.png create mode 100644 _build/static/talks/oscon2012/ui/img/footer_shadow.png create mode 100644 _build/static/talks/oscon2012/ui/img/logo.png create mode 100644 _build/static/talks/oscon2012/ui/img/logo.svg create mode 100644 _build/static/talks/ranch-msgpack/ranch-msgpack.html create mode 100644 _build/static/talks/ranch-msgpack/ui/default/blank.gif create mode 100755 _build/static/talks/ranch-msgpack/ui/default/bodybg.gif create mode 100644 _build/static/talks/ranch-msgpack/ui/default/framing.css create mode 100644 _build/static/talks/ranch-msgpack/ui/default/iepngfix.htc create mode 100644 _build/static/talks/ranch-msgpack/ui/default/opera.css create mode 100644 _build/static/talks/ranch-msgpack/ui/default/outline.css create mode 100644 _build/static/talks/ranch-msgpack/ui/default/pretty.css create mode 100644 _build/static/talks/ranch-msgpack/ui/default/print.css create mode 100644 _build/static/talks/ranch-msgpack/ui/default/s5-core.css create mode 100644 _build/static/talks/ranch-msgpack/ui/default/slides.css create mode 100644 _build/static/talks/ranch-msgpack/ui/default/slides.js create mode 100644 _build/static/talks/ranch-msgpack/ui/img/footer_bg.png create mode 100644 _build/static/talks/ranch-msgpack/ui/img/footer_logo.png create mode 100644 _build/static/talks/ranch-msgpack/ui/img/footer_shadow.png create mode 100644 _build/static/talks/ranch-msgpack/ui/img/logo.png create mode 100644 _build/static/talks/ranch-msgpack/ui/img/logo.svg create mode 100644 _build/static/talks/reverse-engineering/reverse-engineering.html create mode 100644 _build/static/talks/reverse-engineering/ui/default/blank.gif create mode 100755 _build/static/talks/reverse-engineering/ui/default/bodybg.gif create mode 100644 _build/static/talks/reverse-engineering/ui/default/framing.css create mode 100644 _build/static/talks/reverse-engineering/ui/default/iepngfix.htc create mode 100644 _build/static/talks/reverse-engineering/ui/default/opera.css create mode 100644 _build/static/talks/reverse-engineering/ui/default/outline.css create mode 100644 _build/static/talks/reverse-engineering/ui/default/pretty.css create mode 100644 _build/static/talks/reverse-engineering/ui/default/print.css create mode 100644 _build/static/talks/reverse-engineering/ui/default/s5-core.css create mode 100644 _build/static/talks/reverse-engineering/ui/default/slides.css create mode 100644 _build/static/talks/reverse-engineering/ui/default/slides.js create mode 100644 _build/static/talks/reverse-engineering/ui/img/footer_bg.png create mode 100644 _build/static/talks/reverse-engineering/ui/img/footer_logo.png create mode 100644 _build/static/talks/reverse-engineering/ui/img/footer_shadow.png create mode 100644 _build/static/talks/reverse-engineering/ui/img/logo.png create mode 100644 _build/static/talks/reverse-engineering/ui/img/logo.svg create mode 100644 _build/static/talks/sheriff/Makefile create mode 100644 _build/static/talks/sheriff/all.ld create mode 100644 _build/static/talks/sheriff/all.lt create mode 100644 _build/static/talks/sheriff/badge.eps create mode 100644 _build/static/talks/sheriff/lout.li create mode 100644 _build/static/talks/sheriff/myslides create mode 100644 _build/static/talks/sheriff/wilza.eps create mode 100644 _build/static/talks/thinking-in-erlang/pics/building_blocks_code.png create mode 100644 _build/static/talks/thinking-in-erlang/pics/building_blocks_code.svg create mode 100644 _build/static/talks/thinking-in-erlang/pics/building_blocks_data.png create mode 100644 _build/static/talks/thinking-in-erlang/pics/building_blocks_data.svg create mode 100644 _build/static/talks/thinking-in-erlang/pics/links_crash_1.png create mode 100644 _build/static/talks/thinking-in-erlang/pics/links_crash_1.svg create mode 100644 _build/static/talks/thinking-in-erlang/pics/links_crash_2.png create mode 100644 _build/static/talks/thinking-in-erlang/pics/links_crash_2.svg create mode 100644 _build/static/talks/thinking-in-erlang/pics/links_trap_exit_1.png create mode 100644 _build/static/talks/thinking-in-erlang/pics/links_trap_exit_1.svg create mode 100644 _build/static/talks/thinking-in-erlang/pics/links_trap_exit_2.png create mode 100644 _build/static/talks/thinking-in-erlang/pics/links_trap_exit_2.svg create mode 100644 _build/static/talks/thinking-in-erlang/thinking-in-erlang.html create mode 100644 _build/static/talks/thinking-in-erlang/ui/default/blank.gif create mode 100755 _build/static/talks/thinking-in-erlang/ui/default/bodybg.gif create mode 100644 _build/static/talks/thinking-in-erlang/ui/default/framing.css create mode 100644 _build/static/talks/thinking-in-erlang/ui/default/iepngfix.htc create mode 100644 _build/static/talks/thinking-in-erlang/ui/default/opera.css create mode 100644 _build/static/talks/thinking-in-erlang/ui/default/outline.css create mode 100644 _build/static/talks/thinking-in-erlang/ui/default/pretty.css create mode 100644 _build/static/talks/thinking-in-erlang/ui/default/print.css create mode 100644 _build/static/talks/thinking-in-erlang/ui/default/s5-core.css create mode 100644 _build/static/talks/thinking-in-erlang/ui/default/slides.css create mode 100644 _build/static/talks/thinking-in-erlang/ui/default/slides.js create mode 100644 _build/static/talks/thinking-in-erlang/ui/img/footer_bg.png create mode 100644 _build/static/talks/thinking-in-erlang/ui/img/footer_logo.png create mode 100644 _build/static/talks/thinking-in-erlang/ui/img/footer_shadow.png create mode 100644 _build/static/talks/thinking-in-erlang/ui/img/logo.png create mode 100644 _build/static/talks/thinking-in-erlang/ui/img/logo.svg create mode 100644 _build/static/talks/thinking-in-erlang/ui/sh/sh99s.css create mode 100644 _build/static/talks/thinking-in-erlang/ui/sh/shBrushErlang.js create mode 100644 _build/static/talks/thinking-in-erlang/ui/sh/shCore.js create mode 100644 _build/themes/ninenines/layouts/_default/li.html create mode 100644 _build/themes/ninenines/layouts/_default/single.html create mode 100644 _build/themes/ninenines/layouts/_default/summary.html create mode 100644 _build/themes/ninenines/layouts/_default/terms.html create mode 100644 _build/themes/ninenines/layouts/articles/single.html create mode 100644 _build/themes/ninenines/layouts/docs-index/single.html create mode 100644 _build/themes/ninenines/layouts/docs/single.html create mode 100644 _build/themes/ninenines/layouts/index.html create mode 100644 _build/themes/ninenines/layouts/indexes/articles.html create mode 100644 _build/themes/ninenines/layouts/partials/brand.html create mode 100644 _build/themes/ninenines/layouts/partials/copyright.html create mode 100644 _build/themes/ninenines/layouts/partials/disqus.html create mode 100644 _build/themes/ninenines/layouts/partials/footer.html create mode 100644 _build/themes/ninenines/layouts/partials/google_analytics.html create mode 100644 _build/themes/ninenines/layouts/partials/head.html create mode 100644 _build/themes/ninenines/layouts/partials/header.html create mode 100644 _build/themes/ninenines/layouts/partials/pagination.html create mode 100644 _build/themes/ninenines/layouts/partials/post_meta.html create mode 100644 _build/themes/ninenines/layouts/partials/prev_next_post.html create mode 100644 _build/themes/ninenines/layouts/partials/social.html create mode 100644 _build/themes/ninenines/layouts/services/single.html create mode 100644 _build/themes/ninenines/layouts/shortcodes/fluid_img.html create mode 100644 _build/themes/ninenines/layouts/talks/single.html create mode 100644 _build/themes/ninenines/layouts/taxonomy/tag.html create mode 100644 _build/themes/ninenines/layouts/taxonomy/topic.html create mode 100644 _build/themes/ninenines/static/css/99s.css create mode 100644 _build/themes/ninenines/static/css/bootstrap.min.css create mode 100644 _build/themes/ninenines/static/css/sh99s.css create mode 100644 _build/themes/ninenines/static/img/big_bullet.png create mode 100644 _build/themes/ninenines/static/img/body_bg.jpg create mode 100644 _build/themes/ninenines/static/img/container_bg.png create mode 100644 _build/themes/ninenines/static/img/footer_bg.png create mode 100644 _build/themes/ninenines/static/img/footer_bg_light.png create mode 100644 _build/themes/ninenines/static/img/footer_logo.png create mode 100755 _build/themes/ninenines/static/img/glyphicons-halflings-white.png create mode 100755 _build/themes/ninenines/static/img/glyphicons-halflings.png create mode 100644 _build/themes/ninenines/static/img/header_bg.jpg create mode 100644 _build/themes/ninenines/static/img/header_bg_center.jpg create mode 100644 _build/themes/ninenines/static/img/header_center.jpg create mode 100644 _build/themes/ninenines/static/img/header_line.png create mode 100644 _build/themes/ninenines/static/img/home/carousel_bg_blue.png create mode 100644 _build/themes/ninenines/static/img/home/carousel_light_effect.png create mode 100644 _build/themes/ninenines/static/img/home/consulting_ico.jpg create mode 100644 _build/themes/ninenines/static/img/home/detail_bg.png create mode 100644 _build/themes/ninenines/static/img/home/support_ico.jpg create mode 100644 _build/themes/ninenines/static/img/home/training_ico.jpg create mode 100644 _build/themes/ninenines/static/img/ico/apple-touch-icon-114.png create mode 100644 _build/themes/ninenines/static/img/ico/apple-touch-icon-57.png create mode 100644 _build/themes/ninenines/static/img/ico/apple-touch-icon-72.png create mode 100644 _build/themes/ninenines/static/img/ico/favicon.ico create mode 100644 _build/themes/ninenines/static/img/ico_github.png create mode 100644 _build/themes/ninenines/static/img/ico_github_alt.png create mode 100644 _build/themes/ninenines/static/img/ico_linkedin.png create mode 100644 _build/themes/ninenines/static/img/ico_linkedin_alt.png create mode 100644 _build/themes/ninenines/static/img/ico_mail.png create mode 100644 _build/themes/ninenines/static/img/ico_mail_alt.png create mode 100644 _build/themes/ninenines/static/img/ico_microblog.png create mode 100644 _build/themes/ninenines/static/img/ico_microblog_alt.png create mode 100644 _build/themes/ninenines/static/img/logo.png create mode 100644 _build/themes/ninenines/static/img/projects/bullet-home.png create mode 100644 _build/themes/ninenines/static/img/projects/cowboy-home.png create mode 100644 _build/themes/ninenines/static/img/projects/cowlib-home.png create mode 100644 _build/themes/ninenines/static/img/projects/erlang.mk-home.png create mode 100644 _build/themes/ninenines/static/img/projects/gun-home.png create mode 100644 _build/themes/ninenines/static/img/projects/ranch-home.png create mode 100644 _build/themes/ninenines/static/img/projects/sheriff-home.png create mode 100644 _build/themes/ninenines/static/img/sponsors/kato.png create mode 100644 _build/themes/ninenines/static/img/sponsors/shiguredo.png create mode 100644 _build/themes/ninenines/static/img/sponsors/soundrop.png create mode 100755 _build/themes/ninenines/static/js/bootstrap-carousel.js create mode 100755 _build/themes/ninenines/static/js/bootstrap-dropdown.js create mode 100644 _build/themes/ninenines/static/js/custom.js create mode 100644 _build/themes/ninenines/static/js/fuse.min.js create mode 100644 _build/themes/ninenines/static/js/shCore.js create mode 100644 _build/themes/ninenines/static/js/shlang/shBrushBash.js create mode 100644 _build/themes/ninenines/static/js/shlang/shBrushCpp.js create mode 100644 _build/themes/ninenines/static/js/shlang/shBrushErlang.js create mode 100644 _build/themes/ninenines/static/js/shlang/shBrushJScript.js create mode 100644 _build/themes/ninenines/static/js/shlang/shBrushPlain.js create mode 100644 _build/themes/ninenines/theme.toml create mode 100644 articles/cowboy2-qs/index.html create mode 100644 articles/erlang-scalability/index.html create mode 100644 articles/erlang-validate-utf8/index.html create mode 100644 articles/erlang.mk-and-relx/index.html create mode 100644 articles/erlanger-playbook-september-2015-update/index.html create mode 100644 articles/erlanger-playbook/index.html create mode 100644 articles/farwest-funded/index.html create mode 100644 articles/index.html create mode 100644 articles/index.xml create mode 100644 articles/january-2014-status/index.html create mode 100644 articles/on-open-source/index.html create mode 100644 articles/page/1/index.html create mode 100644 articles/ranch-ftp/index.html create mode 100644 articles/the-story-so-far/index.html create mode 100644 articles/tictactoe/index.html create mode 100644 articles/xerl-0.1-empty-modules/index.html create mode 100644 articles/xerl-0.2-two-modules/index.html create mode 100644 articles/xerl-0.3-atomic-expressions/index.html create mode 100644 articles/xerl-0.4-expression-separator/index.html create mode 100644 articles/xerl-0.5-intermediate-module/index.html create mode 100644 categories/index.html create mode 100644 css/99s.css create mode 100644 css/bootstrap.min.css create mode 100644 css/sh99s.css create mode 100644 docs/db.json create mode 100644 docs/en/cowboy/1.0/guide/architecture/index.html create mode 100644 docs/en/cowboy/1.0/guide/broken_clients/index.html create mode 100644 docs/en/cowboy/1.0/guide/cookies/index.html create mode 100644 docs/en/cowboy/1.0/guide/erlang_beginners/index.html create mode 100644 docs/en/cowboy/1.0/guide/erlang_web/index.html create mode 100644 docs/en/cowboy/1.0/guide/getting_started/index.html create mode 100644 docs/en/cowboy/1.0/guide/hooks/index.html create mode 100644 docs/en/cowboy/1.0/guide/http_handlers/index.html create mode 100644 docs/en/cowboy/1.0/guide/http_req_life/index.html create mode 100644 docs/en/cowboy/1.0/guide/http_req_resp.png create mode 100644 docs/en/cowboy/1.0/guide/http_req_resp.svg create mode 100644 docs/en/cowboy/1.0/guide/index.html create mode 100644 docs/en/cowboy/1.0/guide/introduction/index.html create mode 100644 docs/en/cowboy/1.0/guide/loop_handlers/index.html create mode 100644 docs/en/cowboy/1.0/guide/middlewares/index.html create mode 100644 docs/en/cowboy/1.0/guide/modern_web/index.html create mode 100644 docs/en/cowboy/1.0/guide/multipart_intro/index.html create mode 100644 docs/en/cowboy/1.0/guide/multipart_req/index.html create mode 100644 docs/en/cowboy/1.0/guide/req/index.html create mode 100644 docs/en/cowboy/1.0/guide/req_body/index.html create mode 100644 docs/en/cowboy/1.0/guide/resource_design/index.html create mode 100644 docs/en/cowboy/1.0/guide/resp/index.html create mode 100644 docs/en/cowboy/1.0/guide/rest_cond.png create mode 100644 docs/en/cowboy/1.0/guide/rest_cond.svg create mode 100644 docs/en/cowboy/1.0/guide/rest_conneg.png create mode 100644 docs/en/cowboy/1.0/guide/rest_conneg.svg create mode 100644 docs/en/cowboy/1.0/guide/rest_delete.png create mode 100644 docs/en/cowboy/1.0/guide/rest_delete.svg create mode 100644 docs/en/cowboy/1.0/guide/rest_flowcharts/index.html create mode 100644 docs/en/cowboy/1.0/guide/rest_get_head.png create mode 100644 docs/en/cowboy/1.0/guide/rest_get_head.svg create mode 100644 docs/en/cowboy/1.0/guide/rest_handlers/index.html create mode 100644 docs/en/cowboy/1.0/guide/rest_options.png create mode 100644 docs/en/cowboy/1.0/guide/rest_options.svg create mode 100644 docs/en/cowboy/1.0/guide/rest_principles/index.html create mode 100644 docs/en/cowboy/1.0/guide/rest_put_post_patch.png create mode 100644 docs/en/cowboy/1.0/guide/rest_put_post_patch.svg create mode 100644 docs/en/cowboy/1.0/guide/rest_start.png create mode 100644 docs/en/cowboy/1.0/guide/rest_start.svg create mode 100644 docs/en/cowboy/1.0/guide/routing/index.html create mode 100644 docs/en/cowboy/1.0/guide/static_handlers/index.html create mode 100644 docs/en/cowboy/1.0/guide/upgrade_protocol/index.html create mode 100644 docs/en/cowboy/1.0/guide/ws_handlers/index.html create mode 100644 docs/en/cowboy/1.0/guide/ws_protocol/index.html create mode 100644 docs/en/cowboy/1.0/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_app/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_handler/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_http_handler/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_loop_handler/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_middleware/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_protocol/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_req/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_rest/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_router/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_spdy/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_static/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_sub_protocol/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_websocket/index.html create mode 100644 docs/en/cowboy/1.0/manual/cowboy_websocket_handler/index.html create mode 100644 docs/en/cowboy/1.0/manual/http_status_codes/index.html create mode 100644 docs/en/cowboy/1.0/manual/index.html create mode 100644 docs/en/cowboy/2.0/guide/architecture.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/architecture/index.html create mode 100644 docs/en/cowboy/2.0/guide/broken_clients.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/broken_clients/index.html create mode 100644 docs/en/cowboy/2.0/guide/constraints.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/constraints/index.html create mode 100644 docs/en/cowboy/2.0/guide/cookies.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/cookies/index.html create mode 100644 docs/en/cowboy/2.0/guide/erlang_beginners.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/erlang_beginners/index.html create mode 100644 docs/en/cowboy/2.0/guide/erlang_web.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/erlang_web/index.html create mode 100644 docs/en/cowboy/2.0/guide/getting_started.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/getting_started/index.html create mode 100644 docs/en/cowboy/2.0/guide/handlers.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/handlers/index.html create mode 100644 docs/en/cowboy/2.0/guide/hooks.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/hooks/index.html create mode 100644 docs/en/cowboy/2.0/guide/http_req_resp.png create mode 100644 docs/en/cowboy/2.0/guide/http_req_resp.svg create mode 100644 docs/en/cowboy/2.0/guide/index.html create mode 100644 docs/en/cowboy/2.0/guide/introduction.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/introduction/index.html create mode 100644 docs/en/cowboy/2.0/guide/loop_handlers.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/loop_handlers/index.html create mode 100644 docs/en/cowboy/2.0/guide/middlewares.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/middlewares/index.html create mode 100644 docs/en/cowboy/2.0/guide/modern_web.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/modern_web/index.html create mode 100644 docs/en/cowboy/2.0/guide/multipart.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/multipart/index.html create mode 100644 docs/en/cowboy/2.0/guide/overview.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/overview/index.html create mode 100644 docs/en/cowboy/2.0/guide/req.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/req/index.html create mode 100644 docs/en/cowboy/2.0/guide/req_body.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/req_body/index.html create mode 100644 docs/en/cowboy/2.0/guide/resource_design.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/resource_design/index.html create mode 100644 docs/en/cowboy/2.0/guide/resp.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/resp/index.html create mode 100644 docs/en/cowboy/2.0/guide/rest_cond.png create mode 100644 docs/en/cowboy/2.0/guide/rest_cond.svg create mode 100644 docs/en/cowboy/2.0/guide/rest_conneg.png create mode 100644 docs/en/cowboy/2.0/guide/rest_conneg.svg create mode 100644 docs/en/cowboy/2.0/guide/rest_delete.png create mode 100644 docs/en/cowboy/2.0/guide/rest_delete.svg create mode 100644 docs/en/cowboy/2.0/guide/rest_flowcharts.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/rest_flowcharts/index.html create mode 100644 docs/en/cowboy/2.0/guide/rest_get_head.png create mode 100644 docs/en/cowboy/2.0/guide/rest_get_head.svg create mode 100644 docs/en/cowboy/2.0/guide/rest_handlers.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/rest_handlers/index.html create mode 100644 docs/en/cowboy/2.0/guide/rest_options.png create mode 100644 docs/en/cowboy/2.0/guide/rest_options.svg create mode 100644 docs/en/cowboy/2.0/guide/rest_principles.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/rest_principles/index.html create mode 100644 docs/en/cowboy/2.0/guide/rest_put_post_patch.png create mode 100644 docs/en/cowboy/2.0/guide/rest_put_post_patch.svg create mode 100644 docs/en/cowboy/2.0/guide/rest_start.png create mode 100644 docs/en/cowboy/2.0/guide/rest_start.svg create mode 100644 docs/en/cowboy/2.0/guide/routing.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/routing/index.html create mode 100644 docs/en/cowboy/2.0/guide/static_files.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/static_files/index.html create mode 100644 docs/en/cowboy/2.0/guide/sub_protocols.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/sub_protocols/index.html create mode 100644 docs/en/cowboy/2.0/guide/ws_handlers.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/ws_handlers/index.html create mode 100644 docs/en/cowboy/2.0/guide/ws_protocol.asciidoc create mode 100644 docs/en/cowboy/2.0/guide/ws_protocol/index.html create mode 100644 docs/en/cowboy/2.0/index.html create mode 100644 docs/en/cowboy/2.0/manual/cowboy/index.html create mode 100644 docs/en/cowboy/2.0/manual/cowboy_app/index.html create mode 100644 docs/en/cowboy/2.0/manual/cowboy_handler/index.html create mode 100644 docs/en/cowboy/2.0/manual/cowboy_loop/index.html create mode 100644 docs/en/cowboy/2.0/manual/cowboy_middleware/index.html create mode 100644 docs/en/cowboy/2.0/manual/cowboy_protocol/index.html create mode 100644 docs/en/cowboy/2.0/manual/cowboy_req/index.html create mode 100644 docs/en/cowboy/2.0/manual/cowboy_rest/index.html create mode 100644 docs/en/cowboy/2.0/manual/cowboy_router/index.html create mode 100644 docs/en/cowboy/2.0/manual/cowboy_static/index.html create mode 100644 docs/en/cowboy/2.0/manual/cowboy_sub_protocol/index.html create mode 100644 docs/en/cowboy/2.0/manual/cowboy_websocket/index.html create mode 100644 docs/en/cowboy/2.0/manual/http_status_codes/index.html create mode 100644 docs/en/cowboy/2.0/manual/index.html create mode 100644 docs/en/cowboy/HEAD/guide/index.html create mode 100644 docs/en/cowboy/HEAD/index.html create mode 100644 docs/en/cowboy/HEAD/manual/index.html create mode 100644 docs/en/cowboy/index.html create mode 100644 docs/en/erlang.mk/1/guide/app.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/app/index.html create mode 100644 docs/en/erlang.mk/1/guide/asciidoc.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/asciidoc/index.html create mode 100644 docs/en/erlang.mk/1/guide/ci.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/ci/index.html create mode 100644 docs/en/erlang.mk/1/guide/common_test.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/common_test/index.html create mode 100644 docs/en/erlang.mk/1/guide/compat.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/compat/index.html create mode 100644 docs/en/erlang.mk/1/guide/contributing.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/contributing/index.html create mode 100644 docs/en/erlang.mk/1/guide/coverage.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/coverage/index.html create mode 100644 docs/en/erlang.mk/1/guide/deps.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/deps/index.html create mode 100644 docs/en/erlang.mk/1/guide/dialyzer.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/dialyzer/index.html create mode 100644 docs/en/erlang.mk/1/guide/edoc.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/edoc/index.html create mode 100644 docs/en/erlang.mk/1/guide/escripts.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/escripts/index.html create mode 100644 docs/en/erlang.mk/1/guide/eunit.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/eunit/index.html create mode 100644 docs/en/erlang.mk/1/guide/external_plugins.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/external_plugins/index.html create mode 100644 docs/en/erlang.mk/1/guide/external_plugins_list.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/external_plugins_list/index.html create mode 100644 docs/en/erlang.mk/1/guide/getting_started.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/getting_started/index.html create mode 100644 docs/en/erlang.mk/1/guide/history.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/history/index.html create mode 100644 docs/en/erlang.mk/1/guide/index.html create mode 100644 docs/en/erlang.mk/1/guide/installation.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/installation/index.html create mode 100644 docs/en/erlang.mk/1/guide/limitations.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/limitations/index.html create mode 100644 docs/en/erlang.mk/1/guide/overview.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/overview/index.html create mode 100644 docs/en/erlang.mk/1/guide/ports.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/ports/index.html create mode 100644 docs/en/erlang.mk/1/guide/releases.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/releases/index.html create mode 100644 docs/en/erlang.mk/1/guide/shell.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/shell/index.html create mode 100644 docs/en/erlang.mk/1/guide/updating.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/updating/index.html create mode 100644 docs/en/erlang.mk/1/guide/why.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/why/index.html create mode 100644 docs/en/erlang.mk/1/guide/xref.asciidoc create mode 100644 docs/en/erlang.mk/1/guide/xref/index.html create mode 100644 docs/en/erlang.mk/1/index.html create mode 100644 docs/en/erlang.mk/index.html create mode 100644 docs/en/gun/1.0/guide/connect.asciidoc create mode 100644 docs/en/gun/1.0/guide/connect/index.html create mode 100644 docs/en/gun/1.0/guide/http.asciidoc create mode 100644 docs/en/gun/1.0/guide/http/index.html create mode 100644 docs/en/gun/1.0/guide/index.html create mode 100644 docs/en/gun/1.0/guide/introduction.asciidoc create mode 100644 docs/en/gun/1.0/guide/introduction/index.html create mode 100644 docs/en/gun/1.0/guide/protocols.asciidoc create mode 100644 docs/en/gun/1.0/guide/protocols/index.html create mode 100644 docs/en/gun/1.0/guide/start.asciidoc create mode 100644 docs/en/gun/1.0/guide/start/index.html create mode 100644 docs/en/gun/1.0/guide/websocket.asciidoc create mode 100644 docs/en/gun/1.0/guide/websocket/index.html create mode 100644 docs/en/gun/1.0/index.html create mode 100644 docs/en/gun/1.0/manual/gun/index.html create mode 100644 docs/en/gun/1.0/manual/gun_app/index.html create mode 100644 docs/en/gun/1.0/manual/index.html create mode 100644 docs/en/gun/index.html create mode 100644 docs/en/index.html create mode 100644 docs/en/ranch/1.2/guide/embedded.asciidoc create mode 100644 docs/en/ranch/1.2/guide/embedded/index.html create mode 100644 docs/en/ranch/1.2/guide/index.html create mode 100644 docs/en/ranch/1.2/guide/internals.asciidoc create mode 100644 docs/en/ranch/1.2/guide/internals/index.html create mode 100644 docs/en/ranch/1.2/guide/introduction.asciidoc create mode 100644 docs/en/ranch/1.2/guide/introduction/index.html create mode 100644 docs/en/ranch/1.2/guide/listeners.asciidoc create mode 100644 docs/en/ranch/1.2/guide/listeners/index.html create mode 100644 docs/en/ranch/1.2/guide/parsers.asciidoc create mode 100644 docs/en/ranch/1.2/guide/parsers/index.html create mode 100644 docs/en/ranch/1.2/guide/protocols.asciidoc create mode 100644 docs/en/ranch/1.2/guide/protocols/index.html create mode 100644 docs/en/ranch/1.2/guide/ssl_auth.asciidoc create mode 100644 docs/en/ranch/1.2/guide/ssl_auth/index.html create mode 100644 docs/en/ranch/1.2/guide/transports.asciidoc create mode 100644 docs/en/ranch/1.2/guide/transports/index.html create mode 100644 docs/en/ranch/1.2/index.html create mode 100644 docs/en/ranch/1.2/manual/index.html create mode 100644 docs/en/ranch/1.2/manual/ranch/index.html create mode 100644 docs/en/ranch/1.2/manual/ranch_app/index.html create mode 100644 docs/en/ranch/1.2/manual/ranch_protocol/index.html create mode 100644 docs/en/ranch/1.2/manual/ranch_ssl/index.html create mode 100644 docs/en/ranch/1.2/manual/ranch_tcp/index.html create mode 100644 docs/en/ranch/1.2/manual/ranch_transport/index.html create mode 100644 docs/en/ranch/index.html create mode 100644 docs/index.html create mode 100644 docs/index.xml create mode 100644 donate/index.html create mode 100644 img/big_bullet.png create mode 100644 img/body_bg.jpg create mode 100644 img/container_bg.png create mode 100644 img/footer_bg.png create mode 100644 img/footer_bg_light.png create mode 100644 img/footer_logo.png create mode 100755 img/glyphicons-halflings-white.png create mode 100755 img/glyphicons-halflings.png create mode 100644 img/header_bg.jpg create mode 100644 img/header_bg_center.jpg create mode 100644 img/header_center.jpg create mode 100644 img/header_line.png create mode 100644 img/home/carousel_bg_blue.png create mode 100644 img/home/carousel_light_effect.png create mode 100644 img/home/consulting_ico.jpg create mode 100644 img/home/detail_bg.png create mode 100644 img/home/support_ico.jpg create mode 100644 img/home/training_ico.jpg create mode 100644 img/ico/apple-touch-icon-114.png create mode 100644 img/ico/apple-touch-icon-57.png create mode 100644 img/ico/apple-touch-icon-72.png create mode 100644 img/ico/favicon.ico create mode 100644 img/ico_github.png create mode 100644 img/ico_github_alt.png create mode 100644 img/ico_linkedin.png create mode 100644 img/ico_linkedin_alt.png create mode 100644 img/ico_mail.png create mode 100644 img/ico_mail_alt.png create mode 100644 img/ico_microblog.png create mode 100644 img/ico_microblog_alt.png create mode 100644 img/logo.png create mode 100644 img/projects/bullet-home.png create mode 100644 img/projects/cowboy-home.png create mode 100644 img/projects/cowlib-home.png create mode 100644 img/projects/erlang.mk-home.png create mode 100644 img/projects/gun-home.png create mode 100644 img/projects/ranch-home.png create mode 100644 img/projects/sheriff-home.png create mode 100644 img/sponsors/kato.png create mode 100644 img/sponsors/shiguredo.png create mode 100644 img/sponsors/soundrop.png create mode 100644 index.html create mode 100644 index.xml create mode 100755 js/bootstrap-carousel.js create mode 100755 js/bootstrap-dropdown.js create mode 100644 js/custom.js create mode 100644 js/fuse.min.js create mode 100644 js/shCore.js create mode 100644 js/shlang/shBrushBash.js create mode 100644 js/shlang/shBrushCpp.js create mode 100644 js/shlang/shBrushErlang.js create mode 100644 js/shlang/shBrushJScript.js create mode 100644 js/shlang/shBrushPlain.js create mode 100644 res/erlanger-preview.pdf create mode 100644 res/tictactoe.erl create mode 100644 services/index.html create mode 100644 sitemap.xml create mode 100644 slogan/index.html create mode 100644 tags/index.html create mode 100644 talks/PDF/cowboy.pdf create mode 100644 talks/PDF/sheriff.pdf create mode 100644 talks/bed/bed.ezdoc create mode 100644 talks/bed/bed.html create mode 100644 talks/bed/pics/family_business.jpg create mode 100644 talks/bed/pics/mind_blown.jpg create mode 100644 talks/bed/pics/rest.jpg create mode 100644 talks/bed/pics/wondering.jpg create mode 100644 talks/bed/ui/default/blank.gif create mode 100755 talks/bed/ui/default/bodybg.gif create mode 100644 talks/bed/ui/default/framing.css create mode 100644 talks/bed/ui/default/iepngfix.htc create mode 100644 talks/bed/ui/default/opera.css create mode 100644 talks/bed/ui/default/outline.css create mode 100644 talks/bed/ui/default/pretty.css create mode 100644 talks/bed/ui/default/print.css create mode 100644 talks/bed/ui/default/s5-core.css create mode 100644 talks/bed/ui/default/slides.css create mode 100644 talks/bed/ui/default/slides.js create mode 100644 talks/bed/ui/img/footer_bg.png create mode 100644 talks/bed/ui/img/footer_logo.png create mode 100644 talks/bed/ui/img/footer_shadow.png create mode 100644 talks/bed/ui/img/logo.png create mode 100644 talks/bed/ui/img/logo.svg create mode 100644 talks/bed/ui/sh/sh99s.css create mode 100644 talks/bed/ui/sh/shBrushErlang.js create mode 100644 talks/bed/ui/sh/shBrushJScript.js create mode 100644 talks/bed/ui/sh/shBrushXml.js create mode 100644 talks/bed/ui/sh/shCore.js create mode 100644 talks/beyond-otp/beyond-otp.html create mode 100644 talks/beyond-otp/ui/default/blank.gif create mode 100755 talks/beyond-otp/ui/default/bodybg.gif create mode 100644 talks/beyond-otp/ui/default/framing.css create mode 100644 talks/beyond-otp/ui/default/iepngfix.htc create mode 100644 talks/beyond-otp/ui/default/opera.css create mode 100644 talks/beyond-otp/ui/default/outline.css create mode 100644 talks/beyond-otp/ui/default/pretty.css create mode 100644 talks/beyond-otp/ui/default/print.css create mode 100644 talks/beyond-otp/ui/default/s5-core.css create mode 100644 talks/beyond-otp/ui/default/slides.css create mode 100644 talks/beyond-otp/ui/default/slides.js create mode 100644 talks/beyond-otp/ui/img/footer_bg.png create mode 100644 talks/beyond-otp/ui/img/footer_logo.png create mode 100644 talks/beyond-otp/ui/img/footer_shadow.png create mode 100644 talks/beyond-otp/ui/img/logo.png create mode 100644 talks/beyond-otp/ui/img/logo.svg create mode 100644 talks/beyond-otp/ui/sh/sh99s.css create mode 100644 talks/beyond-otp/ui/sh/shBrushErlang.js create mode 100644 talks/beyond-otp/ui/sh/shCore.js create mode 100644 talks/cowboy-0.8/cowboy-0.8.html create mode 100644 talks/cowboy-0.8/pics/adgear.png create mode 100644 talks/cowboy-0.8/pics/cowboy.png create mode 100644 talks/cowboy-0.8/pics/popularity-feb-2013.png create mode 100644 talks/cowboy-0.8/ui/default/blank.gif create mode 100755 talks/cowboy-0.8/ui/default/bodybg.gif create mode 100644 talks/cowboy-0.8/ui/default/framing.css create mode 100644 talks/cowboy-0.8/ui/default/iepngfix.htc create mode 100644 talks/cowboy-0.8/ui/default/opera.css create mode 100644 talks/cowboy-0.8/ui/default/outline.css create mode 100644 talks/cowboy-0.8/ui/default/pretty.css create mode 100644 talks/cowboy-0.8/ui/default/print.css create mode 100644 talks/cowboy-0.8/ui/default/s5-core.css create mode 100644 talks/cowboy-0.8/ui/default/slides.css create mode 100644 talks/cowboy-0.8/ui/default/slides.js create mode 100644 talks/cowboy-0.8/ui/img/footer_bg.png create mode 100644 talks/cowboy-0.8/ui/img/footer_logo.png create mode 100644 talks/cowboy-0.8/ui/img/footer_shadow.png create mode 100644 talks/cowboy-0.8/ui/img/logo.png create mode 100644 talks/cowboy-0.8/ui/img/logo.svg create mode 100644 talks/cowboy-2/CONTRIBUTING.md create mode 100644 talks/cowboy-2/Gruntfile.js create mode 100644 talks/cowboy-2/LICENSE create mode 100644 talks/cowboy-2/README.md create mode 100644 talks/cowboy-2/css/print/paper.css create mode 100644 talks/cowboy-2/css/print/pdf.css create mode 100644 talks/cowboy-2/css/reveal.css create mode 100644 talks/cowboy-2/css/reveal.scss create mode 100644 talks/cowboy-2/css/theme/README.md create mode 100644 talks/cowboy-2/css/theme/beige.css create mode 100644 talks/cowboy-2/css/theme/black.css create mode 100644 talks/cowboy-2/css/theme/blood.css create mode 100644 talks/cowboy-2/css/theme/league.css create mode 100644 talks/cowboy-2/css/theme/moon.css create mode 100644 talks/cowboy-2/css/theme/night.css create mode 100644 talks/cowboy-2/css/theme/serif.css create mode 100644 talks/cowboy-2/css/theme/simple.css create mode 100644 talks/cowboy-2/css/theme/sky.css create mode 100644 talks/cowboy-2/css/theme/solarized.css create mode 100644 talks/cowboy-2/css/theme/source/beige.scss create mode 100644 talks/cowboy-2/css/theme/source/black.scss create mode 100644 talks/cowboy-2/css/theme/source/blood.scss create mode 100644 talks/cowboy-2/css/theme/source/league.scss create mode 100644 talks/cowboy-2/css/theme/source/moon.scss create mode 100644 talks/cowboy-2/css/theme/source/night.scss create mode 100644 talks/cowboy-2/css/theme/source/serif.scss create mode 100644 talks/cowboy-2/css/theme/source/simple.scss create mode 100644 talks/cowboy-2/css/theme/source/sky.scss create mode 100644 talks/cowboy-2/css/theme/source/solarized.scss create mode 100644 talks/cowboy-2/css/theme/source/white.scss create mode 100644 talks/cowboy-2/css/theme/template/mixins.scss create mode 100644 talks/cowboy-2/css/theme/template/settings.scss create mode 100644 talks/cowboy-2/css/theme/template/theme.scss create mode 100644 talks/cowboy-2/css/theme/white.css create mode 100644 talks/cowboy-2/index.html create mode 100644 talks/cowboy-2/js/reveal.js create mode 100644 talks/cowboy-2/lib/css/zenburn.css create mode 100644 talks/cowboy-2/lib/font/league-gothic/LICENSE create mode 100644 talks/cowboy-2/lib/font/league-gothic/league-gothic.css create mode 100755 talks/cowboy-2/lib/font/league-gothic/league-gothic.eot create mode 100755 talks/cowboy-2/lib/font/league-gothic/league-gothic.ttf create mode 100755 talks/cowboy-2/lib/font/league-gothic/league-gothic.woff create mode 100644 talks/cowboy-2/lib/font/source-sans-pro/LICENSE create mode 100755 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-italic.eot create mode 100755 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-italic.ttf create mode 100755 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-italic.woff create mode 100755 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-regular.eot create mode 100755 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-regular.ttf create mode 100755 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-regular.woff create mode 100755 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-semibold.eot create mode 100755 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-semibold.ttf create mode 100755 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-semibold.woff create mode 100755 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-semibolditalic.eot create mode 100755 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-semibolditalic.ttf create mode 100755 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro-semibolditalic.woff create mode 100644 talks/cowboy-2/lib/font/source-sans-pro/source-sans-pro.css create mode 100644 talks/cowboy-2/lib/js/classList.js create mode 100644 talks/cowboy-2/lib/js/head.min.js create mode 100644 talks/cowboy-2/lib/js/html5shiv.js create mode 100644 talks/cowboy-2/package.json create mode 100644 talks/cowboy-2/plugin/highlight/highlight.js create mode 100644 talks/cowboy-2/plugin/leap/leap.js create mode 100644 talks/cowboy-2/plugin/markdown/example.html create mode 100644 talks/cowboy-2/plugin/markdown/example.md create mode 100755 talks/cowboy-2/plugin/markdown/markdown.js create mode 100644 talks/cowboy-2/plugin/markdown/marked.js create mode 100755 talks/cowboy-2/plugin/math/math.js create mode 100644 talks/cowboy-2/plugin/multiplex/client.js create mode 100644 talks/cowboy-2/plugin/multiplex/index.js create mode 100644 talks/cowboy-2/plugin/multiplex/master.js create mode 100644 talks/cowboy-2/plugin/notes-server/client.js create mode 100644 talks/cowboy-2/plugin/notes-server/index.js create mode 100644 talks/cowboy-2/plugin/notes-server/notes.html create mode 100644 talks/cowboy-2/plugin/notes/notes.html create mode 100644 talks/cowboy-2/plugin/notes/notes.js create mode 100644 talks/cowboy-2/plugin/print-pdf/print-pdf.js create mode 100644 talks/cowboy-2/plugin/remotes/remotes.js create mode 100644 talks/cowboy-2/plugin/search/search.js create mode 100644 talks/cowboy-2/plugin/zoom-js/zoom.js create mode 100644 talks/cowboy-2/test/examples/assets/image1.png create mode 100644 talks/cowboy-2/test/examples/assets/image2.png create mode 100644 talks/cowboy-2/test/examples/barebones.html create mode 100644 talks/cowboy-2/test/examples/embedded-media.html create mode 100644 talks/cowboy-2/test/examples/math.html create mode 100644 talks/cowboy-2/test/examples/slide-backgrounds.html create mode 100644 talks/cowboy-2/test/examples/slide-transitions.html create mode 100644 talks/cowboy-2/test/qunit-1.12.0.css create mode 100644 talks/cowboy-2/test/qunit-1.12.0.js create mode 100644 talks/cowboy-2/test/test-markdown-element-attributes.html create mode 100644 talks/cowboy-2/test/test-markdown-element-attributes.js create mode 100644 talks/cowboy-2/test/test-markdown-slide-attributes.html create mode 100644 talks/cowboy-2/test/test-markdown-slide-attributes.js create mode 100644 talks/cowboy-2/test/test-markdown.html create mode 100644 talks/cowboy-2/test/test-markdown.js create mode 100644 talks/cowboy-2/test/test-pdf.html create mode 100644 talks/cowboy-2/test/test-pdf.js create mode 100644 talks/cowboy-2/test/test.html create mode 100644 talks/cowboy-2/test/test.js create mode 100644 talks/cowboy-d3/cowboy-d3.html create mode 100644 talks/cowboy-d3/ui/default/blank.gif create mode 100755 talks/cowboy-d3/ui/default/bodybg.gif create mode 100644 talks/cowboy-d3/ui/default/framing.css create mode 100644 talks/cowboy-d3/ui/default/iepngfix.htc create mode 100644 talks/cowboy-d3/ui/default/opera.css create mode 100644 talks/cowboy-d3/ui/default/outline.css create mode 100644 talks/cowboy-d3/ui/default/pretty.css create mode 100644 talks/cowboy-d3/ui/default/print.css create mode 100644 talks/cowboy-d3/ui/default/s5-core.css create mode 100644 talks/cowboy-d3/ui/default/slides.css create mode 100644 talks/cowboy-d3/ui/default/slides.js create mode 100644 talks/cowboy-d3/ui/img/footer_bg.png create mode 100644 talks/cowboy-d3/ui/img/footer_logo.png create mode 100644 talks/cowboy-d3/ui/img/footer_shadow.png create mode 100644 talks/cowboy-d3/ui/img/logo.png create mode 100644 talks/cowboy-d3/ui/img/logo.svg create mode 100644 talks/cowboy-d3/ui/sh/sh99s.css create mode 100644 talks/cowboy-d3/ui/sh/shBrushErlang.js create mode 100644 talks/cowboy-d3/ui/sh/shBrushJScript.js create mode 100644 talks/cowboy-d3/ui/sh/shBrushXml.js create mode 100644 talks/cowboy-d3/ui/sh/shCore.js create mode 100644 talks/cowboy-websocket/cowboy-websocket.html create mode 100644 talks/cowboy-websocket/ui/default/blank.gif create mode 100755 talks/cowboy-websocket/ui/default/bodybg.gif create mode 100644 talks/cowboy-websocket/ui/default/framing.css create mode 100644 talks/cowboy-websocket/ui/default/iepngfix.htc create mode 100644 talks/cowboy-websocket/ui/default/opera.css create mode 100644 talks/cowboy-websocket/ui/default/outline.css create mode 100644 talks/cowboy-websocket/ui/default/pretty.css create mode 100644 talks/cowboy-websocket/ui/default/print.css create mode 100644 talks/cowboy-websocket/ui/default/s5-core.css create mode 100644 talks/cowboy-websocket/ui/default/slides.css create mode 100644 talks/cowboy-websocket/ui/default/slides.js create mode 100644 talks/cowboy-websocket/ui/img/footer_bg.png create mode 100644 talks/cowboy-websocket/ui/img/footer_logo.png create mode 100644 talks/cowboy-websocket/ui/img/footer_shadow.png create mode 100644 talks/cowboy-websocket/ui/img/logo.png create mode 100644 talks/cowboy-websocket/ui/img/logo.svg create mode 100644 talks/cowboy/Makefile create mode 100644 talks/cowboy/all.ld create mode 100644 talks/cowboy/all.lt create mode 100644 talks/cowboy/lout.li create mode 100644 talks/cowboy/myslides create mode 100644 talks/erlang-cowboy/erlang-cowboy-fr-unis.html create mode 100644 talks/erlang-cowboy/ui/default/blank.gif create mode 100755 talks/erlang-cowboy/ui/default/bodybg.gif create mode 100644 talks/erlang-cowboy/ui/default/framing.css create mode 100644 talks/erlang-cowboy/ui/default/iepngfix.htc create mode 100644 talks/erlang-cowboy/ui/default/opera.css create mode 100644 talks/erlang-cowboy/ui/default/outline.css create mode 100644 talks/erlang-cowboy/ui/default/pretty.css create mode 100644 talks/erlang-cowboy/ui/default/print.css create mode 100644 talks/erlang-cowboy/ui/default/s5-core.css create mode 100644 talks/erlang-cowboy/ui/default/slides.css create mode 100644 talks/erlang-cowboy/ui/default/slides.js create mode 100644 talks/erlang-cowboy/ui/img/footer_bg.png create mode 100644 talks/erlang-cowboy/ui/img/footer_logo.png create mode 100644 talks/erlang-cowboy/ui/img/footer_shadow.png create mode 100644 talks/erlang-cowboy/ui/img/logo.png create mode 100644 talks/erlang-cowboy/ui/img/logo.svg create mode 100644 talks/erlang-tokyo-2012-09/erlang-tokyo-2012-09.html create mode 100644 talks/erlang-tokyo-2012-09/pics/bullet.png create mode 100644 talks/erlang-tokyo-2012-09/pics/cowboy.png create mode 100644 talks/erlang-tokyo-2012-09/ui/default/blank.gif create mode 100755 talks/erlang-tokyo-2012-09/ui/default/bodybg.gif create mode 100644 talks/erlang-tokyo-2012-09/ui/default/framing.css create mode 100644 talks/erlang-tokyo-2012-09/ui/default/iepngfix.htc create mode 100644 talks/erlang-tokyo-2012-09/ui/default/opera.css create mode 100644 talks/erlang-tokyo-2012-09/ui/default/outline.css create mode 100644 talks/erlang-tokyo-2012-09/ui/default/pretty.css create mode 100644 talks/erlang-tokyo-2012-09/ui/default/print.css create mode 100644 talks/erlang-tokyo-2012-09/ui/default/s5-core.css create mode 100644 talks/erlang-tokyo-2012-09/ui/default/slides.css create mode 100644 talks/erlang-tokyo-2012-09/ui/default/slides.js create mode 100644 talks/erlang-tokyo-2012-09/ui/img/footer_bg.png create mode 100644 talks/erlang-tokyo-2012-09/ui/img/footer_logo.png create mode 100644 talks/erlang-tokyo-2012-09/ui/img/footer_shadow.png create mode 100644 talks/erlang-tokyo-2012-09/ui/img/logo.png create mode 100644 talks/erlang-tokyo-2012-09/ui/img/logo.svg create mode 100644 talks/farwest/farwest.html create mode 100644 talks/farwest/ui/default/blank.gif create mode 100755 talks/farwest/ui/default/bodybg.gif create mode 100644 talks/farwest/ui/default/framing.css create mode 100644 talks/farwest/ui/default/iepngfix.htc create mode 100644 talks/farwest/ui/default/opera.css create mode 100644 talks/farwest/ui/default/outline.css create mode 100644 talks/farwest/ui/default/pretty.css create mode 100644 talks/farwest/ui/default/print.css create mode 100644 talks/farwest/ui/default/s5-core.css create mode 100644 talks/farwest/ui/default/slides.css create mode 100644 talks/farwest/ui/default/slides.js create mode 100644 talks/farwest/ui/img/footer_bg.png create mode 100644 talks/farwest/ui/img/footer_logo.png create mode 100644 talks/farwest/ui/img/footer_shadow.png create mode 100644 talks/farwest/ui/img/logo.png create mode 100644 talks/farwest/ui/img/logo.svg create mode 100644 talks/index.html create mode 100644 talks/oscon2012/oscon2012.html create mode 100644 talks/oscon2012/pics/cowboy.png create mode 100644 talks/oscon2012/pics/erlang_movie.jpg create mode 100644 talks/oscon2012/pics/hello_world.png create mode 100644 talks/oscon2012/pics/horse.png create mode 100644 talks/oscon2012/pics/php_fcgi.png create mode 100644 talks/oscon2012/pics/raspberry_pi.png create mode 100644 talks/oscon2012/pics/real_load.png create mode 100644 talks/oscon2012/pics/static.png create mode 100644 talks/oscon2012/pics/web_today.gif create mode 100644 talks/oscon2012/pics/web_yesterday.gif create mode 100644 talks/oscon2012/pics/wsdemo.png create mode 100644 talks/oscon2012/ui/default/blank.gif create mode 100755 talks/oscon2012/ui/default/bodybg.gif create mode 100644 talks/oscon2012/ui/default/framing.css create mode 100644 talks/oscon2012/ui/default/iepngfix.htc create mode 100644 talks/oscon2012/ui/default/opera.css create mode 100644 talks/oscon2012/ui/default/outline.css create mode 100644 talks/oscon2012/ui/default/pretty.css create mode 100644 talks/oscon2012/ui/default/print.css create mode 100644 talks/oscon2012/ui/default/s5-core.css create mode 100644 talks/oscon2012/ui/default/slides.css create mode 100644 talks/oscon2012/ui/default/slides.js create mode 100644 talks/oscon2012/ui/img/footer_bg.png create mode 100644 talks/oscon2012/ui/img/footer_logo.png create mode 100644 talks/oscon2012/ui/img/footer_shadow.png create mode 100644 talks/oscon2012/ui/img/logo.png create mode 100644 talks/oscon2012/ui/img/logo.svg create mode 100644 talks/ranch-msgpack/ranch-msgpack.html create mode 100644 talks/ranch-msgpack/ui/default/blank.gif create mode 100755 talks/ranch-msgpack/ui/default/bodybg.gif create mode 100644 talks/ranch-msgpack/ui/default/framing.css create mode 100644 talks/ranch-msgpack/ui/default/iepngfix.htc create mode 100644 talks/ranch-msgpack/ui/default/opera.css create mode 100644 talks/ranch-msgpack/ui/default/outline.css create mode 100644 talks/ranch-msgpack/ui/default/pretty.css create mode 100644 talks/ranch-msgpack/ui/default/print.css create mode 100644 talks/ranch-msgpack/ui/default/s5-core.css create mode 100644 talks/ranch-msgpack/ui/default/slides.css create mode 100644 talks/ranch-msgpack/ui/default/slides.js create mode 100644 talks/ranch-msgpack/ui/img/footer_bg.png create mode 100644 talks/ranch-msgpack/ui/img/footer_logo.png create mode 100644 talks/ranch-msgpack/ui/img/footer_shadow.png create mode 100644 talks/ranch-msgpack/ui/img/logo.png create mode 100644 talks/ranch-msgpack/ui/img/logo.svg create mode 100644 talks/reverse-engineering/reverse-engineering.html create mode 100644 talks/reverse-engineering/ui/default/blank.gif create mode 100755 talks/reverse-engineering/ui/default/bodybg.gif create mode 100644 talks/reverse-engineering/ui/default/framing.css create mode 100644 talks/reverse-engineering/ui/default/iepngfix.htc create mode 100644 talks/reverse-engineering/ui/default/opera.css create mode 100644 talks/reverse-engineering/ui/default/outline.css create mode 100644 talks/reverse-engineering/ui/default/pretty.css create mode 100644 talks/reverse-engineering/ui/default/print.css create mode 100644 talks/reverse-engineering/ui/default/s5-core.css create mode 100644 talks/reverse-engineering/ui/default/slides.css create mode 100644 talks/reverse-engineering/ui/default/slides.js create mode 100644 talks/reverse-engineering/ui/img/footer_bg.png create mode 100644 talks/reverse-engineering/ui/img/footer_logo.png create mode 100644 talks/reverse-engineering/ui/img/footer_shadow.png create mode 100644 talks/reverse-engineering/ui/img/logo.png create mode 100644 talks/reverse-engineering/ui/img/logo.svg create mode 100644 talks/sheriff/Makefile create mode 100644 talks/sheriff/all.ld create mode 100644 talks/sheriff/all.lt create mode 100644 talks/sheriff/badge.eps create mode 100644 talks/sheriff/lout.li create mode 100644 talks/sheriff/myslides create mode 100644 talks/sheriff/wilza.eps create mode 100644 talks/thinking-in-erlang/pics/building_blocks_code.png create mode 100644 talks/thinking-in-erlang/pics/building_blocks_code.svg create mode 100644 talks/thinking-in-erlang/pics/building_blocks_data.png create mode 100644 talks/thinking-in-erlang/pics/building_blocks_data.svg create mode 100644 talks/thinking-in-erlang/pics/links_crash_1.png create mode 100644 talks/thinking-in-erlang/pics/links_crash_1.svg create mode 100644 talks/thinking-in-erlang/pics/links_crash_2.png create mode 100644 talks/thinking-in-erlang/pics/links_crash_2.svg create mode 100644 talks/thinking-in-erlang/pics/links_trap_exit_1.png create mode 100644 talks/thinking-in-erlang/pics/links_trap_exit_1.svg create mode 100644 talks/thinking-in-erlang/pics/links_trap_exit_2.png create mode 100644 talks/thinking-in-erlang/pics/links_trap_exit_2.svg create mode 100644 talks/thinking-in-erlang/thinking-in-erlang.html create mode 100644 talks/thinking-in-erlang/ui/default/blank.gif create mode 100755 talks/thinking-in-erlang/ui/default/bodybg.gif create mode 100644 talks/thinking-in-erlang/ui/default/framing.css create mode 100644 talks/thinking-in-erlang/ui/default/iepngfix.htc create mode 100644 talks/thinking-in-erlang/ui/default/opera.css create mode 100644 talks/thinking-in-erlang/ui/default/outline.css create mode 100644 talks/thinking-in-erlang/ui/default/pretty.css create mode 100644 talks/thinking-in-erlang/ui/default/print.css create mode 100644 talks/thinking-in-erlang/ui/default/s5-core.css create mode 100644 talks/thinking-in-erlang/ui/default/slides.css create mode 100644 talks/thinking-in-erlang/ui/default/slides.js create mode 100644 talks/thinking-in-erlang/ui/img/footer_bg.png create mode 100644 talks/thinking-in-erlang/ui/img/footer_logo.png create mode 100644 talks/thinking-in-erlang/ui/img/footer_shadow.png create mode 100644 talks/thinking-in-erlang/ui/img/logo.png create mode 100644 talks/thinking-in-erlang/ui/img/logo.svg create mode 100644 talks/thinking-in-erlang/ui/sh/sh99s.css create mode 100644 talks/thinking-in-erlang/ui/sh/shBrushErlang.js create mode 100644 talks/thinking-in-erlang/ui/sh/shCore.js create mode 100644 training/index.html diff --git a/.gitignore b/.gitignore new file mode 100644 index 00000000..6fd45092 --- /dev/null +++ b/.gitignore @@ -0,0 +1,3 @@ +_build/content/docs +_build/static/docs +_build/tmp diff --git a/CNAME b/CNAME new file mode 100644 index 00000000..f6a42dd6 --- /dev/null +++ b/CNAME @@ -0,0 +1 @@ +ninenines.eu diff --git a/_build/Makefile b/_build/Makefile new file mode 100644 index 00000000..ff546315 --- /dev/null +++ b/_build/Makefile @@ -0,0 +1,104 @@ +.PHONY: all clean docs + +PROJECTS = $(sort $(notdir $(basename $(wildcard data/projects/*.toml)))) + +all: docs + hugo --theme=ninenines -d .. + +server: docs + hugo server --theme=ninenines + +clean: DOC_FILES = $(filter-out static/docs/en/cowboy/1.0,$(wildcard static/docs/en/*/*)) +clean: OUTPUT_FILES = $(filter-out ../_build,$(wildcard ../*)) +clean: + rm -rf content/docs tmp + $(if $(OUTPUT_FILES),rm -rf $(OUTPUT_FILES)) + $(if $(DOC_FILES),rm -rf $(DOC_FILES)) + +tmp: clean + mkdir tmp/ + +# For substitution. +comma := , + +define docs-version-target + +.PHONY: docs-$1-$2 + +docs-$1-$2: tmp/$1 + cd tmp/$1 && git checkout $4 + if [ -f tmp/$1/doc/src/guide/book.asciidoc ]; then \ + mkdir -p content/docs/en/$1/$3/guide/; \ + echo "+++" > content/docs/en/$1/$3/guide.asciidoc; \ + echo -n "title = \"" >> content/docs/en/$1/$3/guide.asciidoc; \ + echo -n `sed -n '1,/^= .*/ s/^= //p' tmp/$1/doc/src/guide/book.asciidoc` \ + >> content/docs/en/$1/$3/guide.asciidoc; \ + echo "\"" >> content/docs/en/$1/$3/guide.asciidoc; \ + printf "%s\n" "project = \"$1\"" "version = \"$3\"" "doctype = \"guide\"" \ + >> content/docs/en/$1/$3/guide.asciidoc; \ + echo "+++" >> content/docs/en/$1/$3/guide.asciidoc; \ + sed -E 's/include::([a-z_]*)\.asciidoc(.*)/* link:\1\/\2/' tmp/$1/doc/src/guide/book.asciidoc \ + | sed -n '/^= /,$$$$p' \ + | sed -n '/^$$$$/,$$$$p' \ + | sed 's/^= /== /' >> content/docs/en/$1/$3/guide.asciidoc; \ + rm tmp/$1/doc/src/guide/book.asciidoc; \ + for f in tmp/$1/doc/src/guide/*.asciidoc; do \ + printf "%s\n" "+++" "project = \"$1\"" "version = \"$3\"" "doctype = \"guide\"" \ + > content/docs/en/$1/$3/guide/`basename $$$$f`; \ + echo -n "title = \"" >> content/docs/en/$1/$3/guide/`basename $$$$f`; \ + echo -n `sed -n '1,/^== .*/ s/^== //p' $$$$f` >> content/docs/en/$1/$3/guide/`basename $$$$f`; \ + echo "\"" >> content/docs/en/$1/$3/guide/`basename $$$$f`; \ + echo "+++" >> content/docs/en/$1/$3/guide/`basename $$$$f`; \ + echo >> content/docs/en/$1/$3/guide/`basename $$$$f`; \ + sed '1,/^$$$$/d' $$$$f | sed 's/^=== /== /' \ + | sed 's/xref:/link:..\//' | sed 's/image::/image::..\//' \ + >> content/docs/en/$1/$3/guide/`basename $$$$f`; \ + done; \ + mkdir -p static/docs/en/$1/$3/guide/; \ + cp tmp/$1/doc/src/guide/* static/docs/en/$1/$3/guide/; \ + fi + if [ -f tmp/$1/doc/src/manual/$1.asciidoc ]; then \ + mkdir -p content/docs/en/$1/$3/manual/; \ + printf "%s\n" "+++" "title = \"`sed 's/\(.\)/\U\1/' <<< $1` Function Reference\"" \ + "project = \"$1\"" "version = \"$3\"" "doctype = \"manual\"" "+++" "" \ + > content/docs/en/$1/$3/manual.asciidoc; \ + for f in `ls tmp/$1/doc/src/manual/*.asciidoc | sort`; do \ + echo -n "* link:`basename $$$$f .asciidoc`[" >> content/docs/en/$1/$3/manual.asciidoc; \ + echo -n `sed -En '0,/^= / s/= (.*)/\1/ p' $$$$f` >> content/docs/en/$1/$3/manual.asciidoc; \ + echo "]" >> content/docs/en/$1/$3/manual.asciidoc; \ + done; \ + for f in tmp/$1/doc/src/manual/*.asciidoc; do \ + printf "%s\n" "+++" "project = \"$1\"" "version = \"$3\"" "doctype = \"manual\"" \ + > content/docs/en/$1/$3/manual/`basename $$$$f`; \ + echo -n "title = \"" >> content/docs/en/$1/$3/manual/`basename $$$$f`; \ + echo -n `sed -n '1,/^= .*/ s/^= //p' $$$$f` >> content/docs/en/$1/$3/manual/`basename $$$$f`; \ + echo "\"" >> content/docs/en/$1/$3/manual/`basename $$$$f`; \ + echo "+++" >> content/docs/en/$1/$3/manual/`basename $$$$f`; \ + echo >> content/docs/en/$1/$3/manual/`basename $$$$f`; \ + sed '1,/^$$$$/d' $$$$f | sed 's/xref:/link:..\//' >> content/docs/en/$1/$3/manual/`basename $$$$f`; \ + done \ + fi + +endef + +define docs-target + +$(eval include data/projects/$1.toml) +$(eval VERSIONS := $(subst $(comma),,$(subst ],,$(subst [,,$(versions))))) +$(eval BRANCHES := $(subst $(comma),,$(subst ],,$(subst [,,$(branches))))) +$(eval TARGETS := $(shell echo "1 2 3 4 5 6 7 8 9" | cut -d' ' -f 1-$(words $(VERSIONS)))) + +tmp/$1: + cd tmp && git clone $(repository) + +.PHONY: docs-$1 $(foreach t,$(TARGETS),docs-$1-$t) + +$(eval $(foreach t,$(TARGETS),$(call docs-version-target,$1,$t,$(word $t,$(VERSIONS)),$(word $t,$(BRANCHES))))) + +docs-$1: tmp $(foreach t,$(TARGETS),docs-$1-$t) + +docs:: docs-$1 + +endef + +$(eval $(foreach p,$(PROJECTS),$(call docs-target,$p))) diff --git a/_build/config.toml b/_build/config.toml new file mode 100644 index 00000000..224cdffa --- /dev/null +++ b/_build/config.toml @@ -0,0 +1,11 @@ +baseurl = "http://ninenines.eu" +languagecode = "en-us" +title = "Nine Nines" +paginate = 20 + +editor = "vim" +newcontenteditor = "vim" +verbose = true + +[params] + main_project = "cowboy" diff --git a/_build/content/articles/cowboy2-qs.asciidoc b/_build/content/articles/cowboy2-qs.asciidoc new file mode 100644 index 00000000..90ef714b --- /dev/null +++ b/_build/content/articles/cowboy2-qs.asciidoc @@ -0,0 +1,184 @@ ++++ +date = "2014-08-20T00:00:00+01:00" +title = "Cowboy 2.0 and query strings" + ++++ + +Now that Cowboy 1.0 is out, I can spend some of my time thinking +about Cowboy 2.0 that will be released soon after Erlang/OTP 18.0. +This entry discusses the proposed changes to query string handling +in Cowboy. + +Cowboy 2.0 will respond to user wishes by simplifying the interface +of the `cowboy_req` module. Users want two things: less +juggling with the Req variable, and more maps. Maps is the only +dynamic key/value data structure in Erlang that we can match directly +to extract values, allowing users to greatly simplify their code as +they don't need to call functions to do everything anymore. + +Query strings are a good candidate for maps. It's a list of +key/values, so it's pretty obvious we can win a lot by using maps. +However query strings have one difference with maps: they can have +duplicate keys. + +How are we expected to handle duplicate keys? There's no standard +behavior. It's up to applications. And looking at what is done in +the wild, there's no de facto standard either. While some ignore +duplicate keys (keeping the first or the last they find), others +require duplicate keys to end with `[]` to automatically +put the values in a list, or even worse, languages like PHP even +allow you to do things like `key[something][other]` and +create a deep structure for it. Finally some allow any key to have +duplicates and just gives you lists of key/values. + +Cowboy so far had functions to retrieve query string values one +value at a time, and if there were duplicates it would return the +first it finds. It also has a function returning the entire list +with all duplicates, allowing you to filter it to get all of them, +and another function that returns the raw query string. + +What are duplicates used for? Not that many things actually. + +One use of duplicate keys is with HTML forms. It is common practice +to give all related checkboxes the same name so you get a list of +what's been checked. When nothing is checked, nothing is sent at all, +the key is not in the list. + +Another use of duplicate keys is when generating forms. A good +example of that would be a form that allows uploading any number +of files. When you add a file, client-side code adds another field +to the form. Repeat up to a certain limit. + +And that's about it. Of note is that HTML radio elements share +the same name too, but only one key/value is sent, so they are not +relevant here. + +Normally this would be the part where I tell you how we solve +this elegantly. But I had doubts. Why? Because there's no good +solutions to solving only this particular problem. + +I then stopped thinking about duplicate keys for a minute and +started to think about the larger problem. + +Query strings are input data. They take a particular form, +and may be sent as part of the URI or as part of the request +body. We have other kinds of input data. We have headers and +cookies and the request body in various forms. We also have +path segments in URIs. + +What do you do with input data? Well you use it to do +something. But there is one thing that you almost always do +(and if you don't, you really should): you validate it and +you map it into Erlang terms. + +Cowboy left the user take care of validation and conversion +into Erlang terms so far. Rather, it left the user take care +of it everywhere except one place. Guess where? That's right, +bindings. + +If you define routes with bindings then you have the option +to provide constraints. Constraints can be used to do two things: +validate the data and convert it in a more appropriate term. For +example if you use the `int` constraint, Cowboy will +make sure the binding is an integer, and will replace the value +with the integer representation so that you can use it directly. +In this particular case it not only routes the URI, but also +validates and converts the bindings directly. + +This is very relevant in the case of our duplicate keys, +because if we have a list with duplicates of a key, chances +are we want to convert that into a list of Erlang terms, and +also make sure that all the elements in this list are expected. + +The answer to this particular problem is simple. We need a +function that will parse the query string and apply constraints. +But this is not all, there is one other problem to be solved. + +The other problem is that for the user some keys are mandatory +and some are optional. Optional keys include the ones that +correspond to HTML checkboxes: if the key for one or more +checkbox is missing from the query string, we still want to +have an empty list in our map so we can easily match. Matching +maps is great, but not so much when values might be missing, +so we have to normalize this data a little. + +This problem is solved by allowing a default value. If the +key is missing and a default exists, set it. If no default +exists, then the key was mandatory and we want to crash. + +I therefore make a proposal for changing the query string +interface to three functions. + +The first function already exists, it is `cowboy_req:qs(Req)` +and it returns only the query string binary. No more Req returned. + +The second function is a renaming of `cowboy_req:qs_vals(Req)` +to something more explicit: `cowboy_req:parse_qs(Req)`. +The new name implies that a parsing operation is done. It was implicit +and cached before. It will be explicit and not cached anymore now. +Again, no more Req returned. + +The third function is the one I mentioned above. I think +the interface `cowboy_req:match_qs(Req, Fields)` is +most appropriate. It returns a normalized map that is the same +regardless of optional fields being provided with the request, +allowing for easy matching. It crashes if something went wrong. +Still no Req returned. + +I feel that this three function interface provides everything +one would need to comfortably write applications. You can get +low level and get the query string directly; you can get a list +of key/value binaries without any additional processing and do it +on your own; or you can get a processed map that contains Erlang +terms ready to be used. + +I strongly believe that by democratizing the constraints to +more than just bindings, but also to query string, cookies and +other key/values in Cowboy, we can allow the developer to quickly +and easily go from HTTP request to Erlang function calls. The +constraints are reusable functions that can serve as guards +against unwanted data, providing convenience in the process. + +Your handlers will not look like an endless series of calls +to get and convert the input data, they will instead be just +one call at the beginning followed by the actual application +logic, thanks to constraints and maps. + +[source,erlang] +---- +handle(Req, State) -> + #{name:=Name, email:=Email, choices:=ChoicesList, remember_me:=RememberMe} = + cowboy_req:match_qs(Req, [ + name, {email, email}, + {choices, fun check_choices/1, []}, + {remember_me, boolean, false}]), + save_choices(Name, Email, ChoicesList), + if RememberMe -> create_account(Name, Email); true -> ok end, + {ok, Req, State}. + +check_choices(<<"blue">>) -> {true, blue}; +check_choices(<<"red">>) -> {true, red}; +check_choices(_) -> false; +---- + +(Don't look too closely at the structure yet.) + +As you can see in the above snippet, it becomes really easy +to go from query string to values. You can also use the map +directly as it is guaranteed to only contain the keys you +specified, any extra key is not returned. + +This would I believe be a huge step up as we can now +focus on writing applications instead of translating HTTP +calls. Cowboy can now take care of it. + +And to conclude, this also solves our duplicate keys +dilemma, as they now automatically become a list of binaries, +and this list is then checked against constraints that +will fail if they were not expecting a list. And in the +example above, it even converts the values to atoms for +easier manipulation. + +As usual, feedback is more than welcome, and I apologize +for the rocky structure of this post as it contains all the +thoughts that went into this rather than just the conclusion. diff --git a/_build/content/articles/erlang-scalability.asciidoc b/_build/content/articles/erlang-scalability.asciidoc new file mode 100644 index 00000000..3fdaa445 --- /dev/null +++ b/_build/content/articles/erlang-scalability.asciidoc @@ -0,0 +1,143 @@ ++++ +date = "2013-02-18T00:00:00+01:00" +title = "Erlang Scalability" + ++++ + +I would like to share some experience and theories on +Erlang scalability. + +This will be in the form of a series of hints, which +may or may not be accompanied with explanations as to why +things are this way, or how they improve or reduce the scalability +of a system. I will try to do my best to avoid giving falsehoods, +even if that means a few things won't be explained. + +== NIFs + +NIFs are considered harmful. I don't know any single NIF-based +library that I would recommend. That doesn't mean they should +all be avoided, just that if you're going to want your system to +scale, you probably shouldn't use a NIF. + +A common case for using NIFs is JSON processing. The problem +is that JSON is a highly inefficient data structure (similar +in inefficiency to XML, although perhaps not as bad). If you can +avoid using JSON, you probably should. MessagePack can replace +it in many situations. + +Long-running NIFs will take over a scheduler and prevent Erlang +from efficiently handling many processes. + +Short-running NIFs will still confuse the scheduler if they +take more than a few microseconds to run. + +Threaded NIFs, or the use of the `enif_consume_timeslice` +might help allievate this problem, but they're not a silver bullet. + +And as you already know, a crashing NIF will take down your VM, +destroying any claims you may have at being scalable. + +Never use a NIF because "C is fast". This is only true in +single-threaded programs. + +== BIFs + +BIFs can also be harmful. While they are generally better than +NIFs, they are not perfect and some of them might have harmful +effects on the scheduler. + +A great example of this is the `erlang:decode_packet/3` +BIF, when used for HTTP request or response decoding. Avoiding +its use in _Cowboy_ allowed us to see a big increase in +the number of requests production systems were able to handle, +up to two times the original amount. Incidentally this is something +that is impossible to detect using synthetic benchmarks. + +BIFs that return immediately are perfectly fine though. + +== Binary strings + +Binary strings use less memory, which means you spend less time +allocating memory compared to list-based strings. They are also +more natural for strings manipulation because they are optimized +for appending (as opposed to prepending for lists). + +If you can process a binary string using a single match context, +then the code will run incredibly fast. The effects will be much +increased if the code was compiled using HiPE, even if your Erlang +system isn't compiled natively. + +Avoid using `binary:split` or `binary:replace` +if you can avoid it. They have a certain overhead due to supporting +many options that you probably don't need for most operations. + +== Buffering and streaming + +Use binaries. They are great for appending, and it's a direct copy +from what you receive from a stream (usually a socket or a file). + +Be careful to not indefinitely receive data, as you might end up +having a single binary taking up huge amounts of memory. + +If you stream from a socket and know how much data you expect, +then fetch that data in a single `recv` call. + +Similarly, if you can use a single `send` call, then +you should do so, to avoid going back and forth unnecessarily between +your Erlang process and the Erlang port for your socket. + +== List and binary comprehensions + +Prefer list comprehensions over `lists:map/2`. The +compiler will be able to optimize your code greatly, for example +not creating the result if you don't need it. As time goes on, +more optimizations will be added to the compiler and you will +automatically benefit from them. + +== gen_server is no silver bullet + +It's a bad idea to use `gen_server` for everything. +For two reasons. + +There is an overhead everytime the `gen_server` receives +a call, a cast or a simple message. It can be a problem if your +`gen_server` is in a critical code path where speed +is all that matters. Do not hesitate to create other kinds of +processes where it makes sense. And depending on the kind of process, +you might want to consider making them special processes, which +would essentially behave the same as a `gen_server`. + +A common mistake is to have a unique `gen_server` to +handle queries from many processes. This generally becomes the +biggest bottleneck you'll want to fix. You should try to avoid +relying on a single process, using a pool if you can. + +== Supervisor and monitoring + +A `supervisor` is also a `gen_server`, +so the previous points also apply to them. + +Sometimes you're in a situation where you have supervised +processes but also want to monitor them in one or more other +processes, effectively duplicating the work. The supervisor +already knows when processes die, why not use this to our +advantage? + +You can create a custom supervisor process that will perform +both the supervision and handle exit and other events, allowing +to avoid the combination of supervising and monitoring which +can prove harmful when many processes die at once, or when you +have many short lived processes. + +== ets for LOLSPEED(tm) + +If you have data queried or modified by many processes, then +`ets` public or protected tables will give you the +performance boost you require. Do not forget to set the +`read_concurrency` or `write_concurrency` +options though. + +You might also be thrilled to know that Erlang R16B will feature +a big performance improvement for accessing `ets` tables +concurrently. diff --git a/_build/content/articles/erlang-validate-utf8.asciidoc b/_build/content/articles/erlang-validate-utf8.asciidoc new file mode 100644 index 00000000..383afcc6 --- /dev/null +++ b/_build/content/articles/erlang-validate-utf8.asciidoc @@ -0,0 +1,202 @@ ++++ +date = "2015-03-06T00:00:00+01:00" +title = "Validating UTF-8 binaries with Erlang" + ++++ + +Yesterday I pushed Websocket permessage-deflate to +Cowboy master. I also pushed +https://github.com/ninenines/cowlib/commit/7e4983b70ddf8cedb967e36fba6a600731bdad5d[a +change in the way the code validates UTF-8 data] +(required for text and close frames as per the spec). + +When looking into why the permessage-deflate tests +in autobahntestsuite were taking such a long time, I +found that autobahn is using an adaptation of the +algorithm named Flexible +and Economical UTF-8 Decoder. This is the C99 +implementation: + +[source,c] +---- +// Copyright (c) 2008-2009 Bjoern Hoehrmann +// See http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ for details. + +#define UTF8_ACCEPT 0 +#define UTF8_REJECT 1 + +static const uint8_t utf8d[] = { + 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, // 00..1f + 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, // 20..3f + 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, // 40..5f + 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, // 60..7f + 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9, // 80..9f + 7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7, // a0..bf + 8,8,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2, // c0..df + 0xa,0x3,0x3,0x3,0x3,0x3,0x3,0x3,0x3,0x3,0x3,0x3,0x3,0x4,0x3,0x3, // e0..ef + 0xb,0x6,0x6,0x6,0x5,0x8,0x8,0x8,0x8,0x8,0x8,0x8,0x8,0x8,0x8,0x8, // f0..ff + 0x0,0x1,0x2,0x3,0x5,0x8,0x7,0x1,0x1,0x1,0x4,0x6,0x1,0x1,0x1,0x1, // s0..s0 + 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,1,1,1,1,1,0,1,0,1,1,1,1,1,1, // s1..s2 + 1,2,1,1,1,1,1,2,1,2,1,1,1,1,1,1,1,1,1,1,1,1,1,2,1,1,1,1,1,1,1,1, // s3..s4 + 1,2,1,1,1,1,1,1,1,2,1,1,1,1,1,1,1,1,1,1,1,1,1,3,1,3,1,1,1,1,1,1, // s5..s6 + 1,3,1,1,1,1,1,3,1,3,1,1,1,1,1,1,1,3,1,1,1,1,1,1,1,1,1,1,1,1,1,1, // s7..s8 +}; + +uint32_t inline +decode(uint32_t* state, uint32_t* codep, uint32_t byte) { + uint32_t type = utf8d[byte]; + + *codep = (*state != UTF8_ACCEPT) ? + (byte & 0x3fu) | (*codep << 6) : + (0xff >> type) & (byte); + + *state = utf8d[256 + *state*16 + type]; + return *state; +} +---- + +And this is the Erlang implementation I came up with: + +[source,erlang] +---- +%% This function returns 0 on success, 1 on error, and 2..8 on incomplete data. +validate_utf8(<<>>, State) -> State; +validate_utf8(<< C, Rest/bits >>, 0) when C < 128 -> validate_utf8(Rest, 0); +validate_utf8(<< C, Rest/bits >>, 2) when C >= 128, C < 144 -> validate_utf8(Rest, 0); +validate_utf8(<< C, Rest/bits >>, 3) when C >= 128, C < 144 -> validate_utf8(Rest, 2); +validate_utf8(<< C, Rest/bits >>, 5) when C >= 128, C < 144 -> validate_utf8(Rest, 2); +validate_utf8(<< C, Rest/bits >>, 7) when C >= 128, C < 144 -> validate_utf8(Rest, 3); +validate_utf8(<< C, Rest/bits >>, 8) when C >= 128, C < 144 -> validate_utf8(Rest, 3); +validate_utf8(<< C, Rest/bits >>, 2) when C >= 144, C < 160 -> validate_utf8(Rest, 0); +validate_utf8(<< C, Rest/bits >>, 3) when C >= 144, C < 160 -> validate_utf8(Rest, 2); +validate_utf8(<< C, Rest/bits >>, 5) when C >= 144, C < 160 -> validate_utf8(Rest, 2); +validate_utf8(<< C, Rest/bits >>, 6) when C >= 144, C < 160 -> validate_utf8(Rest, 3); +validate_utf8(<< C, Rest/bits >>, 7) when C >= 144, C < 160 -> validate_utf8(Rest, 3); +validate_utf8(<< C, Rest/bits >>, 2) when C >= 160, C < 192 -> validate_utf8(Rest, 0); +validate_utf8(<< C, Rest/bits >>, 3) when C >= 160, C < 192 -> validate_utf8(Rest, 2); +validate_utf8(<< C, Rest/bits >>, 4) when C >= 160, C < 192 -> validate_utf8(Rest, 2); +validate_utf8(<< C, Rest/bits >>, 6) when C >= 160, C < 192 -> validate_utf8(Rest, 3); +validate_utf8(<< C, Rest/bits >>, 7) when C >= 160, C < 192 -> validate_utf8(Rest, 3); +validate_utf8(<< C, Rest/bits >>, 0) when C >= 194, C < 224 -> validate_utf8(Rest, 2); +validate_utf8(<< 224, Rest/bits >>, 0) -> validate_utf8(Rest, 4); +validate_utf8(<< C, Rest/bits >>, 0) when C >= 225, C < 237 -> validate_utf8(Rest, 3); +validate_utf8(<< 237, Rest/bits >>, 0) -> validate_utf8(Rest, 5); +validate_utf8(<< C, Rest/bits >>, 0) when C =:= 238; C =:= 239 -> validate_utf8(Rest, 3); +validate_utf8(<< 240, Rest/bits >>, 0) -> validate_utf8(Rest, 6); +validate_utf8(<< C, Rest/bits >>, 0) when C =:= 241; C =:= 242; C =:= 243 -> validate_utf8(Rest, 7); +validate_utf8(<< 244, Rest/bits >>, 0) -> validate_utf8(Rest, 8); +validate_utf8(_, _) -> 1. +---- + +Does it look similar to you? So how did we get there? + +I started with a naive implementation of the original. First, we +don't need the codepoint calculated and extracted for our validation +function. We just want to know the data is valid, so we only need to +calculate the next state. Then, the only thing we needed to be careful +about was that tuples are 1-based, and that we need to stop processing +the binary when we get the state 1 or when the binary is empty. + +[source,erlang] +---- +validate_utf8(<<>>, State) -> State; +validate_utf8(_, 1) -> 1; +validate_utf8(<< C, Rest/bits >>, State) -> + validate_utf8(Rest, element(257 + State * 16 + element(1 + C, ?UTF8D), ?UTF8D)). +---- + +The macro `?UTF8D` is the tuple equivalent of the C array +in the original code. + +Compared to our previous algorithm, this performed about the same. +In some situations a little faster, in some a little slower. In other words, +not good enough. But because this new algorithm allows us to avoid a binary +concatenation this warranted looking further. + +It was time to step into crazy land. + +Erlang is very good at pattern matching, even more so than doing some +arithmetic coupled by fetching elements from a tuple. So I decided I was +going to write all possible clauses for all combinations of `C` +and `State`. And by write I mean generate. + +So I opened my Erlang shell, defined the variable `D` to be +the tuple `?UTF8D` with its 400 elements, and then ran the +following expression (after a bit of trial and error): + +[source,erlang] +---- +16> file:write_file("out.txt", + [io_lib:format("validate_utf8(<< ~p, Rest/bits >>, ~p) -> ~p;~n", + [C, S, element(257 + S * 16 + element(1 + C, D), D)]) + || C <- lists:seq(0,255), S <- lists:seq(0,8)]). +ok +---- + +The result is a 2304 lines long file, containing 2304 clauses. +People who pay attention to what I say on Twitter will remember +I said something around 3000 clauses, but that was just me not +using the right number of states in my estimate. + +There was a little more work to be done on this generated +code that I did using regular expressions. We need to recurse +when the resulting state is not 1. We also need to stop when +the binary is empty, making it the 2305th clause. + +Still, 2305 is a lot. But hey, the code did work, and faster +than the previous implementation too! But hey, perhaps I could +find a way to reduce its size. + +Removing all the clauses that return 1 and putting a catch-all +clause at the end instead reduced the number to about 500, and +showed that many clauses were similar: + +[source,erlang] +---- +validate_utf8(<< 0, Rest/bits >>, 0) -> validate_utf8(Rest, 0); +validate_utf8(<< 1, Rest/bits >>, 0) -> validate_utf8(Rest, 0); +validate_utf8(<< 2, Rest/bits >>, 0) -> validate_utf8(Rest, 0); +validate_utf8(<< 3, Rest/bits >>, 0) -> validate_utf8(Rest, 0); +validate_utf8(<< 4, Rest/bits >>, 0) -> validate_utf8(Rest, 0); +validate_utf8(<< 5, Rest/bits >>, 0) -> validate_utf8(Rest, 0); +validate_utf8(<< 6, Rest/bits >>, 0) -> validate_utf8(Rest, 0); +validate_utf8(<< 7, Rest/bits >>, 0) -> validate_utf8(Rest, 0); +---- + +But also: + +[source,erlang] +---- +validate_utf8(<< 157, Rest/bits >>, 2) -> validate_utf8(Rest, 0); +validate_utf8(<< 157, Rest/bits >>, 3) -> validate_utf8(Rest, 2); +validate_utf8(<< 157, Rest/bits >>, 5) -> validate_utf8(Rest, 2); +validate_utf8(<< 157, Rest/bits >>, 6) -> validate_utf8(Rest, 3); +validate_utf8(<< 157, Rest/bits >>, 7) -> validate_utf8(Rest, 3); +validate_utf8(<< 158, Rest/bits >>, 2) -> validate_utf8(Rest, 0); +validate_utf8(<< 158, Rest/bits >>, 3) -> validate_utf8(Rest, 2); +validate_utf8(<< 158, Rest/bits >>, 5) -> validate_utf8(Rest, 2); +validate_utf8(<< 158, Rest/bits >>, 6) -> validate_utf8(Rest, 3); +validate_utf8(<< 158, Rest/bits >>, 7) -> validate_utf8(Rest, 3); +---- + +Patterns, my favorites! + +A little more time was spent to edit the 500 or so clauses into +smaller equivalents, testing that performance was not impacted, and +comitting the result. + +The patterns above can be found here in the resulting function: + +[source,erlang] +---- +validate_utf8(<< C, Rest/bits >>, 0) when C < 128 -> validate_utf8(Rest, 0); +... +validate_utf8(<< C, Rest/bits >>, 2) when C >= 144, C < 160 -> validate_utf8(Rest, 0); +validate_utf8(<< C, Rest/bits >>, 3) when C >= 144, C < 160 -> validate_utf8(Rest, 2); +validate_utf8(<< C, Rest/bits >>, 5) when C >= 144, C < 160 -> validate_utf8(Rest, 2); +validate_utf8(<< C, Rest/bits >>, 6) when C >= 144, C < 160 -> validate_utf8(Rest, 3); +validate_utf8(<< C, Rest/bits >>, 7) when C >= 144, C < 160 -> validate_utf8(Rest, 3); +... +---- + +I hope you enjoyed this post. diff --git a/_build/content/articles/erlang.mk-and-relx.asciidoc b/_build/content/articles/erlang.mk-and-relx.asciidoc new file mode 100644 index 00000000..e8a667a8 --- /dev/null +++ b/_build/content/articles/erlang.mk-and-relx.asciidoc @@ -0,0 +1,131 @@ ++++ +date = "2013-05-28T00:00:00+01:00" +title = "Build Erlang releases with Erlang.mk and Relx" + ++++ + +Building OTP releases has always been a difficult task. Tools like +Reltool or Rebar have made this simpler, but +it's no panacea. This article will show you an alternative and +hopefully much simpler solution. + +There is two steps to building a release. First you need to build +the various OTP applications you want to include in the release. Once +done, you need to create the release itself, by including the Erlang +runtime system alongside the applications, a boot script to start the +node and all its applications, and some configuration files. + +https://github.com/extend/erlang.mk[Erlang.mk] solves +the first step. It is an include file for GNU Make. Just +including it in a Makefile is enough to allow building your project, +fetching and building dependencies, building documentation, performing +static analysis and more. + +https://github.com/erlware/relx[Relx] solves the second +step. It is a release creation tool, wrapped into a single executable +file. It doesn't require a configuration file. And if you do need one, +it will be a pretty small one. + +Let's take a look at the smallest Erlang.mk powered +Makefile. There is only one thing required: defining the project +name. + +[source,make] +---- +PROJECT = my_project + +include erlang.mk +---- + +Simply doing this allows you to build your application by typing +`make`, running tests using `make tests`, and +more. It will even compile your '.dtl' files found in the +'templates/' directory if you are using ErlyDTL! + +Let's now take a look at a simplified version of the Makefile for +this website. I only removed a few targets that were off-topic. + +[source,make] +---- +PROJECT = ninenines + +DEPS = cowboy erlydtl +dep_cowboy = https://github.com/extend/cowboy.git 0.8.5 +dep_erlydtl = https://github.com/evanmiller/erlydtl.git 4d0dc8fb + +.PHONY: release clean-release + +release: clean-release all projects + relx -o rel/$(PROJECT) + +clean-release: clean-projects + rm -rf rel/$(PROJECT) + +include erlang.mk +---- + +You can see here how to define dependencies. First you list all +the dependency names, then you have one line per dependency, giving +the repository URL and the commit number, tag or branch you want. + +Then you can see two targets defined, with `release` +becoming the default target, because it was defined first. You can +override the default target `all`, which builds the +application and its dependencies, this way. + +And as you can see, the `release` target uses +Relx to build a release into the 'rel/ninenines/' +directory. Let's take a look at the configuration file for this release. + +[source,erlang] +---- +{release, {ninenines, "1"}, [ninenines]}. + +{extended_start_script, true}. +{sys_config, "rel/sys.config"}. + +{overlay, [ + {mkdir, "log"}, + {copy, "rel/vm.args", + "releases/\{\{release_name\}\}-\{\{release_version\}\}/vm.args"} +]}. +---- + +The first line defines a release named `ninenines`, which +has a version number `"1"` and includes one application, also +named `ninenines`, although it doesn't have to. + +We then use the `extended_start_script` option to tell +Relx that we would like to have a start script that allows +us to not only start the release, but do so with the node in the +background, or also to allow us to connect to a running node, and so on. +This start script has the same features as the one tools like +Rebar generates. + +The rest of the file just makes sure our configuration files are +where we expect them. Relx will automatically take care +of your 'sys.config' file as long as you tell it where to +find it. The 'vm.args' file used by the extended start script +needs to be handled more explicitly by using an overlay however. + +How does Relx find what applications to include? +By looking at the application dependencies in the '.app' +file of each OTP application. Make sure you put all dependencies in +there, _including_ library applications, and Relx +will find everything for you. + +For example, this release includes the following applications. +Only what's strictly required. + +---- +compiler-4.9.1 crypto-2.3 kernel-2.16.1 ranch-0.8.3 syntax_tools-1.6.11 +cowboy-0.8.5 erlydtl-0.7.0 ninenines-0.2.0 stdlib-1.19.1 +---- + +The 'sys.config' file is standard and +http://www.erlang.org/doc/man/config.html[well documented]. +The 'vm.args' file is just an optionally multiline file +containing all the flags to pass to the Erlang VM, for example +`-name ninenines@127.0.0.1 -heart`. + +Building OTP releases has always been a difficult task. Until now. diff --git a/_build/content/articles/erlanger-playbook-september-2015-update.asciidoc b/_build/content/articles/erlanger-playbook-september-2015-update.asciidoc new file mode 100644 index 00000000..494d1156 --- /dev/null +++ b/_build/content/articles/erlanger-playbook-september-2015-update.asciidoc @@ -0,0 +1,25 @@ ++++ +date = "2015-09-02T00:00:00+01:00" +title = "The Erlanger Playbook September 2015 Update" + ++++ + +An update to The Erlanger Playbook is now available! + +The Erlanger Playbook is a book about software development using +Erlang. It currently covers all areas from the conception, design, +the writing of code, documentation and tests. + +The book is still a work in progress. Future topics will include +refactoring, debugging and tracing, benchmarking, releases, community +management (for open source projects). + +This update fixes a number of things and adds two chapters: IOlists +and Erlang building blocks. + +Learn more about link:/articles/erlanger-playbook[The Erlanger Playbook]! + +This is a self-published ebook. The base price is 50€. All proceeds +will be used to allow me to work on open source full time. + +Thank you for helping me helping you help us all! diff --git a/_build/content/articles/erlanger-playbook.asciidoc b/_build/content/articles/erlanger-playbook.asciidoc new file mode 100644 index 00000000..4a67bf22 --- /dev/null +++ b/_build/content/articles/erlanger-playbook.asciidoc @@ -0,0 +1,69 @@ ++++ +date = "2015-06-18T00:00:00+01:00" +title = "The Erlanger Playbook" + ++++ + +I am proud to announce the pre-release of The Erlanger Playbook. + +The Erlanger Playbook is a book about software development using +Erlang. It currently covers all areas from the conception, design, +the writing of code, documentation and tests. + +The book is still a work in progress. Future topics will include +refactoring, debugging and tracing, benchmarking, releases, community +management (for open source projects). + +The following sections are currently available: + +* About this book; Future additions +* _Workflow:_ Think; Write; Stay productive +* _Documentation:_ On documentation; Tutorials; User guide; Manual +* _Code:_ Starting a project; Version control; Project structure; Code style; Best practices; Special processes +* _Tests:_ On testing; Success typing analysis; Manual testing; Unit testing; Functional testing + +Read a preview: link:/res/erlanger-preview.pdf[Special processes] + +The book is currently just shy of 100 pages. The final version +of the book is planned to be between 200 and 250 pages. +A print version of the book will be considered once the final +version gets released. The printed book is *not* included +in the price. + +This is a self-published book. The base price is 50€. All proceeds +will be used to allow me to work on open source full time. + +++++ +
+ + + + +
+++++ + +You are more than welcome to pay extra by using this second button. +It allows you to set the price you want. Make sure to set it to at least +50€ to receive the book. + +++++ +
+ + + + +
+++++ + +Make sure to provide a valid email address. + +There will be a *delay* between payment and sending of the book. +This process is currently manual. + +As the book is a pre-release, feedback is more than welcome. You can +send your comments to erlanger@ this website. + +The plan is to add about 20 pages every month until it is completed. +You will receive updates to the book for free as soon as they are available. + +Huge thanks for your interest in buying this book! diff --git a/_build/content/articles/farwest-funded.asciidoc b/_build/content/articles/farwest-funded.asciidoc new file mode 100644 index 00000000..99ea3525 --- /dev/null +++ b/_build/content/articles/farwest-funded.asciidoc @@ -0,0 +1,37 @@ ++++ +date = "2013-06-27T00:00:00+01:00" +title = "Farwest got funded!" + ++++ + +This was a triumph! I'm making a note here: HUGE SUCCESS!! + +++++ + +++++ + +It's hard to overstate my satisfaction. Thanks to everyone who +made this possible. + +If you have backed this fundraiser, and haven't provided your +personal details yet, please do so quickly so that your rewards +can be sent! + +I am hoping that we will be able to make good use of all that +money. The details of the expenses will be published regularly +on the https://github.com/extend/farwest/wiki/2013-Fundraiser[2013 Fundraiser wiki page], +giving you full disclosure as to how your money is used. + +It will take a little time to get things started, we are in +summer after all! We will however act quickly to make the +prototype easy enough to use so that the paid UI work can +begin. This is also when user contributions will be welcome. + +You can see the https://github.com/extend/farwest/wiki/Roadmap[Roadmap] +to get more information on the current plans. This document will +get updated as time goes on so check again later to see if you +can help! + +Look at me: still talking when there's open source to do! + +Thanks again for all your support. I really appreciate it. diff --git a/_build/content/articles/january-2014-status.asciidoc b/_build/content/articles/january-2014-status.asciidoc new file mode 100644 index 00000000..58ce17b3 --- /dev/null +++ b/_build/content/articles/january-2014-status.asciidoc @@ -0,0 +1,159 @@ ++++ +date = "2014-01-07T00:00:00+01:00" +title = "January 2014 status" + ++++ + +I will now be regularly writing posts about project status, plans +and hopes for the future. + +Before that though, there's one important news to share. + +Until a year ago all development was financed through consulting +and development services. This worked alright but too much time was +spent doing things that didn't benefit the open source projects. +And that didn't make me happy at all. Because I like being happy +I stopped that for the most part and spent the year figuring things +out, experimenting and discussing with people about it. + +What makes me happy is answering these "what if" questions. +Ranch and Cowboy are a direct product of that, as they originate +from the "what if we could have a server running different protocols +on different ports but all part of the same application?"; Erlang.mk +is a bit different: "this works great for me, what if it could +become the standard solution for building Erlang applications?". + +When I successfully answer the question, this becomes a project +that may end up largely benefiting the Erlang community. I love +Erlang and I love enabling people to build awesome products based +on my projects. It's a lot more rewarding than activities like +consulting where you only help one company at a time. And it's +also a much better use of my time as this has a bigger impact on +the community. + +The hard part is to figure out how to be able to spend 100% +of the time on projects that you basically give away for free, +and still be able to afford living. + +The immediate solution was getting work sponsored by the +http://www.leofs.org/[LeoFS project]. LeoFS is a great +distributed file storage that I can only recommend to anyone who +needs to store files or large pieces of data. The sponsorship +works pretty great, and spurred development of the SPDY code in +Cowboy amongst other things, plus a couple upcoming projects +done more recently and getting a final touch before release. + +It turns out sponsoring works great. So I'm thinking of +expanding on it and hopefully get enough sponsoring for fulltime +open source development. So I figured out a few things that +can give incentive to companies willing to sponsor. + +Sponsors can _request that a particular version of Cowboy +be maintained indefinitely_ (as long as they're sponsoring). +This means fixes will be backported. This doesn't include +features although I can take requests depending on feasability. + +Sponsors can _have a direct, private line of communication_, +useful when they need help debugging or optimizing their product. + +Sponsors can _get their name associated with one of the +project_ and get a good standing in the community thanks +to this. They would be featured in the README of the project +which is viewed by hundreds of developers daily. + +Sponsors can _be listed on this website_. I will modify +the front page when we get a few more sponsors, they will be +featured below the carousel of projects. + +Please mailto:contact@ninenines.eu[contact us] if +you are interested in sponsoring, and say how much you are willing +to sponsor. The goal here is only to have enough money to make a +living and attend a few conferences. There's an upper limit in the +amount needed per year, so the more sponsors there are the cheaper +it becomes to everyone. + +The upper limit stems from the new legal entity that will replace +the current Nine Nines. This is mostly to lower the legal costs and +simplify the administrative stuff and allow me to dedicate all my +time on what's important. From your point of view it's business as +usual. + +Now on to project statuses and future works. + +== Cowboy + +Cowboy is getting ready for a 1.0 release. Once multipart support +is in, all that's left is finishing the guide, improving tests and +finishing moving code to the cowlib project. I hope everything will +be ready around the time R17B is released. + +I already dream of some API breaking changes after 1.0, which +would essentially become 2.0 when they're done. An extensive survey +will be setup after the 1.0 release to get more information on what +people like and don't like about the API. + +And of course, when clients start implementing HTTP/2.0 then we +will too. + +== Ranch + +Ranch is also getting close to 1.0. I am currently writing a +test suite for upgrades. After that I also would like to write +a chaos_monkey test suite and add a getting started chapter to the +guide. + +Ranch is pretty solid otherwise, it's hard to foresee new +features at this point. + +== Erlang.mk + +I didn't expect this project to become popular. Glad it did though. + +Windows support is planned, but will require GNU Make 4. +Thankfully, it's available at least through cygwin. Make, +Git and Erlang will be the only required dependencies +because the rest of the external calls will be converted to +using Guile, a Scheme included since GNU Make 4. So it is +Guile that will download the needed files, magically fill +the list of modules in the '.app' file and so on, allowing +us to provide a truly cross-platform solution without +losing on the performance we benefit from using Make. + +Also note that it is possible to check whether Guile +is available so we will be able to fallback to the current +code for older systems. + +I am also thinking about adding an extra column to the package +index, indicating the preferred tag or commit number to be used. +This would allow us to skip the individual `dep` lines +entirely if the information in the package index is good enough. +And committing that file to your project would be the only thing +needed to lock the dependencies. Of course if a `dep` +line is specified this would instead override the file. + +== Alien Shaman + +This is the two-parts project requested by the LeoFS team. +This is essentially a "distributed bigwig". I am hoping to +have a prototype up in a few days. + +Alien is the part that allows writing and enabling probes +in your nodes. Probes send events which may get filtered before +being forwarded to their destination. The events may be sent +to a local process, a remote process, over UDP, TCP or SSL. +Events may also be received by a process called a relay, which +may be used to group or aggregate data before it is being sent +over the network, reducing the footprint overall. + +Shaman is the UI for it. It will ultimately be able to display +any event as long as it's configured to do so. Events may be logs, +numeric values displayed on graphs updated in real time, lists of +items like processes and so on. + +== Feedback + +That's it for today! There will be another status update once +Shaman is out. But for now I have to focus on it. + +As always, please send feedback on the projects, this post, +the sponsoring idea, anything really! Thanks. diff --git a/_build/content/articles/on-open-source.asciidoc b/_build/content/articles/on-open-source.asciidoc new file mode 100644 index 00000000..6e700e8a --- /dev/null +++ b/_build/content/articles/on-open-source.asciidoc @@ -0,0 +1,137 @@ ++++ +date = "2014-09-05T00:00:00+01:00" +title = "On open source" + ++++ + +Last week I read a great article +http://videlalvaro.github.io/2014/08/on-contributing-to-opensource.html[on +contributing to open source] by Alvaro Videla. He makes +many great points and I am in agreement with most of it. +This made me want to properly explain my point of view with +regard to open source and contributions. Unlike most open +source evangelism articles I will not talk about ideals or +any of that crap, but rather my personal feelings and +experience. + +I have been doing open source work for quite some time. +My very first open source project was a graphics driver +for (the very early version of) the PCSX2 emulator. That +was more than ten years ago, and there +http://ngemu.com/threads/gstaris-0-6.30469/[isn't +much left to look at today]. This was followed by a +https://github.com/extend/wee[PHP framework] +(started long before Zend Framework was even a thing) and +a few other small projects. None of them really took off. +It's alright, that's pretty much the fate of most open +source projects. You spend a lot of work and sweat and +get very little in return from others. + +This sounds harsh but this is the reality of all open +source projects. If you are thinking of building a project +and releasing it as open source, you should be prepared +for that. This is how most of your projects will feel like. +Don't release a project as open source thinking everyone +will pat you on the back and cheer, this won't happen. In +fact if your project is a too small improvement over existing +software, what many people will do is say you have NIH +syndrome, regardless of the improvement you bring. So you +need not to rely on other people in order to get your +enjoyment out of building open source software. + +In my case I get enjoyment from thinking about problems +that need solving. Often times the problems are already +solved, but nevermind that, I still think about them and +sometimes come up with something I feel is better and then +write code for it. Writing code is also fun, but not as +fun as using my brain to imagine solutions. + +You don't need thousands of users to do that. So are +users worthless to me then? No, of course not. In fact +they are an important component: they bring me problems +that need solving. So users are very important to me. +But that's not the only reason. + +I got lucky that the Cowboy project became popular. +And seeing it be this popular, and some of my other projects +also do quite well, made me believe I could perhaps work +full time on open source. If I can work full time then +I can produce better software. What I had one hour to +work on before I can now spend a day on, and experiment +until I am satisfied. This is very useful because that +means I can get it almost right from the beginning, and +avoid the million API breaking changes that occured +before Cowboy 1.0 was released. + +To be able to work full time on open source however, +I need money. This is a largely unspoken topic of open +source work. The work is never free. You can download the +product for free, but someone has to pay for the work +itself. Life is unfortunately not free. + +Large projects and some lucky people have their work +sponsored by their employers. Everyone else has to deal +with it differently. In my case I was sponsored for a +while by the http://leo-project.net/leofs/[LeoFS] +project, but that ended. I also had the Farwest fundraiser, +which was a success, although the project stalled after that. +(Fear not, as Farwest will make a comeback as a conglomerate +of Web development projects in the future.) After that I set +up the http://ninenines.eu/support/[sponsoring scheme], +which I can proudly say today brings in enough money to +cover my food and shelter. Great! + +This is a start, but it's of course not enough. Life +is a little more than food and shelter, and so I am still +looking for sponsors. This is not a very glorious experience, +as I am essentially looking for scraps that companies can +throw away. Still, if a handful more companies were doing +that, not only would I be able to live comfortably, but I +would also be able to stop worrying about the future as I +could put money on the side for when it gets rough. + +A few companies giving me some scrap money so I could +live and work independently is by far the most important +thing anyone can do to help my projects, including Cowboy. +Yes, they're even more important than code contributions, +bug reports and feedback. Because this money gives me the +time I need to handle the code contributions, bug reports +and feedback. + +If Cowboy or another project is a large part of your +product or infrastructure, then the best thing you can do +is become a sponsor. The second best is opening tickets +and/or providing feedback. The third best is providing +good code contributions. + +I will not expand on the feedback part. Feedback is +very important, and even just a high five or a retweet +is already good feedback. It's not very complicated. + +I want to expand a little on code contributions +however. Not long ago I ran across the term "patch bomb" +which means dropping patches and expecting the project +maintainers to merge them and maintain them. I receive +a lot of patches, and often have to refuse them. Causes +for refusal vary. Some patches only benefit the people +who submitted them (or a very small number of people). +Some patches are not refined enough to be included. +Others are out of scope of the project. These are some +of the reasons why I refuse patches. Having limited +time and resources, I have to focus my efforts on the +code used by the larger number of users. I have to +prioritize patches from submitters who are reactive +and address the issues pointed out. And I have to plainly +refuse other patches. + +I believe this wraps up my thoughts on open source. +Overall I had a great experience, the Erlang community +being nice and understanding of the issues at hand in +general. And if the money problem could be solved soon, +then I would be one of the luckiest and happiest open +source developer on Earth. + +Think about it the next time you see a donation button +or a request for funds or sponsoring. You can considerably +improve an open source developer's life with very little +of your company's money. diff --git a/_build/content/articles/ranch-ftp.asciidoc b/_build/content/articles/ranch-ftp.asciidoc new file mode 100644 index 00000000..19209ccc --- /dev/null +++ b/_build/content/articles/ranch-ftp.asciidoc @@ -0,0 +1,220 @@ ++++ +date = "2012-11-14T00:00:00+01:00" +title = "Build an FTP Server with Ranch in 30 Minutes" + ++++ + +Last week I was speaking at the +http://www.erlang-factory.com/conference/London2012/speakers/LoicHoguin[London Erlang Factory Lite] +where I presented a live demonstration of building an FTP server using +http://ninenines.eu/docs/en/ranch/HEAD/README[Ranch]. +As there was no slide, you should use this article as a reference instead. + +The goal of this article is to showcase how to use Ranch for writing +a network protocol implementation, how Ranch gets out of the way to let +you write the code that matters, and the common techniques used when +writing servers. + +Let's start by creating an empty project. Create a new directory and +then open a terminal into that directory. The first step is to add Ranch +as a dependency. Create the `rebar.config` file and add the +following 3 lines. + +[source,erlang] +---- +{deps, [ + {ranch, ".*", {git, "git://github.com/extend/ranch.git", "master"}} +]}. +---- + +This makes your application depend on the last Ranch version available +on the _master_ branch. This is fine for development, however when +you start pushing your application to production you will want to revisit +this file to hardcode the exact version you are using, to make sure you +run the same version of dependencies in production. + +You can now fetch the dependencies. + +[source,bash] +---- +$ rebar get-deps +==> ranch_ftp (get-deps) +Pulling ranch from {git,"git://github.com/extend/ranch.git","master"} +Cloning into 'ranch'... +==> ranch (get-deps) +---- + +This will create a 'deps/' folder containing Ranch. + +We don't actually need anything else to write the protocol code. +We could make an application for it, but this isn't the purpose of this +article so let's just move on to writing the protocol itself. Create +the file 'ranch_ftp_protocol.erl' and open it in your favorite +editor. + +[source,bash] +$ vim ranch_ftp_protocol.erl + +Let's start with a blank protocol module. + +[source,erlang] +---- +-module(ranch_ftp_protocol). +-export([start_link/4, init/3]). + +start_link(ListenerPid, Socket, Transport, Opts) -> + Pid = spawn_link(?MODULE, init, [ListenerPid, Socket, Transport]), + {ok, Pid}. + +init(ListenerPid, Socket, Transport) -> + io:format("Got a connection!~n"), + ok. +---- + +When Ranch receives a connection, it will call the start_link/4 +function with the listener's pid, socket, transport module to be used, +and the options we define when starting the listener. We don't need options +for the purpose of this article, so we don't pass them to the process we are +creating. + +Let's open a shell and start a Ranch listener to begin accepting +connections. We only need to call one function. You should probably open +it in another terminal and keep it open for convenience. If you quit +the shell you will have to repeat the commands to proceed. + +Also note that you need to type `c(ranch_ftp_protocol).` +to recompile and reload the code for the protocol. You do not need to +restart any process however. + +[source,bash] +---- +$ erl -pa ebin deps/*/ebin +Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] + +Eshell V5.9.2 (abort with ^G) +---- + +[source,erlang] +---- +1> application:start(ranch). +ok +2> ranch:start_listener(my_ftp, 10, + ranch_tcp, [{port, 2121}], + ranch_ftp_protocol, []). +{ok,<0.40.0>} +---- + +This starts a listener named `my_ftp` that runs your very own +`ranch_ftp_protocol` over TCP, listening on port `2121`. +The last argument is the options given to the protocol that we ignored +earlier. + +To try your code, you can use the following command. It should be able +to connect, the server will print a message in the console, and then +the client will print an error. + +[source,bash] +$ ftp localhost 2121 + +Let's move on to actually writing the protocol. + +Once you have created the new process and returned the pid, Ranch will +give ownership of the socket to you. This requires a synchronization +step though. + +[source,erlang] +---- +init(ListenerPid, Socket, Transport) -> + ok = ranch:accept_ack(ListenerPid), + ok. +---- + +Now that you acknowledged the new connection, you can use it safely. + +When an FTP server accepts a connection, it starts by sending a +welcome message which can be one or more lines starting with the +code `200`. Then the server will wait for the client +to authenticate the user, and if the authentication went successfully, +which it will always do for the purpose of this article, it will reply +with a `230` code. + +[source,erlang] +---- +init(ListenerPid, Socket, Transport) -> + ok = ranch:accept_ack(ListenerPid), + Transport:send(Socket, <<"200 My cool FTP server welcomes you!\r\n">>), + {ok, Data} = Transport:recv(Socket, 0, 30000), + auth(Socket, Transport, Data). + +auth(Socket, Transport, <<"USER ", Rest/bits>>) -> + io:format("User authenticated! ~p~n", [Rest]), + Transport:send(Socket, <<"230 Auth OK\r\n">>), + ok. +---- + +As you can see we don't need complex parsing code. We can simply +match on the binary in the argument! + +Next we need to loop receiving data commands and optionally +execute them, if we want our server to become useful. + +We will replace the ok. line with the call to +the following function. The new function is recursive, each call +receiving data from the socket and sending a response. For now +we will send an error response for all commands the client sends. + +[source,erlang] +---- +loop(Socket, Transport) -> + case Transport:recv(Socket, 0, 30000) of + {ok, Data} -> + handle(Socket, Transport, Data), + loop(Socket, Transport); + {error, _} -> + io:format("The client disconnected~n") + end. + +handle(Socket, Transport, Data) -> + io:format("Command received ~p~n", [Data]), + Transport:send(Socket, <<"500 Bad command\r\n">>). +---- + +With this we are almost ready to start implementing commands. +But with code like this we might have errors if the client doesn't +send just one command per packet, or if the packets arrive too fast, +or if a command is split over multiple packets. + +To solve this, we need to use a buffer. Each time we receive data, +we will append to the buffer, and then check if we have received a +command fully before running it. The code could look similar to the +following. + +[source,erlang] +---- +loop(Socket, Transport, Buffer) -> + case Transport:recv(Socket, 0, 30000) of + {ok, Data} -> + Buffer2 = << Buffer/binary, Data/binary >>, + {Commands, Rest} = split(Buffer2), + [handle(Socket, Transport, C) || C <- Commands], + loop(Socket, Transport); + {error, _} -> + io:format("The client disconnected~n") + end. +---- + +The implementation of `split/1` is left as an exercice +to the reader. You will also probably want to handle the `QUIT` +command, which must stop any processing and close the connection. + +The attentive reader will also take note that in the case of text- +based protocols where commands are separated by line breaks, you can +set an option using `Transport:setopts/2` and have all the +buffering done for you for free by Erlang itself. + +As you can surely notice by now, Ranch allows us to build network +applications by getting out of our way entirely past the initial setup. +It lets you use the power of binary pattern matching to write text and +binary protocol implementations in just a few lines of code. + +* http://www.erlang-factory.com/conference/London2012/speakers/LoicHoguin[Watch the talk] diff --git a/_build/content/articles/the-story-so-far.asciidoc b/_build/content/articles/the-story-so-far.asciidoc new file mode 100644 index 00000000..54bf7af9 --- /dev/null +++ b/_build/content/articles/the-story-so-far.asciidoc @@ -0,0 +1,250 @@ ++++ +date = "2014-08-23T00:00:00+01:00" +title = "The story so far" + ++++ + +As I am away from home with little to do (some call this +a vacation) I wanted to reflect a little on the story so far, +or how I arrived to Erlang and got to where I am now. The +raw personal experience. It'll be an article that's more +about social aspect, communities and marketing a project than +technical considerations. As a period piece, it will also +allow me to reflect on the evolution of Erlang in recent +years. + +Once upon a time-- Okay this isn't a fairy tale. The story +begins with a short chapter in 2010. The year 2010 started +with a fairly major event in my life: the US servers for the +online game I stopped playing a few months before, but was +still involved with through its community, were closing. OMG! +Someone found a way to log packets and started working on a +private server; meanwhile the JP servers were still up. And +that's pretty much it. + +Fast forward a few months and it became pretty clear that +the private server was going nowhere considering all the drama +surrounding it-- which is actually not unusual, but it was +more entertaining than average and the technical abilities of +people running the project were obviously lacking so I decided +to obtain those logged packets and look at things myself. I +didn't want to do a private server yet, I only wanted to take +a peek to see how things worked, and perhaps organize some +effort to document the protocol. + +There was 10GB of logs. I didn't have an easy to use +language to analyze them, and hex editors wouldn't cut it for +most purposes, so I had to look elsewhere. This was a good +opportunity to start learning this PHP killer I read about +before, which also happens to feature syntax for matching +binaries, called Erlang. To be perfectly honest I wouldn't +have touched the logs if I didn't have the added motivation +to play with and learn a new language. + +At the time it was pretty hard to learn Erlang. In my +experience there was Joe's book (which I always recommend +first as I believe it is the best to learn the Erlang side +of things; but falls a little short on OTP), and there was +about 5 chapters of LYSE. There were a couple other books +I never managed to get into (sorry guys), and there was also +a few interesting blogs, some of which I can't find anymore. +Finally the #erlang IRC community was there but I was strictly +lurking at the time. + +What a difference compared to 4 years later! (That's +today, by the way!) Now we have more books than I can +remember, tons of articles covering various aspects of the +language and platform, many targeting beginners but a good +number of them also about advanced topics. We even have a +free online book, LYSE, with more than 30 chapters covering +pretty much everything. Needless to say I never finished +reading LYSE as it got written slower than I learnt. + +Back to 2010. I wrote a parser for the logs, and +aggregated those results into one CSV file per packet type +so I could open them in Gnumeric and aggregate some more, +but manually this time, and draw conclusions on the packet +structures. That was pretty easy. Even for a beginner. +Anyone can go from zero to that level in a day or two. +Then, having mastered binary pattern matching, I wanted +to learn some more Erlang, by making this aggregation +faster. What I had done before worked, but I wasn't going +to wait forever to process everything sequentially. So I +looked and found a project called `plists` (still exists, +but not maintained AFAIK). I downloaded that project and +replaced my `lists:` calls to `plists:`. +Boom. In just a few minutes all logs were processed, and +I had learnt something new. + +It is particularly interesting to note that the lack of +a package manager or index never bothered me. Neither before +nor after learning Erlang. My experience with package +managers was mostly related to Ubuntu, a little Perl and +Python, and PHP's Pear. Let's just stay polite and say it +was always a terrible experience. So searching on the Web +didn't feel awkward, because even if I used a tool or +website I would have ended up doing a search or two anyway. +This is in contrast to the package index feature in +https://github.com/ninenines/erlang.mk[Erlang.mk], +which is meant to simplify specifying dependencies more +than anything: `DEPS = cowboy`. It does not +attempt to solve any other problem, and will only attempt +to solve one extra problem in the near future, which is +the discovery of packages. So expect some kind of website +listing packages soon enough. + +I want to use this parenthese to also point out that at +the time there was a very small number of projects out there, +at least compared to today. While you sometimes hear people +complain about lack of certain libraries, it is so much +better now than it was before! The situation improves very +quickly, so much that it's not going to be that big an issue +soon enough. + +Wanting to know more about that game's protocol, in the +year 2010, I ended up starting to write more Erlang code to +simulate a server and use the server to query the client and +see what was happening, documenting the packets and so on. +This eventually lead to a larger project implementing more +and more until people got their hopes up for a revival of +the game, all the while the now competing original server +project died in a stream of drama and technical incompetence. +Of course, I ended up doing what any good Internet citizen +would do, I crushed people's hopes, but that's not important +to our story. The important part is that before giving up +on this project, I not only learnt a good deal of Erlang +and a little deal of OTP (which I did not touch until 6 +months after I started with Erlang; see the paragraph +about learning material above), but I also had an intriguing +idea pop into my mind for what would become my greatest +success yet. + +The giving up part was not easy. Having had financial +difficulties all year 2010 and part of 2009, I resolved +to travel back to Paris to try and make it. I ended up +sleeping in offices for 6 months, being hosted by a shady +person, and hearing my fair share of stories about +the dark side of business. While there I also worked for +another company with someone who would end up becoming +another high profile Erlang developer. The situation +slowly improved, I started taking part in the #erlang +IRC discussions, giving up my status of lurker and, a +few months into 2011, started working on the Apache killer +project: Cowboy. + +This is the part where I probably should get accused of +racism and other fun things, but I never did. And I think +that speaks lots about the Erlang community. In all my time +writing Erlang code, I can count the number of conflicts I +had with other people on a single hand. This is the nicest +programming community I have ever seen, by far. And the +humblest too. The Erlang community feels like Japan. And +I love Japan. So I love the Erlang community. I can't say +this enough. This is something that stayed true for all +my time using Erlang, and despite the rise of alternative +languages that are not Japan the Erlang community has +remained very Japan. + +The first published version of Cowboy was written in +two weeks. A little before those two weeks, during, and +a while after, pretty much everything I said on the +Internets was that Cowboy was going to be the greatest +HTTP server ever, that the other servers were problematic +(and just to be clear, Yaws was rarely if ever mentioned, +due to being in a perceived different league of "full +featured servers" while Cowboy was a "lightweight server"), +and that Cowboy will be the best replacement to a Mochiweb +or Misultin application. This, alongside a lot of time +spent on IRC telling people to use Cowboy when they were +asking for an HTTP server to use, probably made me sound +very annoying. But it worked, and Cowboy started getting +its first users, despite being only a few weeks old. Of +course, as soon as I got my very first user, I started +claiming Cowboy had "a lot of users". + +Looking back today I would definitely find myself annoying, +this wasn't just an idle comment there. For about a year, +maybe a little more, all I ever said was that Cowboy was +the best. This probably made me a little dumber in the +process (as if I wasn't enough! I know). Being French, I +sometimes would also say things quite abruptly. To stay +polite, I probably sounded like an asshole. I learnt to +stop being so French over time thankfully. + +I think what was most important to Cowboy at the time, +was three things. First, it felt fresh. It was new, had new +ideas, tried to do things differently and followed "new" old +best practices (the OTP way-- which was simply too obscure +for most people at the time). Second, it had me spending +all my time telling people to use it whenever they were +looking for an HTTP server. Third, it had me helping people +get started with it and guide them all the steps of the way. +Mostly because it didn't have a very good documentation, but +still, hand holding does wonders. + +To be able to help people every time they had a problem, +I did not spend all my days reading IRC. Instead I simply +made sure to be notified when someone said `cowboy`. +The same way many people subscribe to alerts when their +company is mentioned in the news. Nothing fancy. + +Time went on, Cowboy grew, or as some like to say, +completely destroyed the competition, and many people +eventually moved from Mochiweb and Misultin to Cowboy. +And then Roberto Ostinelli stopped Misultin development +and told everyone to move to Cowboy. This is the most +humble and selfless act I have ever seen in the programming +sphere, and I only have one thing to say about it: GG. +Thanks for the fish. He left me with the tasks of improving +Cowboy examples, documentation and strongly believed that +the Misultin interface was more user friendly out of all +the servers. So I added many examples, as many lines of +documentation as we have of code, and strongly believe +that Cowboy 2.0 will be the most user friendly interface +out of all servers. But only time will tell. + +With the rise of the project and the rise in the number +of users, my previous strategy (completely incidental, by +the way, and definitely not a well thought out plan to +become popular) stopped working. It was taking me too much +time. The important aspects slowly drifted. If I wanted to +support more users, I would have to spend less time with +each individual user. This was actually a hard problem. +You basically have to make people understand they can't +just come to you directly when they have a problem, they +have to follow proper channels. It becomes less personal, +and might be felt like you don't care about them anymore. +You have to hurt some people's feelings at this point. It +is quite unfortunate, and also quite difficult to do. There +is some unwritten rule that says early adopters deserve +more, but in the real world it never works like this. So +I probably hurt some people's feelings at some point. But +that's okay. Because even if you make sure to be as nice +as possible when you tell people to go through proper +channels from now on, some people will still get offended. +There's nothing you can do about it. + +From that point onward the important points about the +project was getting the documentation done, making sure +people knew about the proper channels to get help and +report issues, etc. Basically making myself less needed. +This is quite a contrast with the first days, but I believe +Cowboy made that transition successfully. + +Not only did I win time by not having to hold hands with +everyone all the time (not that I didn't like it, but you +know, the sweat), but I also won time thanks to the increased +project popularity. Indeed, the more users you have, the more +annoying guys there are to tell people to use your project +and that it's the best and everything. Which is great. At +least, it's great if you don't pay too much attention to it. +Sometimes people will give an advice that is, in your opinion, +a bad advice. And that's okay. Don't intervene every time +someone gives a bad advice, learn to let it go. People will +figure it out. You learn by making mistakes, after all. Use +this extra time to make sure other people don't end up +giving the same bad advice instead. Fix the code or the +documentation that led to this mistake. Slowly improve the +project and make sure it doesn't happen again. + +This is my story. So far, anyway. diff --git a/_build/content/articles/tictactoe.asciidoc b/_build/content/articles/tictactoe.asciidoc new file mode 100644 index 00000000..8aec1c57 --- /dev/null +++ b/_build/content/articles/tictactoe.asciidoc @@ -0,0 +1,91 @@ ++++ +date = "2012-10-17T00:00:00+01:00" +title = "Erlang Tic Tac Toe" + ++++ + +Everyone knows http://en.wikipedia.org/wiki/Tic-tac-toe[Tic Tac Toe], +right? + +Players choose either to be the Xs or the Os, then place their symbol +on a 3x3 board one after another, trying to create a line of 3 of them. + +Writing an algorithm to check for victory sounds easy, right? It's +easily tested, considering there's only 8 possible winning rows (3 horizontal, +3 vertical and 2 diagonal). + +In Erlang though, you probably wouldn't want an algorithm. Erlang has +this cool feature called pattern matching which will allow us to completely +avoid writing the algorithm by instead letting us match directly on the +solutions. + +Let's first create a board. A board is a list of 3 rows each containing +3 columns. It can also be thought of as a tuple containing 9 elements. +A tuple is easier to manipulate so this is what we are going to use. +Each position can either contain an `x`, an `o`, +or be `undefined`. + +[source,erlang] +---- +new() -> + {undefined, undefined, undefined, + undefined, undefined, undefined, + undefined, undefined, undefined}. +---- + +Now that we have a board, if we want to play, we need a function that +will allow players to, you know, actually play their moves. Rows and +columns are numbered 1 to 3 so we need a little math to correctly +deduce the element's position. + +[source,erlang] +---- +play(Who, X, Y, Board) -> + setelement((Y - 1) * 3 + X, Board, Who). +---- + +This function returns the board with the element modified. Of course, +as you probably noticed, we aren't checking that the arguments are correct, +or that the element was already set. This is left as an exercise to the +reader. + +After playing the move, we need to check whether someone won. That's +where you'd write an algorithm, and that's where I wouldn't. Let's just +pattern match all of them! + +[source,erlang] +---- +check(Board) -> + case Board of + {x, x, x, + _, _, _, + _, _, _} -> {victory, x}; + + {x, _, _, + _, x, _, + _, _, x} -> {victory, x}; + + {x, _, _, + x, _, _, + x, _, _} -> {victory, x}; + + %% [snip] + + _ -> ok + end. +---- + +Pattern matching allows us to simply _draw_ the solutions +directly inside our code, and if the board matches any of them, then we +have a victory or a draw, otherwise the game can continue. + +The `_` variable is special in that it always matches, +allowing us to focus strictly on the winning row. And because it's very +graphical, if we were to have messed up somewhere, then we'd only need +take a quick glance to be sure the winning solutions are the right ones. + +Erlang allows us to transform algorithms into very graphical code thanks +to its pattern matching feature, and let us focus on doing things instead +of writing algorithms to do things. + +* link:/res/tictactoe.erl[tictactoe.erl] diff --git a/_build/content/articles/xerl-0.1-empty-modules.asciidoc b/_build/content/articles/xerl-0.1-empty-modules.asciidoc new file mode 100644 index 00000000..b2c178b2 --- /dev/null +++ b/_build/content/articles/xerl-0.1-empty-modules.asciidoc @@ -0,0 +1,153 @@ ++++ +date = "2013-01-30T00:00:00+01:00" +title = "Xerl: empty modules" + ++++ + +Let's build a programming language. I call it Xerl: eXtended ERLang. +It'll be an occasion for us to learn a few things, especially me. + +Unlike in Erlang, in this language, everything is an expression. +This means that modules and functions are expression, and indeed that +you can have more than one module per file. + +We are just starting, so let's no go ahead of ourselves here. We'll +begin with writing the code allowing us to compile an empty module. + +We will compile to Core Erlang: this is one of the many intermediate +step your Erlang code compiles to before it becomes BEAM machine code. +Core Erlang is a very neat language for machine generated code, and we +will learn many things about it. + +Today we will only focus on compiling the following code: + +[source,erlang] +mod my_module +begin +end + +Compilation will be done in a few steps. First, the source file will +be transformed in a tree of tokens by the lexer. Then, the parser will +use that tree of tokens and convert it to the AST, bringing semantical +meaning to our representation. Finally, the code generator will transform +this AST to Core Erlang AST, which will then be compiled. + +We will use _leex_ for the lexer. This lexer uses .xrl files +which are then compiled to .erl files that you can then compile to BEAM. +The file is divided in three parts: definitions, rules and Erlang code. +Definitions and Erlang code are obvious; rules are what concerns us. + +We only need two things: atoms and whitespaces. Atoms are a lowercase +letter followed by any letter, number, _ or @. Whitespace is either a +space, an horizontal tab, \r or \n. There exists other kinds of whitespaces +but we simply do not allow them in the Xerl language. + +Rules consist of a regular expression followed by Erlang code. The +latter must return a token representation or the atom `skip_token`. + +[source,erlang] +---- +{L}{A}* : + Atom = list_to_atom(TokenChars), + {token, case reserved_word(Atom) of + true -> {Atom, TokenLine}; + false -> {atom, TokenLine, Atom} + end}. + +{WS}+ : skip_token. +---- + +The first rule matches an atom, which is converted to either a special +representation for reserved words, or an atom tuple. The +`TokenChars` variable represents the match as a string, and +the `TokenLine` variable contains the line number. +https://github.com/extend/xerl/blob/0.1/src/xerl_lexer.xrl[View the complete file]. + +We obtain the following result from the lexer: + +[source,erlang] +---- +[{mod,1},{atom,1,my_module},{'begin',2},{'end',3}] +---- + +The second step is to parse this list of tokens to add semantic meaning +and generate what is called an _abstract syntax tree_. We will be +using the _yecc_ parser generator for this. This time it will take +.yrl files but the process is the same as before. The file is a little +more complex than for the lexer, we need to define at the very least +terminals, nonterminals and root symbols, the grammar itself, and +optionally some Erlang code. + +To compile our module, we need a few things. First, everything is an +expression. We thus need list of expressions and individual expressions. +We will support a single expression for now, the `mod` +expression which defines a module. And that's it! We end up with the +following grammar: + +[source,erlang] +---- +exprs -> expr : ['$1']. +exprs -> expr exprs : ['$1' | '$2']. + +expr -> module : '$1'. + +module -> 'mod' atom 'begin' 'end' : + {'mod', ?line('$1'), '$2', []}. +---- + +https://github.com/extend/xerl/blob/0.1/src/xerl_parser.yrl[View the complete file]. + +We obtain the following result from the parser: + +[source,erlang] +---- +[{mod,1,{atom,1,my_module},[]}] +---- + +We obtain a list of a single `mod` expression. Just like +we wanted. Last step is generating the Core Erlang code from it. + +Code generation generally is comprised of several steps. We will +discuss these in more details later on. For now, we will focus on the +minimal needed for successful compilation. + +We can use the `cerl` module to generate Core Erlang AST. +We will simply be using functions, which allows us to avoid learning +and keeping up to date with the internal representation. + +There's one important thing to do when generating Core Erlang AST +for a module: create the `module_info/{0,1}` functions. +Indeed, these are added to Erlang before it becomes Core Erlang, and +so we need to replicate this ourselves. Do not be concerned however, +as this only takes a few lines of extra code. + +As you can see by +https://github.com/extend/xerl/blob/0.1/src/xerl_codegen.erl[looking at the complete file], +the code generator echoes the grammar we defined in the parser, and +simply applies the appropriate Core Erlang functions for each expressions. + +We obtain the following pretty-printed Core Erlang generated code: + +[source,erlang] +---- +module 'my_module' ['module_info'/0, + 'module_info'/1] + attributes [] +'module_info'/0 = + fun () -> + call 'erlang':'get_module_info' + ('empty_module') +'module_info'/1 = + fun (Key) -> + call 'erlang':'get_module_info' + ('empty_module', Key) +end +---- + +For convenience I added all the steps in a `xerl:compile/1` +function that you can use against your own .xerl files. + +That's it for today! We will go into more details over each steps in +the next few articles. + +* https://github.com/extend/xerl/blob/0.1/[View the source] diff --git a/_build/content/articles/xerl-0.2-two-modules.asciidoc b/_build/content/articles/xerl-0.2-two-modules.asciidoc new file mode 100644 index 00000000..4da5322e --- /dev/null +++ b/_build/content/articles/xerl-0.2-two-modules.asciidoc @@ -0,0 +1,152 @@ ++++ +date = "2013-02-03T00:00:00+01:00" +title = "Xerl: two modules" + ++++ + +Everything is an expression. + +This sentence carries profound meaning. We will invoke it many +times over the course of these articles. + +If everything is an expression, then the language shouldn't have +any problem with me defining two modules in the same source file. + +[source,erlang] +---- +mod first_module +begin +end + +mod second_module +begin +end +---- + +Likewise, it shouldn't have any problem with me defining a +module inside another module. + +[source,erlang] +---- +mod out_module +begin + mod in_module + begin + end +end +---- + +Of course, in the context of the Erlang VM, these two snippets +are equivalent; there is nothing preventing you from calling the +`in_module` module from any other module. The `mod` +instruction means a module should be created in the Erlang VM, +with no concept of scope attached. + +Still we need to handle both. To do this we will add a step +between the parser and the code generator that will walk over the +abstract syntax tree, from here onward shortened as _AST_, +and transform the AST by executing it where applicable. + +What happens when you execute a `mod` instruction? +A module is created. Since we are compiling, that simply means +the compiler will branch out and create a module. + +If everything is an expression, does that mean this will allow +me to create modules at runtime using the same syntax? Yes, but +let's not get ahead of ourselves yet. + +For now we will just iterate over the AST, and will compile +a module for each `mod` found. Modules cannot contain +expressions yet, so there's no need to recurse over it at this +point. This should solve the compilation of our first snippet. + +The `compile/1` function becomes: + +[source,erlang] +---- +compile(Filename) -> + io:format("Compiling ~s...~n", [Filename]), + {ok, Src} = file:read_file(Filename), + {ok, Tokens, _} = xerl_lexer:string(binary_to_list(Src)), + {ok, Exprs} = xerl_parser:parse(Tokens), + execute(Filename, Exprs, []). + +execute(_, [], Modules) -> + io:format("Done...~n"), + {ok, lists:reverse(Modules)}; +execute(Filename, [Expr = {mod, _, {atom, _, Name}, []}|Tail], Modules) -> + {ok, [Core]} = xerl_codegen:exprs([Expr]), + {ok, [{Name, []}]} = core_lint:module(Core), + io:format("~s~n", [core_pp:format(Core)]), + {ok, _, Beam} = compile:forms(Core, + [binary, from_core, return_errors, {source, Filename}]), + {module, Name} = code:load_binary(Name, Filename, Beam), + execute(Filename, Tail, [Name|Modules]). +---- + +Running this compiler over the first snippet yields the following +result: + +[source,erlang] +---- +Compiling test/mod_SUITE_data/two_modules.xerl... +module 'first_module' ['module_info'/0, + 'module_info'/1] + attributes [] +'module_info'/0 = + fun () -> + call 'erlang':'get_module_info' + ('first_module') +'module_info'/1 = + fun (Key) -> + call 'erlang':'get_module_info' + ('first_module', Key) +end +module 'second_module' ['module_info'/0, + 'module_info'/1] + attributes [] +'module_info'/0 = + fun () -> + call 'erlang':'get_module_info' + ('second_module') +'module_info'/1 = + fun (Key) -> + call 'erlang':'get_module_info' + ('second_module', Key) +end +Done... +{ok,[first_module,second_module]} +---- + +Everything looks fine. And we can check that the two modules have +been loaded into the VM: + +[source,erlang] +---- +9> m(first_module). +Module first_module compiled: Date: February 2 2013, Time: 14.56 +Compiler options: [from_core] +Object file: test/mod_SUITE_data/two_modules.xerl +Exports: + module_info/0 + module_info/1 +ok +10> m(second_module). +Module second_module compiled: Date: February 2 2013, Time: 14.56 +Compiler options: [from_core] +Object file: test/mod_SUITE_data/two_modules.xerl +Exports: + module_info/0 + module_info/1 +ok +---- + +So far so good! + +What about the second snippet? It brings up many questions. What +happens once a `mod` expression has been executed at +compile time? If it's an expression then it has to have a result, +right? Right. We are still a bit lacking with expressions for now, +though, so let's get back to it after we add more. + +* https://github.com/extend/xerl/blob/0.2/[View the source] diff --git a/_build/content/articles/xerl-0.3-atomic-expressions.asciidoc b/_build/content/articles/xerl-0.3-atomic-expressions.asciidoc new file mode 100644 index 00000000..dae14906 --- /dev/null +++ b/_build/content/articles/xerl-0.3-atomic-expressions.asciidoc @@ -0,0 +1,135 @@ ++++ +date = "2013-02-18T00:00:00+01:00" +title = "Xerl: atomic expressions" + ++++ + +We will be adding atomic integer expressions to our language. +These look as follow in Erlang: + +[source,erlang] +42. + +And the result of this expression is of course 42. + +We will be running this expression at compile time, since we +don't have the means to run code at runtime yet. This will of +course result in no module being compiled, but that's OK, it will +allow us to discuss a few important things we'll have to plan for +later on. + +First, we must of course accept integers in the tokenizer. + +[source,erlang] +{D}+ : {token, {integer, TokenLine, list_to_integer(TokenChars)}}. + +We must then accept atomic integer expressions in the parser. +This is a simple change. The integer token is terminal so we need +to add it to the list of terminals, and then we only need to add +it as a possible expression. + +[source,erlang] +expr -> integer : '$1'. + +A file containing only the number 42 (with no terminating dot) +will give the following result when parsing it. This is incidentally +the same result as when tokenizing. + +[source,erlang] +---- +[{integer,1,42}] +---- + +We must then evaluate it. We're going to interpret it for now. +Since the result of this expression is not stored in a variable, +we are going to simply print it on the screen and discard it. + +[source,erlang] +---- +execute(Filename, [{integer, _, Int}|Tail], Modules) -> + io:format("integer ~p~n", [Int]), + execute(Filename, Tail, Modules). +---- + +You might think by now that what we've done so far this time +is useless. It brings up many interesting questions though. + +* What happens if a file contains two integers? +* Can we live without expression separators? +* Do we need an interpreter for the compile step? + +This is what happens when we create a file that contains two +integers on two separate lines: + +[source,erlang] +---- +[{integer,1,42},{integer,2,43}] +---- + +And on the same lines: + +[source,erlang] +---- +[{integer,1,42},{integer,1,43}] +---- + +Does this mean we do not need separators between expressions? +Not quite. The `+` and `-` operators are an +example of why we can't have nice things. They are ambiguous. They +have two different meanings: make an atomic integer positive or +negative, or perform an addition or a substraction between two +integers. Without a separator you won't be able to know if the +following snippet is one or two expressions: + +[source,erlang] +42 - 12 + +Can we use the line ending as an expression separator then? +Some languages make whitespace important, often the line +separator becomes the expression separator. I do not think this +is the best idea, it can lead to errors. For example the following +snippet would be two expressions: + +[source,erlang] +---- +Var = some_module:some_function() + some_module:other_function() + + another_module:another_function() +---- + +It is not obvious what would happen unless you are a veteran +of the language, and so we will not go down that road. We will use +an expression separator just like in Erlang: the comma. We will +however allow a trailing comma to make copy pasting code easier, +even if this means some old academics guy will go nuts about it +later on. This trailing comma will be optional and simply discarded +by the parser when encountered. We will implement this next. + +The question as to how we will handle running expressions +remains. We have two choices here: we can write an interpreter, +or we can compile the code and run it. Writing an interpreter +would require us to do twice the work, and we are lazy, so we will +not do that. + +You might already know that Erlang does not use the same code +for compiling and for evaluating commands in the shell. The main +reason for this is that in Erlang everything isn't an expression. +Indeed, the compiler compiles forms which contain expressions, +but you can't have forms in the shell. + +How are we going to compile the code that isn't part of a module +then? What do we need to run at compile-time, anyway? The body of +the file itself, of course. The body of module declarations. That's +about it. + +For the file itself, we can simply compile it as a big function +that will be executed. Then, everytime we encounter a module +declaration, we will run the compiler on its body, making its body +essentially a big function that will be executed. The same mechanism +will be applied when we encounter a module declaration at runtime. + +At runtime there's nothing else for us to do, the result of this +operation will load all the compiled modules. At compile time we +will also want to save them to a file. We'll see later how we can +do that. + +* https://github.com/extend/xerl/blob/0.3/[View the source] diff --git a/_build/content/articles/xerl-0.4-expression-separator.asciidoc b/_build/content/articles/xerl-0.4-expression-separator.asciidoc new file mode 100644 index 00000000..c137cf1d --- /dev/null +++ b/_build/content/articles/xerl-0.4-expression-separator.asciidoc @@ -0,0 +1,48 @@ ++++ +date = "2013-03-01T00:00:00+01:00" +title = "Xerl: expression separator" + ++++ + +As promised we are adding an expression separator this time. +This will be short and easy. + +In the tokenizer we only need to add a line recognizing the +comma as a valid token. + +[source,erlang] +, : {token, {',', TokenLine}}. + +Then we need to change the following lines in the parser: + +[source,erlang] +exprs -> expr : ['$1']. +exprs -> expr exprs : ['$1' | '$2']. + +And add a comma between the expressions on the second line: + +[source,erlang] +exprs -> expr : ['$1']. +exprs -> expr ',' exprs : ['$1' | '$3']. + +That takes care of everything except the optional trailing +comma at the end of our lists of expressions. We just need an +additional rule to take care of this. + +[source,erlang] +exprs -> expr ',' : ['$1']. + +That's it. + +Wondering why we don't have this optional trailing comma in +Erlang considering how easy it was and the number of people +complaining about it? Yeah, me too. But that's for someone else +to answer. + +Another change I want to talk about is a simple modification +of the compiler code to use an `#env{}` record for +tracking state instead of passing around individual variables. +This will be required later on when we make modules into proper +expressions so I thought it was a good idea to anticipate. + +* https://github.com/extend/xerl/blob/0.4/[View the source] diff --git a/_build/content/articles/xerl-0.5-intermediate-module.asciidoc b/_build/content/articles/xerl-0.5-intermediate-module.asciidoc new file mode 100644 index 00000000..37f93337 --- /dev/null +++ b/_build/content/articles/xerl-0.5-intermediate-module.asciidoc @@ -0,0 +1,145 @@ ++++ +date = "2013-03-25T00:00:00+01:00" +title = "Xerl: intermediate module" + ++++ + +Today we will start the work on the intermediate module +that will be used to run the code for the expressions found +in our file's body, replacing our interpreter. + +This is what we want to have when all the work is done: + +---- +xerl -> tokens -> AST -> intermediate -> cerl +---- + +Today we will perform this work only on the atomic integer +expression however, so we will not build any module at the end. +We have a few more things to take care of before getting there. +This does mean that we completely break compilation of modules +though, so hopefully we can resolve that soon. + +This intermediate representation is in the form of a module +which contains a single function: `run/0`. This function +contains all the expressions from our Xerl source file. + +In the case of a Xerl source file only containing the integer +`42`, we will obtain the following module ready to +be executed: + +[source,erlang] +---- +-module('$xerl_intermediate'). +-export([run/0]). + +run() -> + 42. +---- + +Running it will of course give us a result of `42`, +the same we had when interpreting expressions. + +The resulting Core Erlang code looks like this: + +[source,erlang] +---- +module '$xerl_intermediate' ['run'/0] + attributes [] +'run'/0 = + fun () -> + 42 +end +---- + +The nice thing about doing it like this is that other than the +definition of the intermediate module and its `run/0` +function, we can use the same code we are using for generating +the final Beam file. It may also be faster than interpreting +if you have complex modules. + +Of course this here only works for the simplest cases, as you +cannot declare a module or a function inside another Erlang function. +We will need to wrap these into function calls to the Xerl compiler +that will take care of compiling them, making them available for +any subsequent expression. We will also need to pass the environment +to the `run` function to keep track of all this. + +This does mean that we will have different code for compiling +`fun` and `mod` expressions when creating +the intermediate module. But the many other expressions don't need +any special care. + +Right now we've used the `'$xerl_intermediate'` atom +for the intermediate module name because we only have one, but we +will need to have a more random name later on when we'll implement +modules this way. + +The attentive mind will know by now that when compiling a Xerl +file containing one module, we will need to compile two intermediate +modules: one for the file body, and one for the module's body. Worry +not though, if we only detect `mod` instructions in the file +body, we can just skip this phase. + +While we're at it, we'll modify our code generator to handle lists +of expressions, which didn't actually work with integer literals +before. + +We're going to use Core Erlang sequences for running the many +expressions. Sequences work like `let`, except no value +is actually bound. Perfect for our case, since we don't support +binding values at this time anyway. + +Sequences have an argument and a body, both being Core Erlang +expressions. The simplest way to have many expressions is to use +a simple expression for the argument and a sequence for the rest +of the expressions. When we encounter the last expression in the +list, we do not create a sequence. + +The result is this very simple function: + +[source,erlang] +---- +comp_body([Expr]) -> + expr(Expr); +comp_body([Expr|Exprs]) -> + Arg = expr(Expr), + Body = comp_body(Exprs), + cerl:c_seq(Arg, Body). +---- + +In the case of our example above, a sequence will not be created, +we only have one expression. If we were to have `42, 43, 44` +in our Xerl source file, we would have a result equivalent to the +following before optimization: + +[source,erlang] +---- +-module('$xerl_intermediate'). +-export([run/0]). + +run() -> + 42, + 43, + 44. +---- + +And the result is of course `44`. + +The resulting Core Erlang code looks like this: + +[source,erlang] +---- +module '$xerl_intermediate' ['run'/0] + attributes [] +'run'/0 = + fun () -> + do 42 + do 43 + 44 +end +---- + +Feels very lisp-y, right? Yep. + +* https://github.com/extend/xerl/blob/0.5/[View the source] diff --git a/_build/content/docs.asciidoc b/_build/content/docs.asciidoc new file mode 100644 index 00000000..f22fc81c --- /dev/null +++ b/_build/content/docs.asciidoc @@ -0,0 +1,28 @@ ++++ +date = "2015-07-01T00:00:00+01:00" +title = "Documentation" +section = "docs" +type = "docs-index" +aliases = [ + "/docs/en/", + "/docs/en/cowboy/", + "/docs/en/erlang.mk/", + "/docs/en/gun/", + "/docs/en/ranch/", + "/docs/en/cowboy/1.0/", + "docs/en/cowboy/HEAD/", + "docs/en/cowboy/HEAD/guide/", + "docs/en/cowboy/HEAD/manual/", + "/docs/en/cowboy/2.0/", + "/docs/en/erlang.mk/1/", + "/docs/en/gun/1.0/", + "/docs/en/ranch/1.2/" +] ++++ + +=== Contribute + +Do you have examples, tutorials, videos about one or more +of my projects? I would happily include them on this page. + +mailto:contact@ninenines.eu[Send me an email with the details]. diff --git a/_build/content/donate.asciidoc b/_build/content/donate.asciidoc new file mode 100644 index 00000000..4ac8d4b8 --- /dev/null +++ b/_build/content/donate.asciidoc @@ -0,0 +1,24 @@ ++++ +date = "2015-07-01T00:00:00+01:00" +title = "Donate" +type = "services" ++++ + +=== Like my work? Donate! + +You can donate via Paypal to reward me, Loïc Hoguin, for my +work on open source software including Cowboy and Erlang.mk. + +++++ +
+ + + + + + + + + +
+++++ diff --git a/_build/content/services.asciidoc b/_build/content/services.asciidoc new file mode 100644 index 00000000..88baac57 --- /dev/null +++ b/_build/content/services.asciidoc @@ -0,0 +1,95 @@ ++++ +date = "2015-07-01T00:00:00+01:00" +title = "Consulting & Training" +type = "services" +aliases = [ + "/training/" +] ++++ + +If you are interested by any of these opportunities, +mailto:contact@ninenines.eu[send me an email]. + +== Consulting + +You can get me, Loïc Hoguin, author of Cowboy, to help you +solve a problem or work on a particular project. + +My area of expertise is Erlang; HTTP, Websocket and REST APIs; +design and implementation of protocols; and messaging systems. + +I can also be helpful with testing or code reviews. + +I offer both hourly and daily rates: + +* 200€ hourly rate (remote) +* 1000€ daily rate (remote and on-site) + +For remote consulting, the work can be done by phone, email, +IRC, GitHub and/or any other platform for collaborative work. + +For on-site consulting, the travel expenses and +accomodations are to be paid by the customer. I will also +ask for a higher rate if forced to stay on-site for more +than a week. + +Note that my expertise does not cover all areas where +Erlang is used. My help will be limited in the areas of +distributed databases, or large distributed systems. + +== Sponsoring + +You can sponsor one of my projects. + +Sponsoring gives you: + +* a direct, private line of communication + +* the power to make me maintain older versions of my projects + (as long as they are sponsoring) + +* priority when adding features or fixing bugs + +* advertisement space on this website and in the README file + of the project of your choice + +Sponsors may choose to benefit from any of these perks. + +In exchange sponsors must contribute financially. A minimum +of 200€ per month is required. Sponsors may give as much as +they want. Payment can be monthly or one-time. Invoices are +of course provided. + +== Erlang beginner training + +I would be happy to introduce more people to Erlang. I have +a 1-day Erlang training readily available for consumption. +The goal of this training is to teach the basics of Erlang +systems and programming. It's a kind of "Getting started" +for Erlang. + +You can review the link:/talks/thinking-in-erlang/thinking-in-erlang.html[training slides]. + +This training is meant to be given to a large number of +people interested in Erlang, as part of a public event, +where anyone interested can come. + +Another important aspect of this training is that it is +meant to be affordable. We want the most people to learn +Erlang as possible. + +If you have room, think you can gather 20+ people and +are interested in sponsoring a training session, then +we should talk. + +== Custom training + +I can also provide custom training, tailored to your level +and your needs. It can take the form of a class, Q&A or a +code review/writing session. I need to know your expectations +to prepare an appropriate training. + +Custom training rates are the same as consulting rates and +the same restrictions apply. + +// @todo Also need the donate link. diff --git a/_build/content/slogan.asciidoc b/_build/content/slogan.asciidoc new file mode 100644 index 00000000..f132e064 --- /dev/null +++ b/_build/content/slogan.asciidoc @@ -0,0 +1,7 @@ ++++ +date = "2015-07-01T00:00:00+01:00" +title = "Slogan" ++++ + +The Erlanger Playbook is now available! + +link:/articles/erlanger-playbook[Buy now] — link:/services[Become a Cowboy project sponsor] diff --git a/_build/content/talks.asciidoc b/_build/content/talks.asciidoc new file mode 100644 index 00000000..3dc41452 --- /dev/null +++ b/_build/content/talks.asciidoc @@ -0,0 +1,14 @@ ++++ +date = "2015-07-01T00:00:00+01:00" +title = "Public talks" +type = "talks" ++++ + +=== Talk requests + +Organizing a conference and in need of a speaker for a talk +about Erlang and the Web? Need an introduction to Erlang/OTP +for your company? Looking for a cool subject for a user group +meeting? + +mailto:contact@ninenines.eu[Send me an email with the details]. diff --git a/_build/data/projects/bullet.toml b/_build/data/projects/bullet.toml new file mode 100644 index 00000000..7725c249 --- /dev/null +++ b/_build/data/projects/bullet.toml @@ -0,0 +1,8 @@ +title = "Bullet" +catchphrase = "The Cowboy's silver bullet." +description = "Bullet is a permanent bidirectional connection between the browser and the server." +name = "bullet" +repository = "https://github.com/ninenines/bullet" +versions = ["1.0"] +branches = ["master"] +has_source = true diff --git a/_build/data/projects/cowboy.toml b/_build/data/projects/cowboy.toml new file mode 100644 index 00000000..a9bb6bf4 --- /dev/null +++ b/_build/data/projects/cowboy.toml @@ -0,0 +1,10 @@ +title = "Cowboy" +catchphrase = "Small, fast, modular HTTP server." +description = "Cowboy is the ultimate server for the modern Web with support for Websocket, HTTP/2 and REST." +name = "cowboy" +repository = "https://github.com/ninenines/cowboy" +versions = ["1.0", "2.0"] +branches = ["1.0.x", "master"] +has_source = true +has_guide = true +has_manual = true diff --git a/_build/data/projects/cowlib.toml b/_build/data/projects/cowlib.toml new file mode 100644 index 00000000..9e007bf9 --- /dev/null +++ b/_build/data/projects/cowlib.toml @@ -0,0 +1,8 @@ +title = "Cowlib" +catchphrase = "Support library for the Web." +description = "The Web toolbox for HTTP/1.1, HTTP/2, Websocket, Multipart, Cookies, URL encoding..." +name = "cowlib" +repository = "https://github.com/ninenines/cowlib" +versions = ["2.0"] +branches = ["master"] +has_source = true diff --git a/_build/data/projects/erlang.mk.toml b/_build/data/projects/erlang.mk.toml new file mode 100644 index 00000000..c18d1dbb --- /dev/null +++ b/_build/data/projects/erlang.mk.toml @@ -0,0 +1,9 @@ +title = "Erlang.mk" +catchphrase = "A build tool that just works." +description = "Embrace the power and simplicity of Makefiles." +name = "erlang.mk" +repository = "https://github.com/ninenines/erlang.mk" +versions = ["1"] +branches = ["master"] +has_source = true +external_site = "http://erlang.mk" diff --git a/_build/data/projects/gun.toml b/_build/data/projects/gun.toml new file mode 100644 index 00000000..b92c8bff --- /dev/null +++ b/_build/data/projects/gun.toml @@ -0,0 +1,10 @@ +title = "Gun" +catchphrase = "The smoking gun of HTTP clients." +description = "Asynchronous, always-connected client with support for HTTP/1.1, HTTP/2 and Websocket." +name = "gun" +repository = "https://github.com/ninenines/gun" +versions = ["1.0"] +branches = ["master"] +has_source = true +has_guide = true +has_manual = true diff --git a/_build/data/projects/ranch.toml b/_build/data/projects/ranch.toml new file mode 100644 index 00000000..1f3cb624 --- /dev/null +++ b/_build/data/projects/ranch.toml @@ -0,0 +1,10 @@ +title = "Ranch" +catchphrase = "The holy cow of servers." +description = "Ranch is a socket acceptor pool for building awesome TCP and TLS servers." +name = "ranch" +repository = "https://github.com/ninenines/ranch" +versions = ["1.2"] +branches = ["master"] +has_source = true +has_guide = true +has_manual = true diff --git a/_build/data/talks.toml b/_build/data/talks.toml new file mode 100644 index 00000000..f0eca7b7 --- /dev/null +++ b/_build/data/talks.toml @@ -0,0 +1,86 @@ +# [[future]] +# name = "" +# title = "" +# link = "" +# date = 2016-01-01 +# location = "" + +[[past]] +name = "Erlang User Conference 2015" +title = "Cowboy 2.0" +link = "/talks/cowboy-2/" + +[[past]] +name = "Erlang User Conference 2014" +title = "The last REST client you will ever need" +link = "/talks/bed/bed.html" + +[[past]] +name = "Erlang Factory SF Bay Area 2014" +title = "D3.js + Websocket for live Web applications" +link = "/talks/cowboy-d3/cowboy-d3.html" + +[[past]] +name = "Erlang/OTP トレーニング 2013.10" +title = "Thinking in Erlang" +link = "/talks/thinking-in-erlang/thinking-in-erlang.html" + +[[past]] +name = "Erlang User Conference 2013" +title = "Beyond OTP" +link = "/talks/beyond-otp/beyond-otp.html" + +[[past]] +name = "Erlang Factory SF Bay Area 2013" +title = "The new Cowboy" +link = "/talks/cowboy-0.8/cowboy-0.8.html" + +[[past]] +name = "Munich Erlang Factory Lite 2013" +title = "Build custom protocols with Ranch and msgpack" +link = "/talks/ranch-msgpack/ranch-msgpack.html" + +[[past]] +name = "ErlangDC 2013" +title = "Cowboy and Websocket" +link = "/talks/cowboy-websocket/cowboy-websocket.html" + +[[past]] +name = "Erlang Factory Lite Paris 2012" +title = "Un webchat avec Cowboy en 45 minutes" +link = "http://www.erlang-factory.com/conference/Paris2012/speakers/LoicHoguin" + +[[past]] +name = "Erlang Factory Lite London 2012" +title = "Build an FTP server in 30 minutes with Ranch" +link = "/articles/ranch-ftp" + +[[past]] +name = "Erlang Study Meeting Tokyo 2012.09" +title = "The future of the web with Cowboy and Ranch" +link = "/talks/erlang-tokyo-2012-09/erlang-tokyo-2012-09.html" + +[[past]] +name = "OSCON 2012" +title = "Efficient Web Applications with Erlang and Cowboy" +link = "/talks/oscon2012/oscon2012.html" + +[[past]] +name = "Erlang User Conference 2012" +title = "Reverse-engineering a proprietary game server with Erlang" +link = "/talks/reverse-engineering/reverse-engineering.html" + +[[past]] +name = "Erlang Factory SF Bay Area 2012" +title = "Leverage the World Wide West with Farwest" +link = "/talks/farwest/farwest.html" + +[[past]] +name = "Erlang User Conference 2011" +title = "A Cowboy quest for a modern web (PDF)" +link = "/talks/PDF/cowboy.pdf" + +[[past]] +name = "Erlang Factory Lite Paris 2011" +title = "Validation using Erlang's type system with Sheriff (PDF)" +link = "/talks/PDF/sheriff.pdf" diff --git a/_build/static/CNAME b/_build/static/CNAME new file mode 100644 index 00000000..f6a42dd6 --- /dev/null +++ b/_build/static/CNAME @@ -0,0 +1 @@ +ninenines.eu diff --git a/_build/static/docs/db.json b/_build/static/docs/db.json new file mode 100644 index 00000000..368e78f0 --- /dev/null +++ b/_build/static/docs/db.json @@ -0,0 +1 @@ +[{"n":"cowboy_static:extra_mimetypes","l":"/docs/en/cowboy/1.0/manual/cowboy_static/index.html#extra_mimetypes"},{"n":"cowboy_static:extra","l":"/docs/en/cowboy/1.0/manual/cowboy_static/index.html#extra"},{"n":"cowboy_static:opts","l":"/docs/en/cowboy/1.0/manual/cowboy_static/index.html#opts"},{"n":"cowboy_static:extra_etag","l":"/docs/en/cowboy/1.0/manual/cowboy_static/index.html#extra_etag"},{"n":"http_status_codes:304 Not Modified","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#304 not modified"},{"n":"http_status_codes:500 Internal Server Error","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#500 internal server error"},{"n":"http_status_codes:201 Created","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#201 created"},{"n":"http_status_codes:413 Request Entity Too Large","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#413 request entity too large"},{"n":"http_status_codes:300 Multiple Choices","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#300 multiple choices"},{"n":"http_status_codes:412 Precondition Failed","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#412 precondition failed"},{"n":"http_status_codes:200 OK","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#200 ok"},{"n":"http_status_codes:101 Switching Protocols","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#101 switching protocols"},{"n":"http_status_codes:501 Not Implemented","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#501 not implemented"},{"n":"http_status_codes:505 HTTP Version Not Supported","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#505 http version not supported"},{"n":"http_status_codes:204 No Content","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#204 no content"},{"n":"http_status_codes:406 Not Acceptable","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#406 not acceptable"},{"n":"http_status_codes:415 Unsupported Media Type","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#415 unsupported media type"},{"n":"http_status_codes:503 Service Unavailable","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#503 service unavailable"},{"n":"http_status_codes:410 Gone","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#410 gone"},{"n":"http_status_codes:400 Bad Request","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#400 bad request"},{"n":"http_status_codes:401 Unauthorized","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#401 unauthorized"},{"n":"http_status_codes:301 Moved Permanently","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#301 moved permanently"},{"n":"http_status_codes:100 Continue","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#100 continue"},{"n":"http_status_codes:414 Request-URI Too Long","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#414 request-uri too long"},{"n":"http_status_codes:307 Temporary Redirect","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#307 temporary redirect"},{"n":"http_status_codes:409 Conflict","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#409 conflict"},{"n":"http_status_codes:202 Accepted","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#202 accepted"},{"n":"http_status_codes:404 Not Found","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#404 not found"},{"n":"http_status_codes:303 See Other","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#303 see other"},{"n":"http_status_codes:405 Method Not Allowed","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#405 method not allowed"},{"n":"http_status_codes:403 Forbidden","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#403 forbidden"},{"n":"http_status_codes:408 Request Timeout","l":"/docs/en/cowboy/1.0/manual/http_status_codes/index.html#408 request timeout"},{"n":"cowboy:http_version","l":"/docs/en/cowboy/1.0/manual/cowboy/index.html#http_version"},{"n":"cowboy:http_status","l":"/docs/en/cowboy/1.0/manual/cowboy/index.html#http_status"},{"n":"cowboy:onrequest_fun","l":"/docs/en/cowboy/1.0/manual/cowboy/index.html#onrequest_fun"},{"n":"cowboy:onresponse_fun","l":"/docs/en/cowboy/1.0/manual/cowboy/index.html#onresponse_fun"},{"n":"cowboy:start_http","l":"/docs/en/cowboy/1.0/manual/cowboy/index.html#start_http"},{"n":"cowboy:http_headers","l":"/docs/en/cowboy/1.0/manual/cowboy/index.html#http_headers"},{"n":"cowboy:start_https","l":"/docs/en/cowboy/1.0/manual/cowboy/index.html#start_https"},{"n":"cowboy:start_spdy","l":"/docs/en/cowboy/1.0/manual/cowboy/index.html#start_spdy"},{"n":"cowboy:stop_listener","l":"/docs/en/cowboy/1.0/manual/cowboy/index.html#stop_listener"},{"n":"cowboy:set_env","l":"/docs/en/cowboy/1.0/manual/cowboy/index.html#set_env"},{"n":"cowboy_http_handler:handle","l":"/docs/en/cowboy/1.0/manual/cowboy_http_handler/index.html#handle"},{"n":"cowboy_http_handler:init","l":"/docs/en/cowboy/1.0/manual/cowboy_http_handler/index.html#init"},{"n":"cowboy_http_handler:terminate","l":"/docs/en/cowboy/1.0/manual/cowboy_http_handler/index.html#terminate"},{"n":"cowboy_loop_handler:info","l":"/docs/en/cowboy/1.0/manual/cowboy_loop_handler/index.html#info"},{"n":"cowboy_loop_handler:init","l":"/docs/en/cowboy/1.0/manual/cowboy_loop_handler/index.html#init"},{"n":"cowboy_loop_handler:terminate","l":"/docs/en/cowboy/1.0/manual/cowboy_loop_handler/index.html#terminate"},{"n":"cowboy_middleware:env","l":"/docs/en/cowboy/1.0/manual/cowboy_middleware/index.html#env"},{"n":"cowboy_middleware:execute","l":"/docs/en/cowboy/1.0/manual/cowboy_middleware/index.html#execute"},{"n":"cowboy_protocol:max_header_name_length ","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#max_header_name_length "},{"n":"cowboy_protocol:max_keepalive ","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#max_keepalive "},{"n":"cowboy_protocol:max_request_line_length ","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#max_request_line_length "},{"n":"cowboy_protocol:middlewares ","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#middlewares "},{"n":"cowboy_protocol:onresponse ","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#onresponse "},{"n":"cowboy_protocol:timeout ","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#timeout "},{"n":"cowboy_protocol:max_header_value_length ","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#max_header_value_length "},{"n":"cowboy_protocol:max_headers ","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#max_headers "},{"n":"cowboy_protocol:max_empty_lines ","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#max_empty_lines "},{"n":"cowboy_protocol:compress ","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#compress "},{"n":"cowboy_protocol:onrequest ","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#onrequest "},{"n":"cowboy_protocol:env ","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#env "},{"n":"cowboy_protocol:opts","l":"/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html#opts"},{"n":"cowboy_req:has_resp_body","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#has_resp_body"},{"n":"cowboy_req:body_length","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#body_length"},{"n":"cowboy_req:headers","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#headers"},{"n":"cowboy_req:chunk","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#chunk"},{"n":"cowboy_req:parse_header","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#parse_header"},{"n":"cowboy_req:req","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#req"},{"n":"cowboy_req:cookie","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#cookie"},{"n":"cowboy_req:reply","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#reply"},{"n":"cowboy_req:method","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#method"},{"n":"cowboy_req:body_qs","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#body_qs"},{"n":"cowboy_req:set_resp_cookie","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#set_resp_cookie"},{"n":"cowboy_req:set_resp_header","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#set_resp_header"},{"n":"cowboy_req:port","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#port"},{"n":"cowboy_req:peer","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#peer"},{"n":"cowboy_req:part","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#part"},{"n":"cowboy_req:meta","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#meta"},{"n":"cowboy_req:continue","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#continue"},{"n":"cowboy_req:delete_resp_header","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#delete_resp_header"},{"n":"cowboy_req:set_meta","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#set_meta"},{"n":"cowboy_req:chunked_reply","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#chunked_reply"},{"n":"cowboy_req:host","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#host"},{"n":"cowboy_req:host_url","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#host_url"},{"n":"cowboy_req:qs_val","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#qs_val"},{"n":"cowboy_req:body","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#body"},{"n":"cowboy_req:cookies","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#cookies"},{"n":"cowboy_req:host_info","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#host_info"},{"n":"cowboy_req:cookie_opts","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#cookie_opts"},{"n":"cowboy_req:version","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#version"},{"n":"cowboy_req:qs","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#qs"},{"n":"cowboy_req:body_opts","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#body_opts"},{"n":"cowboy_req:bindings","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#bindings"},{"n":"cowboy_req:header","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#header"},{"n":"cowboy_req:binding","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#binding"},{"n":"cowboy_req:path_info","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#path_info"},{"n":"cowboy_req:compact","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#compact"},{"n":"cowboy_req:has_body","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#has_body"},{"n":"cowboy_req:path","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#path"},{"n":"cowboy_req:set_resp_body","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#set_resp_body"},{"n":"cowboy_req:has_resp_header","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#has_resp_header"},{"n":"cowboy_req:url","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#url"},{"n":"cowboy_req:qs_vals","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#qs_vals"},{"n":"cowboy_req:set_resp_body_fun","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#set_resp_body_fun"},{"n":"cowboy_req:part_body","l":"/docs/en/cowboy/1.0/manual/cowboy_req/index.html#part_body"},{"n":"cowboy_rest:valid_content_headers","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#valid_content_headers"},{"n":"cowboy_rest:generate_etag","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#generate_etag"},{"n":"cowboy_rest:forbidden","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#forbidden"},{"n":"cowboy_rest:valid_entity_length","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#valid_entity_length"},{"n":"cowboy_rest:expires","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#expires"},{"n":"cowboy_rest:resource_exists","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#resource_exists"},{"n":"cowboy_rest:last_modified","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#last_modified"},{"n":"cowboy_rest:delete_completed","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#delete_completed"},{"n":"cowboy_rest:is_conflict","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#is_conflict"},{"n":"cowboy_rest:moved_permanently","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#moved_permanently"},{"n":"cowboy_rest:media_type","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#media_type"},{"n":"cowboy_rest:charsets_provided","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#charsets_provided"},{"n":"cowboy_rest:content_types_provided","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#content_types_provided"},{"n":"cowboy_rest:content_types_accepted","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#content_types_accepted"},{"n":"cowboy_rest:previously_existed","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#previously_existed"},{"n":"cowboy_rest:languages_provided","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#languages_provided"},{"n":"cowboy_rest:uri_too_long","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#uri_too_long"},{"n":"cowboy_rest:moved_temporarily","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#moved_temporarily"},{"n":"cowboy_rest:charset","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#charset"},{"n":"cowboy_rest:rest_init","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#rest_init"},{"n":"cowboy_rest:rest_terminate","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#rest_terminate"},{"n":"cowboy_rest:known_content_type","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#known_content_type"},{"n":"cowboy_rest:allow_missing_post","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#allow_missing_post"},{"n":"cowboy_rest:options","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#options"},{"n":"cowboy_rest:multiple_choices","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#multiple_choices"},{"n":"cowboy_rest:language","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#language"},{"n":"cowboy_rest:allowed_methods","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#allowed_methods"},{"n":"cowboy_rest:malformed_request","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#malformed_request"},{"n":"cowboy_rest:known_methods","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#known_methods"},{"n":"cowboy_rest:Callback","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#callback"},{"n":"cowboy_rest:delete_resource","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#delete_resource"},{"n":"cowboy_rest:service_available","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#service_available"},{"n":"cowboy_rest:is_authorized","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#is_authorized"},{"n":"cowboy_rest:variances","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#variances"},{"n":"cowboy_rest:init","l":"/docs/en/cowboy/1.0/manual/cowboy_rest/index.html#init"},{"n":"cowboy_router:constraints","l":"/docs/en/cowboy/1.0/manual/cowboy_router/index.html#constraints"},{"n":"cowboy_router:routes","l":"/docs/en/cowboy/1.0/manual/cowboy_router/index.html#routes"},{"n":"cowboy_router:tokens","l":"/docs/en/cowboy/1.0/manual/cowboy_router/index.html#tokens"},{"n":"cowboy_router:bindings","l":"/docs/en/cowboy/1.0/manual/cowboy_router/index.html#bindings"},{"n":"cowboy_router:compile","l":"/docs/en/cowboy/1.0/manual/cowboy_router/index.html#compile"},{"n":"cowboy_router:dispatch_rules","l":"/docs/en/cowboy/1.0/manual/cowboy_router/index.html#dispatch_rules"},{"n":"cowboy_spdy:middlewares ","l":"/docs/en/cowboy/1.0/manual/cowboy_spdy/index.html#middlewares "},{"n":"cowboy_spdy:onresponse ","l":"/docs/en/cowboy/1.0/manual/cowboy_spdy/index.html#onresponse "},{"n":"cowboy_spdy:onrequest ","l":"/docs/en/cowboy/1.0/manual/cowboy_spdy/index.html#onrequest "},{"n":"cowboy_spdy:opts","l":"/docs/en/cowboy/1.0/manual/cowboy_spdy/index.html#opts"},{"n":"cowboy_spdy:env ","l":"/docs/en/cowboy/1.0/manual/cowboy_spdy/index.html#env "},{"n":"cowboy_sub_protocol:upgrade","l":"/docs/en/cowboy/1.0/manual/cowboy_sub_protocol/index.html#upgrade"},{"n":"cowboy_websocket:websocket_compress","l":"/docs/en/cowboy/1.0/manual/cowboy_websocket/index.html#websocket_compress"},{"n":"cowboy_websocket:websocket_version","l":"/docs/en/cowboy/1.0/manual/cowboy_websocket/index.html#websocket_version"},{"n":"cowboy_websocket:close_code","l":"/docs/en/cowboy/1.0/manual/cowboy_websocket/index.html#close_code"},{"n":"cowboy_websocket:frame","l":"/docs/en/cowboy/1.0/manual/cowboy_websocket/index.html#frame"},{"n":"cowboy_websocket_handler:websocket_info","l":"/docs/en/cowboy/1.0/manual/cowboy_websocket_handler/index.html#websocket_info"},{"n":"cowboy_websocket_handler:websocket_terminate","l":"/docs/en/cowboy/1.0/manual/cowboy_websocket_handler/index.html#websocket_terminate"},{"n":"cowboy_websocket_handler:websocket_handle","l":"/docs/en/cowboy/1.0/manual/cowboy_websocket_handler/index.html#websocket_handle"},{"n":"cowboy_websocket_handler:init","l":"/docs/en/cowboy/1.0/manual/cowboy_websocket_handler/index.html#init"},{"n":"cowboy_websocket_handler:websocket_init","l":"/docs/en/cowboy/1.0/manual/cowboy_websocket_handler/index.html#websocket_init"},{"n":"cowboy_static:extra_mimetypes","l":"/docs/en/cowboy/HEAD/manual/cowboy_static/index.html#extra_mimetypes"},{"n":"cowboy_static:extra","l":"/docs/en/cowboy/HEAD/manual/cowboy_static/index.html#extra"},{"n":"cowboy_static:opts","l":"/docs/en/cowboy/HEAD/manual/cowboy_static/index.html#opts"},{"n":"cowboy_static:extra_etag","l":"/docs/en/cowboy/HEAD/manual/cowboy_static/index.html#extra_etag"},{"n":"http_status_codes:304 Not Modified","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#304 not modified"},{"n":"http_status_codes:500 Internal Server Error","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#500 internal server error"},{"n":"http_status_codes:201 Created","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#201 created"},{"n":"http_status_codes:413 Request Entity Too Large","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#413 request entity too large"},{"n":"http_status_codes:300 Multiple Choices","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#300 multiple choices"},{"n":"http_status_codes:412 Precondition Failed","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#412 precondition failed"},{"n":"http_status_codes:200 OK","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#200 ok"},{"n":"http_status_codes:101 Switching Protocols","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#101 switching protocols"},{"n":"http_status_codes:501 Not Implemented","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#501 not implemented"},{"n":"http_status_codes:505 HTTP Version Not Supported","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#505 http version not supported"},{"n":"http_status_codes:204 No Content","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#204 no content"},{"n":"http_status_codes:406 Not Acceptable","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#406 not acceptable"},{"n":"http_status_codes:415 Unsupported Media Type","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#415 unsupported media type"},{"n":"http_status_codes:503 Service Unavailable","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#503 service unavailable"},{"n":"http_status_codes:410 Gone","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#410 gone"},{"n":"http_status_codes:400 Bad Request","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#400 bad request"},{"n":"http_status_codes:401 Unauthorized","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#401 unauthorized"},{"n":"http_status_codes:301 Moved Permanently","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#301 moved permanently"},{"n":"http_status_codes:100 Continue","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#100 continue"},{"n":"http_status_codes:414 Request-URI Too Long","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#414 request-uri too long"},{"n":"http_status_codes:307 Temporary Redirect","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#307 temporary redirect"},{"n":"http_status_codes:409 Conflict","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#409 conflict"},{"n":"http_status_codes:202 Accepted","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#202 accepted"},{"n":"http_status_codes:404 Not Found","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#404 not found"},{"n":"http_status_codes:303 See Other","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#303 see other"},{"n":"http_status_codes:405 Method Not Allowed","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#405 method not allowed"},{"n":"http_status_codes:403 Forbidden","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#403 forbidden"},{"n":"http_status_codes:408 Request Timeout","l":"/docs/en/cowboy/HEAD/manual/http_status_codes/index.html#408 request timeout"},{"n":"cowboy:http_version","l":"/docs/en/cowboy/HEAD/manual/cowboy/index.html#http_version"},{"n":"cowboy:fields","l":"/docs/en/cowboy/HEAD/manual/cowboy/index.html#fields"},{"n":"cowboy:http_status","l":"/docs/en/cowboy/HEAD/manual/cowboy/index.html#http_status"},{"n":"cowboy:onresponse_fun","l":"/docs/en/cowboy/HEAD/manual/cowboy/index.html#onresponse_fun"},{"n":"cowboy:start_http","l":"/docs/en/cowboy/HEAD/manual/cowboy/index.html#start_http"},{"n":"cowboy:http_headers","l":"/docs/en/cowboy/HEAD/manual/cowboy/index.html#http_headers"},{"n":"cowboy:start_https","l":"/docs/en/cowboy/HEAD/manual/cowboy/index.html#start_https"},{"n":"cowboy:start_spdy","l":"/docs/en/cowboy/HEAD/manual/cowboy/index.html#start_spdy"},{"n":"cowboy:stop_listener","l":"/docs/en/cowboy/HEAD/manual/cowboy/index.html#stop_listener"},{"n":"cowboy:set_env","l":"/docs/en/cowboy/HEAD/manual/cowboy/index.html#set_env"},{"n":"cowboy_handler:{crash, Class, Reason}","l":"/docs/en/cowboy/HEAD/manual/cowboy_handler/index.html#{crash, class, reason}"},{"n":"cowboy_handler:normal","l":"/docs/en/cowboy/HEAD/manual/cowboy_handler/index.html#normal"},{"n":"cowboy_handler:init","l":"/docs/en/cowboy/HEAD/manual/cowboy_handler/index.html#init"},{"n":"cowboy_handler:terminate","l":"/docs/en/cowboy/HEAD/manual/cowboy_handler/index.html#terminate"},{"n":"cowboy_loop:{error, Reason}","l":"/docs/en/cowboy/HEAD/manual/cowboy_loop/index.html#{error, reason}"},{"n":"cowboy_loop:stop","l":"/docs/en/cowboy/HEAD/manual/cowboy_loop/index.html#stop"},{"n":"cowboy_loop:timeout","l":"/docs/en/cowboy/HEAD/manual/cowboy_loop/index.html#timeout"},{"n":"cowboy_loop:{crash, Class, Reason}","l":"/docs/en/cowboy/HEAD/manual/cowboy_loop/index.html#{crash, class, reason}"},{"n":"cowboy_loop:{error, closed}","l":"/docs/en/cowboy/HEAD/manual/cowboy_loop/index.html#{error, closed}"},{"n":"cowboy_loop:info","l":"/docs/en/cowboy/HEAD/manual/cowboy_loop/index.html#info"},{"n":"cowboy_loop:{error, overflow}","l":"/docs/en/cowboy/HEAD/manual/cowboy_loop/index.html#{error, overflow}"},{"n":"cowboy_loop:normal","l":"/docs/en/cowboy/HEAD/manual/cowboy_loop/index.html#normal"},{"n":"cowboy_middleware:env","l":"/docs/en/cowboy/HEAD/manual/cowboy_middleware/index.html#env"},{"n":"cowboy_middleware:execute","l":"/docs/en/cowboy/HEAD/manual/cowboy_middleware/index.html#execute"},{"n":"cowboy_protocol:max_header_name_length ","l":"/docs/en/cowboy/HEAD/manual/cowboy_protocol/index.html#max_header_name_length "},{"n":"cowboy_protocol:max_keepalive ","l":"/docs/en/cowboy/HEAD/manual/cowboy_protocol/index.html#max_keepalive "},{"n":"cowboy_protocol:max_request_line_length ","l":"/docs/en/cowboy/HEAD/manual/cowboy_protocol/index.html#max_request_line_length "},{"n":"cowboy_protocol:middlewares ","l":"/docs/en/cowboy/HEAD/manual/cowboy_protocol/index.html#middlewares "},{"n":"cowboy_protocol:onresponse ","l":"/docs/en/cowboy/HEAD/manual/cowboy_protocol/index.html#onresponse "},{"n":"cowboy_protocol:timeout ","l":"/docs/en/cowboy/HEAD/manual/cowboy_protocol/index.html#timeout "},{"n":"cowboy_protocol:max_header_value_length ","l":"/docs/en/cowboy/HEAD/manual/cowboy_protocol/index.html#max_header_value_length "},{"n":"cowboy_protocol:max_headers ","l":"/docs/en/cowboy/HEAD/manual/cowboy_protocol/index.html#max_headers "},{"n":"cowboy_protocol:max_empty_lines ","l":"/docs/en/cowboy/HEAD/manual/cowboy_protocol/index.html#max_empty_lines "},{"n":"cowboy_protocol:compress ","l":"/docs/en/cowboy/HEAD/manual/cowboy_protocol/index.html#compress "},{"n":"cowboy_protocol:env ","l":"/docs/en/cowboy/HEAD/manual/cowboy_protocol/index.html#env "},{"n":"cowboy_protocol:opts","l":"/docs/en/cowboy/HEAD/manual/cowboy_protocol/index.html#opts"},{"n":"cowboy_req:has_resp_body","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#has_resp_body"},{"n":"cowboy_req:body_length","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#body_length"},{"n":"cowboy_req:headers","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#headers"},{"n":"cowboy_req:chunk","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#chunk"},{"n":"cowboy_req:parse_header","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#parse_header"},{"n":"cowboy_req:req","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#req"},{"n":"cowboy_req:match_qs","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#match_qs"},{"n":"cowboy_req:reply","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#reply"},{"n":"cowboy_req:method","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#method"},{"n":"cowboy_req:parse_cookies","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#parse_cookies"},{"n":"cowboy_req:body_qs","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#body_qs"},{"n":"cowboy_req:parse_qs","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#parse_qs"},{"n":"cowboy_req:set_resp_cookie","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#set_resp_cookie"},{"n":"cowboy_req:set_resp_header","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#set_resp_header"},{"n":"cowboy_req:port","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#port"},{"n":"cowboy_req:peer","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#peer"},{"n":"cowboy_req:part","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#part"},{"n":"cowboy_req:meta","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#meta"},{"n":"cowboy_req:continue","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#continue"},{"n":"cowboy_req:delete_resp_header","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#delete_resp_header"},{"n":"cowboy_req:set_meta","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#set_meta"},{"n":"cowboy_req:chunked_reply","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#chunked_reply"},{"n":"cowboy_req:host","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#host"},{"n":"cowboy_req:host_url","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#host_url"},{"n":"cowboy_req:body","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#body"},{"n":"cowboy_req:host_info","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#host_info"},{"n":"cowboy_req:cookie_opts","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#cookie_opts"},{"n":"cowboy_req:version","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#version"},{"n":"cowboy_req:qs","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#qs"},{"n":"cowboy_req:body_opts","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#body_opts"},{"n":"cowboy_req:bindings","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#bindings"},{"n":"cowboy_req:header","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#header"},{"n":"cowboy_req:binding","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#binding"},{"n":"cowboy_req:match_cookies","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#match_cookies"},{"n":"cowboy_req:path_info","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#path_info"},{"n":"cowboy_req:has_body","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#has_body"},{"n":"cowboy_req:path","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#path"},{"n":"cowboy_req:set_resp_body","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#set_resp_body"},{"n":"cowboy_req:has_resp_header","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#has_resp_header"},{"n":"cowboy_req:url","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#url"},{"n":"cowboy_req:set_resp_body_fun","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#set_resp_body_fun"},{"n":"cowboy_req:part_body","l":"/docs/en/cowboy/HEAD/manual/cowboy_req/index.html#part_body"},{"n":"cowboy_rest:valid_content_headers","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#valid_content_headers"},{"n":"cowboy_rest:generate_etag","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#generate_etag"},{"n":"cowboy_rest:forbidden","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#forbidden"},{"n":"cowboy_rest:valid_entity_length","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#valid_entity_length"},{"n":"cowboy_rest:resource_exists","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#resource_exists"},{"n":"cowboy_rest:expires","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#expires"},{"n":"cowboy_rest:last_modified","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#last_modified"},{"n":"cowboy_rest:{crash, Class, Reason}","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#{crash, class, reason}"},{"n":"cowboy_rest:delete_completed","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#delete_completed"},{"n":"cowboy_rest:is_conflict","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#is_conflict"},{"n":"cowboy_rest:moved_permanently","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#moved_permanently"},{"n":"cowboy_rest:media_type","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#media_type"},{"n":"cowboy_rest:charsets_provided","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#charsets_provided"},{"n":"cowboy_rest:content_types_accepted","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#content_types_accepted"},{"n":"cowboy_rest:content_types_provided","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#content_types_provided"},{"n":"cowboy_rest:normal","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#normal"},{"n":"cowboy_rest:previously_existed","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#previously_existed"},{"n":"cowboy_rest:languages_provided","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#languages_provided"},{"n":"cowboy_rest:uri_too_long","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#uri_too_long"},{"n":"cowboy_rest:moved_temporarily","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#moved_temporarily"},{"n":"cowboy_rest:charset","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#charset"},{"n":"cowboy_rest:allow_missing_post","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#allow_missing_post"},{"n":"cowboy_rest:options","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#options"},{"n":"cowboy_rest:multiple_choices","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#multiple_choices"},{"n":"cowboy_rest:language","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#language"},{"n":"cowboy_rest:allowed_methods","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#allowed_methods"},{"n":"cowboy_rest:malformed_request","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#malformed_request"},{"n":"cowboy_rest:known_methods","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#known_methods"},{"n":"cowboy_rest:Callback","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#callback"},{"n":"cowboy_rest:delete_resource","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#delete_resource"},{"n":"cowboy_rest:service_available","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#service_available"},{"n":"cowboy_rest:is_authorized","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#is_authorized"},{"n":"cowboy_rest:variances","l":"/docs/en/cowboy/HEAD/manual/cowboy_rest/index.html#variances"},{"n":"cowboy_router:routes","l":"/docs/en/cowboy/HEAD/manual/cowboy_router/index.html#routes"},{"n":"cowboy_router:tokens","l":"/docs/en/cowboy/HEAD/manual/cowboy_router/index.html#tokens"},{"n":"cowboy_router:bindings","l":"/docs/en/cowboy/HEAD/manual/cowboy_router/index.html#bindings"},{"n":"cowboy_router:compile","l":"/docs/en/cowboy/HEAD/manual/cowboy_router/index.html#compile"},{"n":"cowboy_router:dispatch_rules","l":"/docs/en/cowboy/HEAD/manual/cowboy_router/index.html#dispatch_rules"},{"n":"cowboy_spdy:middlewares ","l":"/docs/en/cowboy/HEAD/manual/cowboy_spdy/index.html#middlewares "},{"n":"cowboy_spdy:onresponse ","l":"/docs/en/cowboy/HEAD/manual/cowboy_spdy/index.html#onresponse "},{"n":"cowboy_spdy:opts","l":"/docs/en/cowboy/HEAD/manual/cowboy_spdy/index.html#opts"},{"n":"cowboy_spdy:env ","l":"/docs/en/cowboy/HEAD/manual/cowboy_spdy/index.html#env "},{"n":"cowboy_sub_protocol:upgrade","l":"/docs/en/cowboy/HEAD/manual/cowboy_sub_protocol/index.html#upgrade"},{"n":"cowboy_websocket:{remote, Code, Payload}","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#{remote, code, payload}"},{"n":"cowboy_websocket:{error, Reason}","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#{error, reason}"},{"n":"cowboy_websocket:stop","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#stop"},{"n":"cowboy_websocket:timeout","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#timeout"},{"n":"cowboy_websocket:{crash, Class, Reason}","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#{crash, class, reason}"},{"n":"cowboy_websocket:websocket_compress","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#websocket_compress"},{"n":"cowboy_websocket:{error, closed}","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#{error, closed}"},{"n":"cowboy_websocket:websocket_info","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#websocket_info"},{"n":"cowboy_websocket:{error, badframe}","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#{error, badframe}"},{"n":"cowboy_websocket:websocket_version","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#websocket_version"},{"n":"cowboy_websocket:remote","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#remote"},{"n":"cowboy_websocket:normal","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#normal"},{"n":"cowboy_websocket:websocket_handle","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#websocket_handle"},{"n":"cowboy_websocket:{error, badencoding}","l":"/docs/en/cowboy/HEAD/manual/cowboy_websocket/index.html#{error, badencoding}"},{"n":"ranch:start_listener","l":"/docs/en/ranch/1.1/manual/ranch/index.html#start_listener"},{"n":"ranch:set_protocol_options","l":"/docs/en/ranch/1.1/manual/ranch/index.html#set_protocol_options"},{"n":"ranch:set_max_connections","l":"/docs/en/ranch/1.1/manual/ranch/index.html#set_max_connections"},{"n":"ranch:get_protocol_options","l":"/docs/en/ranch/1.1/manual/ranch/index.html#get_protocol_options"},{"n":"ranch:accept_ack","l":"/docs/en/ranch/1.1/manual/ranch/index.html#accept_ack"},{"n":"ranch:remove_connection","l":"/docs/en/ranch/1.1/manual/ranch/index.html#remove_connection"},{"n":"ranch:max_conns","l":"/docs/en/ranch/1.1/manual/ranch/index.html#max_conns"},{"n":"ranch:child_spec","l":"/docs/en/ranch/1.1/manual/ranch/index.html#child_spec"},{"n":"ranch:ref","l":"/docs/en/ranch/1.1/manual/ranch/index.html#ref"},{"n":"ranch:get_max_connections","l":"/docs/en/ranch/1.1/manual/ranch/index.html#get_max_connections"},{"n":"ranch:get_port","l":"/docs/en/ranch/1.1/manual/ranch/index.html#get_port"},{"n":"ranch:stop_listener","l":"/docs/en/ranch/1.1/manual/ranch/index.html#stop_listener"},{"n":"ranch_protocol:start_link","l":"/docs/en/ranch/1.1/manual/ranch_protocol/index.html#start_link"},{"n":"ranch_ssl:opts","l":"/docs/en/ranch/1.1/manual/ranch_ssl/index.html#opts"},{"n":"ranch_tcp:opts","l":"/docs/en/ranch/1.1/manual/ranch_tcp/index.html#opts"},{"n":"ranch_transport:accept_ack","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#accept_ack"},{"n":"ranch_transport:controlling_process","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#controlling_process"},{"n":"ranch_transport:shutdown","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#shutdown"},{"n":"ranch_transport:sendfile_opts","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#sendfile_opts"},{"n":"ranch_transport:sendfile","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#sendfile"},{"n":"ranch_transport:send","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#send"},{"n":"ranch_transport:accept","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#accept"},{"n":"ranch_transport:recv","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#recv"},{"n":"ranch_transport:name","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#name"},{"n":"ranch_transport:close","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#close"},{"n":"ranch_transport:listen","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#listen"},{"n":"ranch_transport:setopts","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#setopts"},{"n":"ranch_transport:peername","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#peername"},{"n":"ranch_transport:messages","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#messages"},{"n":"ranch_transport:sockname","l":"/docs/en/ranch/1.1/manual/ranch_transport/index.html#sockname"},{"n":"ranch:start_listener","l":"/docs/en/ranch/1.0/manual/ranch/index.html#start_listener"},{"n":"ranch:set_protocol_options","l":"/docs/en/ranch/1.0/manual/ranch/index.html#set_protocol_options"},{"n":"ranch:set_max_connections","l":"/docs/en/ranch/1.0/manual/ranch/index.html#set_max_connections"},{"n":"ranch:get_protocol_options","l":"/docs/en/ranch/1.0/manual/ranch/index.html#get_protocol_options"},{"n":"ranch:accept_ack","l":"/docs/en/ranch/1.0/manual/ranch/index.html#accept_ack"},{"n":"ranch:remove_connection","l":"/docs/en/ranch/1.0/manual/ranch/index.html#remove_connection"},{"n":"ranch:max_conns","l":"/docs/en/ranch/1.0/manual/ranch/index.html#max_conns"},{"n":"ranch:child_spec","l":"/docs/en/ranch/1.0/manual/ranch/index.html#child_spec"},{"n":"ranch:ref","l":"/docs/en/ranch/1.0/manual/ranch/index.html#ref"},{"n":"ranch:get_max_connections","l":"/docs/en/ranch/1.0/manual/ranch/index.html#get_max_connections"},{"n":"ranch:get_port","l":"/docs/en/ranch/1.0/manual/ranch/index.html#get_port"},{"n":"ranch:stop_listener","l":"/docs/en/ranch/1.0/manual/ranch/index.html#stop_listener"},{"n":"ranch_protocol:start_link","l":"/docs/en/ranch/1.0/manual/ranch_protocol/index.html#start_link"},{"n":"ranch_ssl:opts","l":"/docs/en/ranch/1.0/manual/ranch_ssl/index.html#opts"},{"n":"ranch_tcp:opts","l":"/docs/en/ranch/1.0/manual/ranch_tcp/index.html#opts"},{"n":"ranch_transport:accept_ack","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#accept_ack"},{"n":"ranch_transport:controlling_process","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#controlling_process"},{"n":"ranch_transport:shutdown","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#shutdown"},{"n":"ranch_transport:sendfile_opts","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#sendfile_opts"},{"n":"ranch_transport:sendfile","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#sendfile"},{"n":"ranch_transport:send","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#send"},{"n":"ranch_transport:accept","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#accept"},{"n":"ranch_transport:recv","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#recv"},{"n":"ranch_transport:name","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#name"},{"n":"ranch_transport:close","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#close"},{"n":"ranch_transport:listen","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#listen"},{"n":"ranch_transport:setopts","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#setopts"},{"n":"ranch_transport:peername","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#peername"},{"n":"ranch_transport:messages","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#messages"},{"n":"ranch_transport:sockname","l":"/docs/en/ranch/1.0/manual/ranch_transport/index.html#sockname"},{"n":"ranch:start_listener","l":"/docs/en/ranch/HEAD/manual/ranch/index.html#start_listener"},{"n":"ranch:set_protocol_options","l":"/docs/en/ranch/HEAD/manual/ranch/index.html#set_protocol_options"},{"n":"ranch:set_max_connections","l":"/docs/en/ranch/HEAD/manual/ranch/index.html#set_max_connections"},{"n":"ranch:get_protocol_options","l":"/docs/en/ranch/HEAD/manual/ranch/index.html#get_protocol_options"},{"n":"ranch:accept_ack","l":"/docs/en/ranch/HEAD/manual/ranch/index.html#accept_ack"},{"n":"ranch:remove_connection","l":"/docs/en/ranch/HEAD/manual/ranch/index.html#remove_connection"},{"n":"ranch:max_conns","l":"/docs/en/ranch/HEAD/manual/ranch/index.html#max_conns"},{"n":"ranch:child_spec","l":"/docs/en/ranch/HEAD/manual/ranch/index.html#child_spec"},{"n":"ranch:ref","l":"/docs/en/ranch/HEAD/manual/ranch/index.html#ref"},{"n":"ranch:get_max_connections","l":"/docs/en/ranch/HEAD/manual/ranch/index.html#get_max_connections"},{"n":"ranch:get_port","l":"/docs/en/ranch/HEAD/manual/ranch/index.html#get_port"},{"n":"ranch:stop_listener","l":"/docs/en/ranch/HEAD/manual/ranch/index.html#stop_listener"},{"n":"ranch_protocol:start_link","l":"/docs/en/ranch/HEAD/manual/ranch_protocol/index.html#start_link"},{"n":"ranch_ssl:opts","l":"/docs/en/ranch/HEAD/manual/ranch_ssl/index.html#opts"},{"n":"ranch_tcp:opts","l":"/docs/en/ranch/HEAD/manual/ranch_tcp/index.html#opts"},{"n":"ranch_transport:accept_ack","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#accept_ack"},{"n":"ranch_transport:controlling_process","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#controlling_process"},{"n":"ranch_transport:shutdown","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#shutdown"},{"n":"ranch_transport:sendfile_opts","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#sendfile_opts"},{"n":"ranch_transport:sendfile","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#sendfile"},{"n":"ranch_transport:send","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#send"},{"n":"ranch_transport:accept","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#accept"},{"n":"ranch_transport:recv","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#recv"},{"n":"ranch_transport:name","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#name"},{"n":"ranch_transport:close","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#close"},{"n":"ranch_transport:listen","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#listen"},{"n":"ranch_transport:setopts","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#setopts"},{"n":"ranch_transport:peername","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#peername"},{"n":"ranch_transport:messages","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#messages"},{"n":"ranch_transport:sockname","l":"/docs/en/ranch/HEAD/manual/ranch_transport/index.html#sockname"}] \ No newline at end of file diff --git a/_build/static/docs/en/cowboy/1.0/guide/architecture/index.html b/_build/static/docs/en/cowboy/1.0/guide/architecture/index.html new file mode 100644 index 00000000..ad14c180 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/architecture/index.html @@ -0,0 +1,202 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Architecture

+ +

Cowboy is a lightweight HTTP server.

+ +

It is built on top of Ranch. Please see the Ranch guide for more information.

+ +

One process per connection

+ +

It uses only one process per connection. The process where your code runs is the process controlling the socket. Using one process instead of two allows for lower memory usage.

+ +

Because there can be more than one request per connection with the keepalive feature of HTTP/1.1, that means the same process will be used to handle many requests.

+ +

Because of this, you are expected to make sure your process cleans up before terminating the handling of the current request. This may include cleaning up the process dictionary, timers, monitoring and more.

+ +

Binaries

+ +

It uses binaries. Binaries are more efficient than lists for representing strings because they take less memory space. Processing performance can vary depending on the operation. Binaries are known for generally getting a great boost if the code is compiled natively. Please see the HiPE documentation for more details.

+ +

Date header

+ +

Because querying for the current date and time can be expensive, Cowboy generates one Date header value every second, shares it to all other processes, which then simply copy it in the response. This allows compliance with HTTP/1.1 with no actual performance loss.

+ +

Max connections

+ +

By default the maximum number of active connections is set to a generally accepted big enough number. This is meant to prevent having too many processes performing potentially heavy work and slowing everything else down, or taking up all the memory.

+ +

Disabling this feature, by setting the {max_connections, infinity} protocol option, would give you greater performance when you are only processing short-lived requests.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/broken_clients/index.html b/_build/static/docs/en/cowboy/1.0/guide/broken_clients/index.html new file mode 100644 index 00000000..d0046439 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/broken_clients/index.html @@ -0,0 +1,212 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Dealing with broken clients

+ +

There exists a very large number of implementations for the HTTP protocol. Most widely used clients, like browsers, follow the standard quite well, but others may not. In particular custom enterprise clients tend to be very badly written.

+ +

Cowboy tries to follow the standard as much as possible, but is not trying to handle every possible special cases. Instead Cowboy focuses on the cases reported in the wild, on the public Web.

+ +

That means clients that ignore the HTTP standard completely may fail to understand Cowboy's responses. There are of course workarounds. This chapter aims to cover them.

+ +

Lowercase headers

+ +

Cowboy converts all headers it receives to lowercase, and similarly sends back headers all in lowercase. Some broken HTTP clients have issues with that.

+ +

A simple way to solve this is to create an onresponse hook that will format the header names with the expected case.

+ + + +

Note that SPDY clients do not have that particular issue because the specification explicitly says all headers are lowercase, unlike HTTP which allows any case but treats them as case insensitive.

+ +

Camel-case headers

+ +

Sometimes it is desirable to keep the actual case used by clients, for example when acting as a proxy between two broken implementations. There is no easy solution for this other than forking the project and editing the cowboy_protocol file directly.

+ +

Chunked transfer-encoding

+ +

Sometimes an HTTP client advertises itself as HTTP/1.1 but does not support chunked transfer-encoding. This is invalid behavior, as HTTP/1.1 clients are required to support it.

+ +

A simple workaround exists in these cases. By changing the Req object response state to waiting_stream, Cowboy will understand that it must use the identity transfer-encoding when replying, just like if it was an HTTP/1.0 client.

+ + + + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/cookies/index.html b/_build/static/docs/en/cowboy/1.0/guide/cookies/index.html new file mode 100644 index 00000000..fd9e0519 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/cookies/index.html @@ -0,0 +1,273 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Using cookies

+ +

Cookies are a mechanism allowing applications to maintain state on top of the stateless HTTP protocol.

+ +

Cowboy provides facilities for handling cookies. It is highly recommended to use them instead of writing your own, as the implementation of cookies can vary greatly between clients.

+ +

Cookies are stored client-side and sent with every subsequent request that matches the domain and path for which they were stored, including requests for static files. For this reason they can incur a cost which must be taken in consideration.

+ +

Also consider that, regardless of the options used, cookies are not to be trusted. They may be read and modified by any program on the user's computer, but also by proxies. You should always validate cookie values before using them. Do not store any sensitive information in cookies either.

+ +

When explicitly setting the domain, the cookie will be sent for the domain and all subdomains from that domain. Otherwise the current domain will be used. The same is true for the path.

+ +

When the server sets cookies, they will only be available for requests that are sent after the client receives the response.

+ +

Cookies are sent in HTTP headers, therefore they must have text values. It is your responsibility to encode any other data type. Also note that cookie names are de facto case sensitive.

+ +

Cookies can be set for the client session (which generally means until the browser is closed), or it can be set for a number of seconds. Once it expires, or when the server says the cookie must exist for up to 0 seconds, the cookie is deleted by the client. To avoid this while the user is browsing your site, you should set the cookie for every request, essentially resetting the expiration time.

+ +

Cookies can be restricted to secure channels. This typically means that such a cookie will only be sent over HTTPS, and that it will only be available by client-side scripts that run from HTTPS webpages.

+ +

Finally, cookies can be restricted to HTTP and HTTPS requests, essentially disabling their access from client-side scripts.

+ +

Setting cookies

+ +

By default, cookies you set are defined for the session.

+ + + +

You can also make them expire at a specific point in the future.

+ + + +

You can delete cookies that have already been set. The value is ignored.

+ + + +

You can restrict them to a specific domain and path. For example, the following cookie will be set for the domain my.example.org and all its subdomains, but only on the path /account and all its subdirectories.

+ + + +

You can restrict the cookie to secure channels, typically HTTPS.

+ + + +

You can restrict the cookie to client-server communication only. Such a cookie will not be available to client-side scripts.

+ + + +

Cookies may also be set client-side, for example using Javascript.

+ +

Reading cookies

+ +

As we said, the client sends cookies with every request. But unlike the server, the client only sends the cookie name and value.

+ +

You can read the value of a cookie.

+ + + +

You can also get a default value returned when the cookie isn't set.

+ + + +

And you can obtain all cookies at once as a list of key/value tuples.

+ + + + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/erlang_beginners/index.html b/_build/static/docs/en/cowboy/1.0/guide/erlang_beginners/index.html new file mode 100644 index 00000000..b57aaf94 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/erlang_beginners/index.html @@ -0,0 +1,196 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Erlang for beginners

+ +

Chances are you are interested in using Cowboy, but have no idea how to write an Erlang program. Fear not! This chapter will help you get started.

+ +

We recommend two books for beginners. You should read them both at some point, as they cover Erlang from two entirely different perspectives.

+ +

Learn You Some Erlang for Great Good!

+ +

The quickest way to get started with Erlang is by reading a book with the funny name of LYSE, as we affectionately call it.

+ +

It will get right into the syntax and quickly answer the questions a beginner would ask themselves, all the while showing funny pictures and making insightful jokes.

+ +

You can read an early version of the book online for free, but you really should buy the much more refined paper and ebook versions.

+ +

Programming Erlang

+ +

After writing some code, you will probably want to understand the very concepts that make Erlang what it is today. These are best explained by Joe Armstrong, the godfather of Erlang, in his book Programming Erlang.

+ +

Instead of going into every single details of the language, Joe focuses on the central concepts behind Erlang, and shows you how they can be used to write a variety of different applications.

+ +

At the time of writing, the 2nd edition of the book is in beta, and includes a few details about upcoming Erlang features that cannot be used today. Choose the edition you want, then get reading!

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/erlang_web/index.html b/_build/static/docs/en/cowboy/1.0/guide/erlang_web/index.html new file mode 100644 index 00000000..96ba79b1 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/erlang_web/index.html @@ -0,0 +1,248 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Erlang and the Web

+ +

The Web is concurrent

+ +

When you access a website there is little concurrency involved. A few connections are opened and requests are sent through these connections. Then the web page is displayed on your screen. Your browser will only open up to 4 or 8 connections to the server, depending on your settings. This isn't much.

+ +

But think about it. You are not the only one accessing the server at the same time. There can be hundreds, if not thousands, if not millions of connections to the same server at the same time.

+ +

Even today a lot of systems used in production haven't solved the C10K problem (ten thousand concurrent connections). And the ones who did are trying hard to get to the next step, C100K, and are pretty far from it.

+ +

Erlang meanwhile has no problem handling millions of connections. At the time of writing there are application servers written in Erlang that can handle more than two million connections on a single server in a real production application, with spare memory and CPU!

+ +

The Web is concurrent, and Erlang is a language designed for concurrency, so it is a perfect match.

+ +

Of course, various platforms need to scale beyond a few million connections. This is where Erlang's built-in distribution mechanisms come in. If one server isn't enough, add more! Erlang allows you to use the same code for talking to local processes or to processes in other parts of your cluster, which means you can scale very quickly if the need arises.

+ +

The Web has large userbases, and the Erlang platform was designed to work in a distributed setting, so it is a perfect match.

+ +

Or is it? Surely you can find solutions to handle that many concurrent connections with your favorite language... But all these solutions will break down in the next few years. Why? Firstly because servers don't get any more powerful, they instead get a lot more cores and memory. This is only useful if your application can use them properly, and Erlang is light-years away from anything else in that area. Secondly, today your computer and your phone are online, tomorrow your watch, goggles, bike, car, fridge and tons of other devices will also connect to various applications on the Internet.

+ +

Only Erlang is prepared to deal with what's coming.

+ +

The Web is soft real time

+ +

What does soft real time mean, you ask? It means we want the operations done as quickly as possible, and in the case of web applications, it means we want the data propagated fast.

+ +

In comparison, hard real time has a similar meaning, but also has a hard time constraint, for example an operation needs to be done in under N milliseconds otherwise the system fails entirely.

+ +

Users aren't that needy yet, they just want to get access to their content in a reasonable delay, and they want the actions they make to register at most a few seconds after they submitted them, otherwise they'll start worrying about whether it successfully went through.

+ +

The Web is soft real time because taking longer to perform an operation would be seen as bad quality of service.

+ +

Erlang is a soft real time system. It will always run processes fairly, a little at a time, switching to another process after a while and preventing a single process to steal resources from all others. This means that Erlang can guarantee stable low latency of operations.

+ +

Erlang provides the guarantees that the soft real time Web requires.

+ +

The Web is asynchronous

+ +

Long ago, the Web was synchronous because HTTP was synchronous. You fired a request, and then waited for a response. Not anymore. It all began when XmlHttpRequest started being used. It allowed the client to perform asynchronous calls to the server.

+ +

Then Websocket appeared and allowed both the server and the client to send data to the other endpoint completely asynchronously. The data is contained within frames and no response is necessary.

+ +

Erlang processes work the same. They send each other data contained within messages and then continue running without needing a response. They tend to spend most of their time inactive, waiting for a new message, and the Erlang VM happily activate them when one is received.

+ +

It is therefore quite easy to imagine Erlang being good at receiving Websocket frames, which may come in at unpredictable times, pass the data to the responsible processes which are always ready waiting for new messages, and perform the operations required by only activating the required parts of the system.

+ +

The more recent Web technologies, like Websocket of course, but also SPDY and HTTP/2.0, are all fully asynchronous protocols. The concept of requests and responses is retained of course, but anything could be sent in between, by both the client or the browser, and the responses could also be received in a completely different order.

+ +

Erlang is by nature asynchronous and really good at it thanks to the great engineering that has been done in the VM over the years. It's only natural that it's so good at dealing with the asynchronous Web.

+ +

The Web is omnipresent

+ +

The Web has taken a very important part of our lives. We're connected at all times, when we're on our phone, using our computer, passing time using a tablet while in the bathroom... And this isn't going to slow down, every single device at home or on us will be connected.

+ +

All these devices are always connected. And with the number of alternatives to give you access to the content you seek, users tend to not stick around when problems arise. Users today want their applications to be always available and if it's having too many issues they just move on.

+ +

Despite this, when developers choose a product to use for building web applications, their only concern seem to be "Is it fast?", and they look around for synthetic benchmarks showing which one is the fastest at sending "Hello world" with only a handful concurrent connections. Web benchmarks haven't been representative of reality in a long time, and are drifting further away as time goes on.

+ +

What developers should really ask themselves is "Can I service all my users with no interruption?" and they'd find that they have two choices. They can either hope for the best, or they can use Erlang.

+ +

Erlang is built for fault tolerance. When writing code in any other language, you have to check all the return values and act accordingly to avoid any unforeseen issues. If you're lucky, you won't miss anything important. When writing Erlang code, you can just check the success condition and ignore all errors. If an error happen, the Erlang process crashes and is then restarted by a special process called a supervisor.

+ +

The Erlang developer thus has no need to fear about unhandled errors, and can focus on handling only the errors that should give some feedback to the user and let the system take care of the rest. This also has the advantage of allowing him to write a lot less code, and letting him sleep at night.

+ +

Erlang's fault tolerance oriented design is the first piece of what makes it the best choice for the omnipresent, always available Web.

+ +

The second piece is Erlang's built-in distribution. Distribution is a key part of building a fault tolerant system, because it allows you to handle bigger failures, like a whole server going down, or even a data center entirely.

+ +

Fault tolerance and distribution are important today, and will be vital in the future of the Web. Erlang is ready.

+ +

Erlang is the ideal platform for the Web

+ +

Erlang provides all the important features that the Web requires or will require in the near future. Erlang is a perfect match for the Web, and it only makes sense to use it to build web applications.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/getting_started/index.html b/_build/static/docs/en/cowboy/1.0/guide/getting_started/index.html new file mode 100644 index 00000000..810fd358 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/getting_started/index.html @@ -0,0 +1,299 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Getting started

+ +

Erlang is more than a language, it is also an operating system for your applications. Erlang developers rarely write standalone modules, they write libraries or applications, and then bundle those into what is called a release. A release contains the Erlang VM plus all applications required to run the node, so it can be pushed to production directly.

+ +

This chapter walks you through all the steps of setting up Cowboy, writing your first application and generating your first release. At the end of this chapter you should know everything you need to push your first Cowboy application to production.

+ +

Bootstrap

+ +

We are going to use the erlang.mk build system. It also offers bootstrap features allowing us to quickly get started without having to deal with minute details.

+ +

First, let's create the directory for our application.

+ + + +

Then we need to download erlang.mk. Either use the following command or download it manually.

+ + + +

We can now bootstrap our application. Since we are going to generate a release, we will also bootstrap it at the same time.

+ + + +

This creates a Makefile, a base application, and the release files necessary for creating the release. We can already build and start this release.

+ + + +

Entering the command i(). will show the running processes, including one called hello_erlang_sup. This is the supervisor for our application.

+ +

The release currently does nothing. In the rest of this chapter we will add Cowboy as a dependency and write a simple "Hello world!" handler.

+ +

Cowboy setup

+ +

To add Cowboy as a dependency to your application, you need to modify two files: the Makefile and the application resource file.

+ +

Modifying the Makefile allows the build system to know it needs to fetch and compile Cowboy. To do that we simply need to add one line to our Makefile to make it look like this:

+ + + +

Modifying the application resource file, src/hello_erlang.app.src, allows the build system to know it needs to include Cowboy in the release and start it automatically. This is a different step because some dependencies are only needed during development.

+ +

We are simply going to add cowboy to the list of applications, right after stdlib. Don't forget the comma separator.

+ + + +

You may want to set a description for the application while you are editing the file.

+ +

If you run make now and start the release, Cowboy will be included and started automatically. This is not enough however, as Cowboy doesn't do anything by default. We still need to tell Cowboy to listen for connections.

+ +

Listening for connections

+ +

We will do this when our application starts. It's a two step process. First we need to define and compile the dispatch list, a list of routes that Cowboy will use to map requests to handler modules. Then we tell Cowboy to listen for connections.

+ +

Open the src/hello_erlang_app.erl file and add the necessary code to the start/2 function to make it look like this:

+ + + +

The dispatch list is explained in great details in the Routing chapter. For this tutorial we map the path / to the handler module hello_handler. This module doesn't exist yet, we still have to write it.

+ +

If you build the release, start it and open http://localhost:8080 now, you will get an error because the module is missing. Any other URL, like http://localhost:8080/test, will result in a 404 error.

+ +

Handling requests

+ +

Cowboy features different kinds of handlers, including REST and Websocket handlers. For this tutorial we will use a plain HTTP handler.

+ +

First, let's generate a handler from a template.

+ + + +

You can then open the src/hello_handler.erl file and modify the handle/2 function like this to send a reply.

+ + + +

What the above code does is send a 200 OK reply, with the content-type header set to text/plain and the response body set to Hello Erlang!.

+ +

If you build the release, start it and open http://localhost:8080 in your browser, you should get a nice Hello Erlang! displayed!

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/hooks/index.html b/_build/static/docs/en/cowboy/1.0/guide/hooks/index.html new file mode 100644 index 00000000..13079057 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/hooks/index.html @@ -0,0 +1,239 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Hooks

+ +

Cowboy provides two hooks. onrequest is called once the request line and headers have been received. onresponse is called just before sending the response.

+ +

Onrequest

+ +

The onrequest hook is called as soon as Cowboy finishes fetching the request headers. It occurs before any other processing, including routing. It can be used to perform any modification needed on the request object before continuing with the processing. If a reply is sent inside this hook, then Cowboy will move on to the next request, skipping any subsequent handling.

+ +

This hook is a function that takes a request object as argument, and returns a request object. This function MUST NOT crash. Cowboy will not send any reply if a crash occurs in this function.

+ +

You can specify the onrequest hook when creating the listener, inside the request options.

+ + + +

The following hook function prints the request object everytime a request is received. This can be useful for debugging, for example.

+ + + +

Make sure to always return the last request object obtained.

+ +

Onresponse

+ +

The onresponse hook is called right before sending the response to the socket. It can be used for the purposes of logging responses, or for modifying the response headers or body. The best example is providing custom error pages.

+ +

Note that like the onrequest hook, this function MUST NOT crash. Cowboy may or may not send a reply if this function crashes. If a reply is sent, the hook MUST explicitly provide all headers that are needed.

+ +

You can specify the onresponse hook when creating the listener.

+ + + +

The following hook function will provide a custom body for 404 errors when it has not been provided before, and will let Cowboy proceed with the default response otherwise.

+ + + +

Again, make sure to always return the last request object obtained.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/http_handlers/index.html b/_build/static/docs/en/cowboy/1.0/guide/http_handlers/index.html new file mode 100644 index 00000000..31a6c135 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/http_handlers/index.html @@ -0,0 +1,279 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Handling plain HTTP requests

+ +

The simplest way to handle a request is by writing a plain HTTP handler. It is modeled after Erlang/OTP's gen_server behaviour, although simplified, as Cowboy will simply call the three callbacks sequentially.

+ +

Initialization

+ +

The first callback, init/3, is common to all handlers, as it is used to identify the type of handler. Plain HTTP handlers just return ok.

+ + + +

This function receives the name of the transport and protocol modules used for processing the request. They can be used to quickly dismiss requests. For example the following handler will crash when accessed using TCP instead of SSL.

+ + + +

This function also receives the options associated with this route that you configured previously. If your handler does not use options, then it is recommended you match the value [] directly to quickly detect configuration errors.

+ + + +

You do not need to validate the options unless they are user configured. If they are, and there's a configuration error, you may choose to crash. For example, this will crash if the required lang option is not found.

+ + + +

If your users are unlikely to figure out the issue without explanations, then you should send a more meaningful error back to the user. Since we already replied to the user, there's no need for us to continue with the handler code, so we use the shutdown return value to stop early.

+ + + +

Once the options have been validated, we can use them safely. So we need to pass them onward to the rest of the handler. That's what the third element of the return tuple, the state, is for.

+ +

We recommend that you create a state record for this. The record will make your handler code clearer and will allow you to better use Dialyzer for type checking.

+ + + +

Handling the request

+ +

The second callback, handle/2, is specific to plain HTTP handlers. It's where you, wait for it, handle the request.

+ +

A handle function that does nothing would look like this:

+ + + +

There's no other return value. To obtain information about the request, or send a response, you would use the Req object here. The Req object is documented in its own chapter.

+ +

The following handle function will send a fairly original response.

+ + + +

Cleaning up

+ +

The third and last callback, terminate/3, will most likely be empty in your handler.

+ + + +

This callback is strictly reserved for any required cleanup. You cannot send a response from this function. There is no other return value.

+ +

If you used the process dictionary, timers, monitors or may be receiving messages, then you can use this function to clean them up, as Cowboy might reuse the process for the next keep-alive request.

+ +

The chances of any of this happening in your handler are pretty thin however. The use of the process dictionary is discouraged in Erlang code in general. And if you need to use timers, monitors or to receive messages, you are better off with a loop handler, a different kind of handler meant specifically for this use.

+ +

This function is still available should you need it. It will always be called.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/http_req_life/index.html b/_build/static/docs/en/cowboy/1.0/guide/http_req_life/index.html new file mode 100644 index 00000000..90d5d466 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/http_req_life/index.html @@ -0,0 +1,251 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

The life of a request

+ +

This chapter explains the different steps a request goes through until a response is sent, along with details of the Cowboy implementation.

+ +

Request/response

+ +

As you already know, HTTP clients connect to the server and send a request for a resource; the server then sends a response containing the resource if it could obtain it.

+ +

Before the server can send the resource, however, it needs to perform many different operations to read the request, find the resource, prepare the response being sent and often other related operations the user can add like writing logs.

+ +

Requests take the following route in Cowboy:

+ +

+ +

This shows the default middlewares, but they may be configured differently in your setup. The dark green indicates the points where you can hook your own code, the light green is the Cowboy code that you can of course configure as needed.

+ +

The acceptor is the part of the server that accepts the connection and create an Erlang process to handle it. The parser then starts reading from the socket and handling requests as they come until the socket is closed.

+ +

A response may be sent at many different points in the life of the request. If Cowboy can't parse the request, it gives up with an error response. If the router can't find the resource, it sends a not found error. Your own code can of course send a response at any time.

+ +

When a response is sent, you can optionally modify it or act upon it by enabling the onresponse hook. By default the response is sent directly to the client.

+ +

And then?

+ +

Behavior depends on what protocol is in use.

+ +

HTTP/1.0 can only process one request per connection, so Cowboy will close the connection immediately after it sends the response.

+ +

HTTP/1.1 allows the client to request that the server keeps the connection alive. This mechanism is described in the next section.

+ +

SPDY is designed to allow sending multiple requests asynchronously on the same connection. Details on what this means for your application is described in this chapter.

+ +

Keep-alive (HTTP/1.1)

+ +

With HTTP/1.1, the connection may be left open for subsequent requests to come. This mechanism is called keep-alive.

+ +

When the client sends a request to the server, it includes a header indicating whether it would like to leave the socket open. The server may or may not accept, indicating its choice by sending the same header in the response.

+ +

Cowboy will include this header automatically in all responses to HTTP/1.1 requests. You can however force the closing of the socket if you want. When Cowboy sees you want to send a connection: close header, it will not override it and will close the connection as soon as the reply is sent.

+ +

This snippet will force Cowboy to close the connection.

+ + + +

Cowboy will only accept a certain number of new requests on the same connection. By default it will run up to 100 requests. This number can be changed by setting the max_keepalive configuration value when starting an HTTP listener.

+ + + +

Cowboy implements the keep-alive mechanism by reusing the same process for all requests. This allows Cowboy to save memory. This works well because most code will not have any side effect impacting subsequent requests. But it also means you need to clean up if you do have code with side effects. The terminate/3 function can be used for this purpose.

+ +

Pipelining (HTTP/1.1)

+ +

While HTTP is designed as a sequential protocol, with the client sending a request and then waiting for the response from the server, nothing prevents the client from sending more requests to the server without waiting for the response, due to how sockets work. The server still handles the requests sequentially and sends the responses in the same order.

+ +

This mechanism is called pipelining. It allows reducing latency when a client needs to request many resources at the same time. This is used by browsers when requesting static files for example.

+ +

This is handled automatically by the server.

+ +

Asynchronous requests (SPDY)

+ +

In SPDY, the client can send a request at any time. And the server can send a response at any time too.

+ +

This means for example that the client does not need to wait for a request to be fully sent to send another, it is possible to interleave a request with the request body of another request. The same is true with responses. Responses may also be sent in a different order.

+ +

Because requests and responses are fully asynchronous, Cowboy creates a new process for each request, and these processes are managed by another process that handles the connection itself.

+ +

SPDY servers may also decide to send resources to the client before the client requests them. This is especially useful for sending static files associated with the HTML page requested, as this reduces the latency of the overall response. Cowboy does not support this particular mechanism at this point, however.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/http_req_resp.png b/_build/static/docs/en/cowboy/1.0/guide/http_req_resp.png new file mode 100644 index 00000000..e38935f3 Binary files /dev/null and b/_build/static/docs/en/cowboy/1.0/guide/http_req_resp.png differ diff --git a/_build/static/docs/en/cowboy/1.0/guide/http_req_resp.svg b/_build/static/docs/en/cowboy/1.0/guide/http_req_resp.svg new file mode 100644 index 00000000..0cfa0ae9 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/http_req_resp.svg @@ -0,0 +1,558 @@ + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + some text + acceptor + parser + router + some text + onrequest + handler + middlewares + some text + client + + + + + reply + onresponse + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/index.html b/_build/static/docs/en/cowboy/1.0/guide/index.html new file mode 100644 index 00000000..f03e8f67 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/index.html @@ -0,0 +1,250 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Cowboy User Guide

+ +

The Cowboy User Guide explores the modern Web and how to make best use of Cowboy for writing powerful web applications.

+ +

Introducing Cowboy

+ + + +

HTTP

+ + + +

Multipart

+ + + +

Static files

+ + + +

REST

+ + + +

Websocket

+ + + +

Server push

+ + + +

Pluggable interface

+ + + +

Internals

+ + + + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/introduction/index.html b/_build/static/docs/en/cowboy/1.0/guide/introduction/index.html new file mode 100644 index 00000000..fa7f48f5 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/introduction/index.html @@ -0,0 +1,212 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Introduction

+ +

Cowboy is a small, fast and modular HTTP server written in Erlang.

+ +

Cowboy aims to provide a complete HTTP stack, including its derivatives SPDY, Websocket and REST. Cowboy currently supports HTTP/1.0, HTTP/1.1, Websocket (all implemented drafts + standard) and Webmachine-based REST.

+ +

Cowboy is a high quality project. It has a small code base, is very efficient (both in latency and memory use) and can easily be embedded in another application.

+ +

Cowboy is clean Erlang code. It includes hundreds of tests and its code is fully compliant with the Dialyzer. It is also well documented and features both a Function Reference and a User Guide.

+ +

Prerequisites

+ +

No Erlang knowledge is required for reading this guide. The reader will be introduced to Erlang concepts and redirected to reference material whenever necessary.

+ +

Knowledge of the HTTP protocol is recommended but not required, as it will be detailed throughout the guide.

+ +

Supported platforms

+ +

Cowboy is tested and supported on Linux.

+ +

Cowboy has been reported to work on other platforms, but we make no guarantee that the experience will be safe and smooth. You are advised to perform the necessary testing and security audits prior to deploying on other platforms.

+ +

Cowboy is developed for Erlang/OTP R16B01, R16B02, R16B03-1, 17.0 and 17.1.2.

+ +

Cowboy may be compiled on other Erlang versions with small source code modifications but there is no guarantee that it will work as expected.

+ +

Versioning

+ +

Cowboy uses Semantic Versioning 2.0.0.

+ +

Conventions

+ +

In the HTTP protocol, the method name is case sensitive. All standard method names are uppercase.

+ +

Header names are case insensitive. Cowboy converts all the request header names to lowercase, and expects your application to provide lowercase header names in the response.

+ +

The same applies to any other case insensitive value.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/loop_handlers/index.html b/_build/static/docs/en/cowboy/1.0/guide/loop_handlers/index.html new file mode 100644 index 00000000..d9d1bb30 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/loop_handlers/index.html @@ -0,0 +1,264 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Loop handlers

+ +

Loop handlers are a special kind of HTTP handlers used when the response can not be sent right away. The handler enters instead a receive loop waiting for the right message before it can send a response.

+ +

Loop handlers are used for requests where a response might not be immediately available, but where you would like to keep the connection open for a while in case the response arrives. The most known example of such practice is known as long-polling.

+ +

Loop handlers can also be used for requests where a response is partially available and you need to stream the response body while the connection is open. The most known example of such practice is known as server-sent events.

+ +

While the same can be accomplished using plain HTTP handlers, it is recommended to use loop handlers because they are well-tested and allow using built-in features like hibernation and timeouts.

+ +

Loop handlers essentially wait for one or more Erlang messages and feed these messages to the info/3 callback. It also features the init/3 and terminate/3 callbacks which work the same as for plain HTTP handlers.

+ +

Initialization

+ +

The init/3 function must return a loop tuple to enable loop handler behavior. This tuple may optionally contain a timeout value and/or the atom hibernate to make the process enter hibernation until a message is received.

+ +

This snippet enables the loop handler.

+ + + +

However it is largely recommended that you set a timeout value. The next example sets a timeout value of 30s and also makes the process hibernate.

+ + + +

Receive loop

+ +

Once initialized, Cowboy will wait for messages to arrive in the process' mailbox. When a message arrives, Cowboy calls the info/3 function with the message, the Req object and the handler's state.

+ +

The following snippet sends a reply when it receives a reply message from another process, or waits for another message otherwise.

+ + + +

Do note that the reply tuple here may be any message and is simply an example.

+ +

This callback may perform any necessary operation including sending all or parts of a reply, and will subsequently return a tuple indicating if more messages are to be expected.

+ +

The callback may also choose to do nothing at all and just skip the message received.

+ +

If a reply is sent, then the ok tuple should be returned. This will instruct Cowboy to end the request.

+ +

Otherwise a loop tuple should be returned.

+ +

Streaming loop

+ +

Another common case well suited for loop handlers is streaming data received in the form of Erlang messages. This can be done by initiating a chunked reply in the init/3 callback and then using cowboy_req:chunk/2 every time a message is received.

+ +

The following snippet does exactly that. As you can see a chunk is sent every time a chunk message is received, and the loop is stopped by sending an eof message.

+ + + +

Cleaning up

+ +

It is recommended that you set the connection header to close when replying, as this process may be reused for a subsequent request.

+ +

Please refer to the HTTP handlers chapter for general instructions about cleaning up.

+ +

Timeout

+ +

By default Cowboy will not attempt to close the connection if there is no activity from the client. This is not always desirable, which is why you can set a timeout. Cowboy will close the connection if no data was received from the client after the configured time. The timeout only needs to be set once and can't be modified afterwards.

+ +

Because the request may have had a body, or may be followed by another request, Cowboy is forced to buffer all data it receives. This data may grow to become too large though, so there is a configurable limit for it. The default buffer size is of 5000 bytes, but it may be changed by setting the loop_max_buffer middleware environment value.

+ +

Hibernate

+ +

To save memory, you may hibernate the process in between messages received. This is done by returning the atom hibernate as part of the loop tuple callbacks normally return. Just add the atom at the end and Cowboy will hibernate accordingly.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/middlewares/index.html b/_build/static/docs/en/cowboy/1.0/guide/middlewares/index.html new file mode 100644 index 00000000..42410512 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/middlewares/index.html @@ -0,0 +1,226 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Middlewares

+ +

Cowboy delegates the request processing to middleware components. By default, two middlewares are defined, for the routing and handling of the request, as is detailed in most of this guide.

+ +

Middlewares give you complete control over how requests are to be processed. You can add your own middlewares to the mix or completely change the chain of middlewares as needed.

+ +

Cowboy will execute all middlewares in the given order, unless one of them decides to stop processing.

+ +

Usage

+ +

Middlewares only need to implement a single callback: execute/2. It is defined in the cowboy_middleware behavior.

+ +

This callback has two arguments. The first is the Req object. The second is the environment.

+ +

Middlewares can return one of four different values:

+ +
    +
  • {ok, Req, Env} to continue the request processing
    • +
  • {suspend, Module, Function, Args} to hibernate
    • +
  • {halt, Req} to stop processing and move on to the next request
    • +
  • {error, StatusCode, Req} to reply an error and close the socket
    • +
+ +

Of note is that when hibernating, processing will resume on the given MFA, discarding all previous stacktrace. Make sure you keep the Req and Env in the arguments of this MFA for later use.

+ +

If an error happens during middleware processing, Cowboy will not try to send an error back to the socket, the process will just crash. It is up to the middleware to make sure that a reply is sent if something goes wrong.

+ +

Configuration

+ +

The middleware environment is defined as the env protocol option. In the previous chapters we saw it briefly when we needed to pass the routing information. It is a list of tuples with the first element being an atom and the second any Erlang term.

+ +

Two values in the environment are reserved:

+ +
    +
  • listener contains the name of the listener
    • +
  • result contains the result of the processing
    • +
+ +

The listener value is always defined. The result value can be set by any middleware. If set to anything other than ok, Cowboy will not process any subsequent requests on this connection.

+ +

The middlewares that come with Cowboy may define or require other environment values to perform.

+ +

You can update the environment by calling the cowboy:set_env/3 convenience function, adding or replacing a value in the environment.

+ +

Routing middleware

+ +

The routing middleware requires the dispatch value. If routing succeeds, it will put the handler name and options in the handler and handler_opts values of the environment, respectively.

+ +

Handler middleware

+ +

The handler middleware requires the handler and handler_opts values. It puts the result of the request handling into result.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/modern_web/index.html b/_build/static/docs/en/cowboy/1.0/guide/modern_web/index.html new file mode 100644 index 00000000..1aaba0a0 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/modern_web/index.html @@ -0,0 +1,282 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

The modern Web

+ +

Let's take a look at various technologies from the beginnings of the Web up to this day, and get a preview of what's coming next.

+ +

Cowboy is compatible with all the technology cited in this chapter except of course HTTP/2.0 which has no implementation in the wild at the time of writing.

+ +

The prehistoric Web

+ +

HTTP was initially created to serve HTML pages and only had the GET method for retrieving them. This initial version is documented and is sometimes called HTTP/0.9. HTTP/1.0 defined the GET, HEAD and POST methods, and was able to send data with POST requests.

+ +

HTTP/1.0 works in a very simple way. A TCP connection is first established to the server. Then a request is sent. Then the server sends a response back and closes the connection.

+ +

Suffice to say, HTTP/1.0 is not very efficient. Opening a TCP connection takes some time, and pages containing many assets load much slower than they could because of this.

+ +

Most improvements done in recent years focused on reducing this load time and reducing the latency of the requests.

+ +

HTTP/1.1

+ +

HTTP/1.1 quickly followed and added a keep-alive mechanism to allow using the same connection for many requests, as well as streaming capabilities, allowing an endpoint to send a body in well defined chunks.

+ +

HTTP/1.1 defines the OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE and CONNECT methods. The PATCH method was added in more recent years. It also improves the caching capabilities with the introduction of many headers.

+ +

HTTP/1.1 still works like HTTP/1.0 does, except the connection can be kept alive for subsequent requests. This however allows clients to perform what is called as pipelining: sending many requests in a row, and then processing the responses which will be received in the same order as the requests.

+ +

REST

+ +

The design of HTTP/1.1 was influenced by the REST architectural style. REST, or REpresentational State Transfer, is a style of architecture for loosely connected distributed systems.

+ +

REST defines constraints that systems must obey to in order to be RESTful. A system which doesn't follow all the constraints cannot be considered RESTful.

+ +

REST is a client-server architecture with a clean separation of concerns between the client and the server. They communicate by referencing resources. Resources can be identified, but also manipulated. A resource representation has a media type and information about whether it can be cached and how. Hypermedia determines how resources are related and how they can be used. REST is also stateless. All requests contain the complete information necessary to perform the action.

+ +

HTTP/1.1 defines all the methods, headers and semantics required to implement RESTful systems.

+ +

REST is most often used when designing web application APIs which are generally meant to be used by executable code directly.

+ +

XmlHttpRequest

+ +

Also know as AJAX, this technology allows Javascript code running on a web page to perform asynchronous requests to the server. This is what started the move from static websites to dynamic web applications.

+ +

XmlHttpRequest still performs HTTP requests under the hood, and then waits for a response, but the Javascript code can continue to run until the response arrives. It will then receive the response through a callback previously defined.

+ +

This is of course still requests initiated by the client, the server still had no way of pushing data to the client on its own, so new technology appeared to allow that.

+ +

Long-polling

+ +

Polling was a technique used to overcome the fact that the server cannot push data directly to the client. Therefore the client had to repeatedly create a connection, make a request, get a response, then try again a few seconds later. This is overly expensive and adds an additional delay before the client receives the data.

+ +

Polling was necessary to implement message queues and other similar mechanisms, where a user must be informed of something when it happens, rather than when he refreshes the page next. A typical example would be a chat application.

+ +

Long-polling was created to reduce the server load by creating less connections, but also to improve latency by getting the response back to the client as soon as it becomes available on the server.

+ +

Long-polling works in a similar manner to polling, except the request will not get a response immediately. Instead the server leaves it open until it has a response to send. After getting the response, the client creates a new request and gets back to waiting.

+ +

You probably guessed by now that long-polling is a hack, and like most hacks it can suffer from unforeseen issues, in this case it doesn't always play well with proxies.

+ +

HTML5

+ +

HTML5 is, of course, the HTML version after HTML4. But HTML5 emerged to solve a specific problem: dynamic web applications.

+ +

HTML was initially created to write web pages which compose a website. But soon people and companies wanted to use HTML to write more and more complex websites, eventually known as web applications. They are for example your news reader, your email client in the browser, or your video streaming website.

+ +

Because HTML wasn't enough, they started using proprietary solutions, often implemented using plug-ins. This wasn't perfect of course, but worked well enough for most people.

+ +

However, the needs for a standard solution eventually became apparent. The browser needed to be able to play media natively. It needed to be able to draw anything. It needed an efficient way of streaming events to the server, but also receiving events from the server.

+ +

The solution went on to become HTML5. At the time of writing it is being standardized.

+ +

EventSource

+ +

EventSource, sometimes also called Server-Sent Events, is a technology allowing servers to push data to HTML5 applications.

+ +

EventSource is one-way communication channel from the server to the client. The client has no means to talk to the server other than by using HTTP requests.

+ +

It consists of a Javascript object allowing setting up an EventSource connection to the server, and a very small protocol for sending events to the client on top of the HTTP/1.1 connection.

+ +

EventSource is a lightweight solution that only works for UTF-8 encoded text data. Binary data and text data encoded differently are not allowed by the protocol. A heavier but more generic approach can be found in Websocket.

+ +

Websocket

+ +

Websocket is a protocol built on top of HTTP/1.1 that provides a two-ways communication channel between the client and the server. Communication is asynchronous and can occur concurrently.

+ +

It consists of a Javascript object allowing setting up a Websocket connection to the server, and a binary based protocol for sending data to the server or the client.

+ +

Websocket connections can transfer either UTF-8 encoded text data or binary data. The protocol also includes support for implementing a ping/pong mechanism, allowing the server and the client to have more confidence that the connection is still alive.

+ +

A Websocket connection can be used to transfer any kind of data, small or big, text or binary. Because of this Websocket is sometimes used for communication between systems.

+ +

SPDY

+ +

SPDY is an attempt to reduce page loading time by opening a single connection per server, keeping it open for subsequent requests, and also by compressing the HTTP headers to reduce the size of requests.

+ +

SPDY is compatible with HTTP/1.1 semantics, and is actually just a different way of performing HTTP requests and responses, by using binary frames instead of a text-based protocol. SPDY also allows the server to send extra responses following a request. This is meant to allow sending the resources associated with the request before the client requests them, saving latency when loading websites.

+ +

SPDY is an experiment that has proven successful and is used as the basis for the HTTP/2.0 standard.

+ +

Browsers make use of TLS Next Protocol Negotiation to upgrade to a SPDY connection seamlessly if the protocol supports it.

+ +

The protocol itself has a few shortcomings which are being fixed in HTTP/2.0.

+ +

HTTP/2.0

+ +

HTTP/2.0 is the long-awaited update to the HTTP/1.1 protocol. It is based on SPDY although a lot has been improved at the time of writing.

+ +

HTTP/2.0 is an asynchronous two-ways communication channel between two endpoints.

+ +

It is planned to be ready late 2014.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/multipart_intro/index.html b/_build/static/docs/en/cowboy/1.0/guide/multipart_intro/index.html new file mode 100644 index 00000000..3a2f5273 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/multipart_intro/index.html @@ -0,0 +1,198 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Introduction to multipart

+ +

Multipart originates from MIME, an Internet standard that extends the format of emails. Multipart messages are a container for parts of any content-type.

+ +

For example, a multipart message may have a part containing text and a second part containing an image. This is what allows you to attach files to emails.

+ +

In the context of HTTP, multipart is most often used with the multipart/form-data content-type. This is the content-type you have to use when you want browsers to be allowed to upload files through HTML forms.

+ +

Multipart is of course not required for uploading files, it is only required when you want to do so through HTML forms.

+ +

Structure

+ +

A multipart message is a list of parts. Parts may contain either a multipart message or a non-multipart content-type. This allows parts to be arranged in a tree structure, although this is a rare case as far as the Web is concerned.

+ +

Form-data

+ +

In the normal case, when a form is submitted, the browser will use the application/x-www-form-urlencoded content-type. This type is just a list of keys and values and is therefore not fit for uploading files.

+ +

That's where the multipart/form-data content-type comes in. When the form is configured to use this content-type, the browser will use one part of the message for each form field. This means that a file input field will be sent in its own part, but the same applies to all other kinds of fields.

+ +

A form with a text input, a file input and a select choice box will result in a multipart message with three parts, one for each field.

+ +

The browser does its best to determine the content-type of the files it sends this way, but you should not rely on it for determining the contents of the file. Proper investigation of the contents is recommended.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/multipart_req/index.html b/_build/static/docs/en/cowboy/1.0/guide/multipart_req/index.html new file mode 100644 index 00000000..f6301d83 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/multipart_req/index.html @@ -0,0 +1,261 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Multipart requests

+ +

You can read and parse multipart messages using the Req object directly.

+ +

Cowboy defines two functions that allows you to get information about each part and read their contents.

+ +

Checking the content-type

+ +

While there is a variety of multipart messages, the most common on the Web is multipart/form-data. It's the type of message being sent when an HTML form allows uploading files.

+ +

You can quickly figure out if a multipart message has been sent by parsing the content-type header.

+ + + +

Reading a multipart message

+ +

To read a message you have to iterate over all its parts. Then, for each part, you can inspect its headers and read its body.

+ + + +

Parts do not have a size limit. When a part body is too big, Cowboy will return what it read so far and allow you to continue if you wish to do so.

+ +

The function cow_multipart:form_data/1 can be used to quickly obtain information about a part from a multipart/form-data message. This function will tell you if the part is for a normal field or if it is a file being uploaded.

+ +

This can be used for example to allow large part bodies for files but crash when a normal field is too large.

+ + + +

By default the body chunk Cowboy will return is limited to 8MB. This can of course be overriden. Both functions can take a second argument, the same list of options that will be passed to cowboy_req:body/2 function.

+ +

Skipping unwanted parts

+ +

If you do not want to read a part's body, you can skip it. Skipping is easy. If you do not call the function to read the part's body, Cowboy will automatically skip it when you request the next part.

+ +

The following snippet reads all part headers and skips all bodies:

+ + + +

Similarly, if you start reading the body and it ends up being too big, you can simply continue with the next part, Cowboy will automatically skip what remains.

+ +

Note that the skipping rate may not be adequate for your application. If you observe poor performance when skipping, you might want to consider manually skipping by calling the cowboy_req:part_body/1 function directly.

+ +

And if you started reading the message but decide that you do not need the remaining parts, you can simply stop reading entirely and Cowboy will automatically figure out what to do.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/req/index.html b/_build/static/docs/en/cowboy/1.0/guide/req/index.html new file mode 100644 index 00000000..0b8bb586 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/req/index.html @@ -0,0 +1,390 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

The Req object

+ +

The Req object is this variable that you will use to obtain information about a request, read the body of the request and send a response.

+ +

A special variable

+ +

While we call it an "object", it is not an object in the OOP sense of the term. In fact it is completely opaque to you and the only way you can perform operations using it is by calling the functions from the cowboy_req module.

+ +

Almost all the calls to the cowboy_req module will return an updated request object. Just like you would keep the updated State variable in a gen_server, you MUST keep the updated Req variable in a Cowboy handler. Cowboy will use this object to know whether a response has been sent when the handler has finished executing.

+ +

The Req object allows accessing both immutable and mutable state. This means that calling some of the functions twice will not produce the same result. For example, when streaming the request body, the function will return the body by chunks, one at a time, until there is none left.

+ +

It also caches the result of operations performed on the immutable state. That means that some calls will give a result much faster when called many times.

+ +

Overview of the cowboy_req interface

+ +

The cowboy_req interface is divided in four groups of functions, each having a well defined return type signature common to the entire group.

+ +

The first group, access functions, will always return {Value, Req}. The group includes all the following functions: binding/{2,3}, bindings/1, body_length/1, cookie/{2,3}, cookies/1, header/{2,3}, headers/1, host/1, host_info/1, host_url/1, meta/{2,3}, method/1, path/1, path_info/1, peer/1, port/1, qs/1, qs_val/{2,3}, qs_vals/1, url/1, version/1.

+ +

The second group, question functions, will always return a boolean(). The group includes the following three functions: has_body/1, has_resp_body/1, has_resp_header/2.

+ +

The third group contains the functions that manipulate the socket or perform operations that may legitimately fail. They may return {Result, Req}, {Result, Value, Req} or {error, atom()}. This includes the following functions: body/{1,2}, body_qs/{1,2}, chunked_reply/{2,3}, parse_header/{2,3}, part/{1,2}, part_body/{1,2} and reply/{2,3,4}. Finally, the group also includes the chunk/2 and continue/1 functions which always return ok.

+ +

The final group modifies the Req object state without performing any immediate operations. As these functions can't fail, they always return a new Req directly. This includes the following functions: compact/1, delete_resp_header/2, set_meta/3, set_resp_body/2, set_resp_body_fun/{2,3}, set_resp_cookie/4, set_resp_header/3.

+ +

This chapter covers most of the first group, plus a few other functions. The next few chapters cover cookies handling, reading the request body and sending a response.

+ +

Request

+ +

When a client performs a request, it first sends a few required values. They are sent differently depending on the protocol being used, but the intent is the same. They indicate to the server the type of action it wants to do and how to locate the resource to perform it on.

+ +

The method identifies the action. Standard methods include GET, HEAD, OPTIONS, PATCH, POST, PUT, DELETE. Method names are case sensitive.

+ + + +

The host, port and path parts of the URL identify the resource being accessed. The host and port information may not be available if the client uses HTTP/1.0.

+ + + +

The version used by the client can of course also be obtained.

+ + + +

Do note however that clients claiming to implement one version of the protocol does not mean they implement it fully, or even properly.

+ +

Bindings

+ +

After routing the request, bindings are available. Bindings are these parts of the host or path that you chose to extract when defining the routes of your application.

+ +

You can fetch a single binding. The value will be undefined if the binding doesn't exist.

+ + + +

If you need a different value when the binding doesn't exist, you can change the default.

+ + + +

You can also obtain all bindings in one call. They will be returned as a list of key/value tuples.

+ + + +

If you used ... at the beginning of the route's pattern for the host, you can retrieve the matched part of the host. The value will be undefined otherwise.

+ + + +

Similarly, if you used ... at the end of the route's pattern for the path, you can retrieve the matched part, or get undefined otherwise.

+ + + +

Query string

+ +

The query string can be obtained directly.

+ + + +

You can also requests only one value.

+ + + +

If that value is optional, you can define a default to simplify your task.

+ + + +

Finally, you can obtain all query string values.

+ + + +

Request URL

+ +

You can reconstruct the full URL of the resource.

+ + + +

You can also obtain only the base of the URL, excluding the path and query string.

+ + + +

Headers

+ +

Cowboy allows you to obtain the header values as string, or parsed into a more meaningful representation.

+ +

This will get the string value of a header.

+ + + +

You can of course set a default in case the header is missing.

+ + + +

And also obtain all headers.

+ + + +

To parse the previous header, simply call parse_header/{2,3} where you would call header/{2,3} otherwise. Note that the return value changes and includes the result of the operation as the first element of the returned tuple. A successful parse returns ok.

+ + + +

When Cowboy doesn't know how to parse the given header, the result of the operation will be undefined and the string value will be returned instead.

+ + + +

When parsing fails, {error, Reason} is returned instead.

+ +

You can of course define a default value. Note that the default value you specify here is the parsed value you'd like to get by default.

+ + + +

The list of known headers and default values is defined in the manual. Also note that the result of parsing is cached, so calling this function multiple times for the same values will not have a significant performance impact.

+ +

Meta

+ +

Cowboy will sometimes associate some meta information with the request. Built-in meta values are listed in the manual for their respective modules.

+ +

This will get a meta value. The returned value will be undefined if it isn't defined.

+ + + +

You can change the default value if needed.

+ + + +

You can also define your own meta values. The name must be an atom().

+ + + +

Peer

+ +

You can obtain the peer address and port number. This is not necessarily the actual IP and port of the client, but rather the one of the machine that connected to the server.

+ + + +

Reducing the memory footprint

+ +

When you are done reading information from the request object and know you are not going to access it anymore, for example when using long-polling or Websocket, you can use the compact/1 function to remove most of the data from the request object and free memory.

+ + + +

You will still be able to send a reply if needed.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/req_body/index.html b/_build/static/docs/en/cowboy/1.0/guide/req_body/index.html new file mode 100644 index 00000000..b6365a8f --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/req_body/index.html @@ -0,0 +1,296 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Reading the request body

+ +

The Req object also allows you to read the request body.

+ +

Because the request body can be of any size, all body reading operations will only work once, as Cowboy will not cache the result of these operations.

+ +

Cowboy will not attempt to read the body until you do. If handler execution ends without reading it, Cowboy will simply skip it.

+ +

Cowboy provides different ways to read the request body. You can read it directly, stream it, but also read and parse in a single call for form urlencoded formats or multipart. All of these except multipart are covered in this chapter. Multipart is covered later on in the guide.

+ +

Check for request body

+ +

You can check whether a body was sent with the request.

+ + + +

It will return true if there is a request body, and false otherwise.

+ +

Note that it is generally safe to assume that a body is sent for POST, PUT and PATCH requests, without having to explicitly check for it.

+ +

Request body length

+ +

You can obtain the body length if it was sent with the request.

+ + + +

The value returned will be undefined if the length couldn't be figured out from the request headers. If there's a body but no length is given, this means that the chunked transfer-encoding was used. You can read chunked bodies by using the stream functions.

+ +

Reading the body

+ +

You can read the whole body directly in one call.

+ + + +

By default, Cowboy will attempt to read up to a size of 8MB. You can override this limit as needed.

+ + + +

You can also disable it.

+ + + +

It is recommended that you do not disable it for public facing websites.

+ +

If the body is larger than the limit, then Cowboy will return a more tuple instead, allowing you to stream it if you would like to.

+ +

Streaming the body

+ +

You can stream the request body by chunks.

+ +

Cowboy returns a more tuple when there is more body to be read, and an ok tuple for the last chunk. This allows you to loop over all chunks.

+ + + +

You can of course set the length option to configure the size of chunks.

+ +

Rate of data transmission

+ +

You can control the rate of data transmission by setting options when calling body functions. This applies not only to the functions described in this chapter, but also to the multipart functions.

+ +

The read_length option defines the maximum amount of data to be received from the socket at once, in bytes.

+ +

The read_timeout option defines the time Cowboy waits before that amount is received, in milliseconds.

+ +

Transfer and content decoding

+ +

Cowboy will by default decode the chunked transfer-encoding if any. It will not decode any content-encoding by default.

+ +

The first time you call a body function you can set the transfer_decode and content_decode options. If the body was already started being read these options are simply ignored.

+ +

The following example shows how to set both options.

+ + + +

Reading a form urlencoded body

+ +

You can directly obtain a list of key/value pairs if the body was sent using the application/x-www-form-urlencoded content-type.

+ + + +

You can then retrieve an individual value from that list.

+ + + +

You should not attempt to match on the list as the order of the values is undefined.

+ +

By default Cowboy will reject bodies with a size above 64KB when using this function. You can override this limit by setting the length option.

+ + + + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/resource_design/index.html b/_build/static/docs/en/cowboy/1.0/guide/resource_design/index.html new file mode 100644 index 00000000..24977abb --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/resource_design/index.html @@ -0,0 +1,294 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Designing a resource handler

+ +

This chapter aims to provide you with a list of questions you must answer in order to write a good resource handler. It is meant to be usable as a step by step guide.

+ +

The service

+ +

Can the service become unavailable, and when it does, can we detect it? For example database connectivity problems may be detected early. We may also have planned outages of all or parts of the system. Implement the service_available callback.

+ +

What HTTP methods does the service implement? Do we need more than the standard OPTIONS, HEAD, GET, PUT, POST, PATCH and DELETE? Are we not using one of those at all? Implement the known_methods callback.

+ +

Type of resource handler

+ +

Am I writing a handler for a collection of resources, or for a single resource?

+ +

The semantics for each of these are quite different. You should not mix collection and single resource in the same handler.

+ +

Collection handler

+ +

Skip this section if you are not doing a collection.

+ +

Is the collection hardcoded or dynamic? For example if you use the route /users for the collection of users then the collection is hardcoded; if you use /forums/:category for the collection of threads then it isn't. When the collection is hardcoded you can safely assume the resource always exists.

+ +

What methods should I implement?

+ +

OPTIONS is used to get some information about the collection. It is recommended to allow it even if you do not implement it, as Cowboy has a default implementation built-in.

+ +

HEAD and GET are used to retrieve the collection. If you allow GET, also allow HEAD as there's no extra work required to make it work.

+ +

POST is used to create a new resource inside the collection. Creating a resource by using POST on the collection is useful when resources may be created before knowing their URI, usually because parts of it are generated dynamically. A common case is some kind of auto incremented integer identifier.

+ +

The next methods are more rarely allowed.

+ +

PUT is used to create a new collection (when the collection isn't hardcoded), or replace the entire collection.

+ +

DELETE is used to delete the entire collection.

+ +

PATCH is used to modify the collection using instructions given in the request body. A PATCH operation is atomic. The PATCH operation may be used for such things as reordering; adding, modifying or deleting parts of the collection.

+ +

Single resource handler

+ +

Skip this section if you are doing a collection.

+ +

What methods should I implement?

+ +

OPTIONS is used to get some information about the resource. It is recommended to allow it even if you do not implement it, as Cowboy has a default implementation built-in.

+ +

HEAD and GET are used to retrieve the resource. If you allow GET, also allow HEAD as there's no extra work required to make it work.

+ +

POST is used to update the resource.

+ +

PUT is used to create a new resource (when it doesn't already exist) or replace the resource.

+ +

DELETE is used to delete the resource.

+ +

PATCH is used to modify the resource using instructions given in the request body. A PATCH operation is atomic. The PATCH operation may be used for adding, removing or modifying specific values in the resource.

+ +

The resource

+ +

Following the above discussion, implement the allowed_methods callback.

+ +

Does the resource always exist? If it may not, implement the resource_exists callback.

+ +

Do I need to authenticate the client before they can access the resource? What authentication mechanisms should I provide? This may include form-based, token-based (in the URL or a cookie), HTTP basic, HTTP digest, SSL certificate or any other form of authentication. Implement the is_authorized callback.

+ +

Do I need fine-grained access control? How do I determine that they are authorized access? Handle that in your is_authorized callback.

+ +

Can access to a resource be forbidden regardless of access being authorized? A simple example of that is censorship of a resource. Implement the forbidden callback.

+ +

Is there any constraints on the length of the resource URI? For example the URI may be used as a key in storage and may have a limit in length. Implement uri_too_long.

+ +

Representations

+ +

What media types do I provide? If text based, what charsets are provided? What languages do I provide?

+ +

Implement the mandatory content_types_provided. Prefix the callbacks with to_ for clarity. For example to_html or to_text.

+ +

Implement the languages_provided or charsets_provided callbacks if applicable.

+ +

Is there any other header that may make the representation of the resource vary? Implement the variances callback.

+ +

Depending on your choices for caching content, you may want to implement one or more of the generate_etag, last_modified and expires callbacks.

+ +

Do I want the user or user agent to actively choose a representation available? Send a list of available representations in the response body and implement the multiple_choices callback.

+ +

Redirections

+ +

Do I need to keep track of what resources were deleted? For example you may have a mechanism where moving a resource leaves a redirect link to its new location. Implement the previously_existed callback.

+ +

Was the resource moved, and is the move temporary? If it is explicitly temporary, for example due to maintenance, implement the moved_temporarily callback. Otherwise, implement the moved_permanently callback.

+ +

The request

+ +

Do we need to perform extra checks to make sure the request is valid? Cowboy will do many checks when receiving the request already, do we need more? Note that this only applies to the request-line and headers of the request, and not the body. Implement malformed_request.

+ +

May there be a request body? Will I know its size? What's the maximum size of the request body I'm willing to accept? Implement valid_entity_length.

+ +

Finally, take a look at the sections corresponding to the methods you are implementing.

+ +

OPTIONS method

+ +

Cowboy by default will send back a list of allowed methods. Do I need to add more information to the response? Implement the options method.

+ +

GET and HEAD methods

+ +

If you implement the methods GET and/or HEAD, you must implement one ProvideResource callback for each content-type returned by the content_types_provided callback.

+ +

PUT, POST and PATCH methods

+ +

If you implement the methods PUT, POST and/or PATCH, you must implement the content_types_accepted callback, and one AcceptResource callback for each content-type it returns. Prefix the AcceptResource callback names with from_ for clarity. For example from_html or from_json.

+ +

Do we want to allow the POST method to create individual resources directly through their URI (like PUT)? Implement the allow_missing_post callback. It is recommended to explicitly use PUT in these cases instead.

+ +

May there be conflicts when using PUT to create or replace a resource? Do we want to make sure that two updates around the same time are not cancelling one another? Implement the is_conflict callback.

+ +

DELETE methods

+ +

If you implement the method DELETE, you must implement the delete_resource callback.

+ +

When delete_resource returns, is the resource completely removed from the server, including from any caching service? If not, and/or if the deletion is asynchronous and we have no way of knowing it has been completed yet, implement the delete_completed callback.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/resp/index.html b/_build/static/docs/en/cowboy/1.0/guide/resp/index.html new file mode 100644 index 00000000..d61be41b --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/resp/index.html @@ -0,0 +1,327 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Sending a response

+ +

The Req object also allows you to send a response.

+ +

You can only send one response. Any other attempt will trigger a crash. The response may be sent in one go or with its body streamed by chunks of arbitrary size.

+ +

You can also set headers or the response body in advance and Cowboy will use them when you finally do reply.

+ +

Reply

+ +

You can send a reply with no particular headers or body. Cowboy will make sure to send the mandatory headers with the response.

+ + + +

You can define headers to be sent with the response. Note that header names must be lowercase. Again, Cowboy will make sure to send the mandatory headers with the response.

+ + + +

You can override headers that Cowboy would send otherwise. Any header set by the user will be used over the ones set by Cowboy. For example, you can advertise yourself as a different server.

+ + + +

We also saw earlier how to force close the connection by overriding the connection header.

+ +

Finally, you can also send a body with the response. Cowboy will automatically set the content-length header if you do. We recommend that you set the content-type header so the client may know how to read the body.

+ + + +

Here is the same example but sending HTML this time.

+ + + +

Note that the reply is sent immediately.

+ +

Chunked reply

+ +

You can also stream the response body. First, you need to initiate the reply by sending the response status code. Then you can send the body in chunks of arbitrary size.

+ + + +

You should make sure to match on ok as an error may be returned.

+ +

While it is possible to send a chunked response without a content-type header, it is still recommended. You can set this header or any other just like for normal replies.

+ + + +

Note that the reply and each chunk following it are sent immediately.

+ +

Preset response headers

+ +

You can define response headers in advance. They will be merged into the headers given in the reply call. Headers in the reply call override preset response headers which override the default Cowboy headers.

+ + + +

You can check if a response header has already been set. This will only check the response headers that you set, and not the ones Cowboy will add when actually sending the reply.

+ + + +

It will return true if the header is defined, and false otherwise.

+ +

Finally, you can also delete a preset response header if needed. If you do, it will not be sent.

+ + + +

Preset response body

+ +

You can set the response body in advance. Note that this body will be ignored if you then choose to send a chunked reply, or if you send a reply with an explicit body.

+ + + +

You can also set a fun that will be called when it is time to send the body. There are three different ways of doing that.

+ +

If you know the length of the body that needs to be sent, you should specify it, as it will help clients determine the remaining download time and allow them to inform the user.

+ + + +

If you do not know the length of the body, you should use a chunked response body fun instead.

+ + + +

Finally, you can also send data on the socket directly, without knowing the length in advance. Cowboy may be forced to close the connection at the end of the response though depending on the protocol capabilities.

+ + + +

Sending files

+ +

You can send files directly from disk without having to read them. Cowboy will use the sendfile syscall when possible, which means that the file is sent to the socket directly from the kernel, which is a lot more performant than doing it from userland.

+ +

Again, it is recommended to set the size of the file if it can be known in advance.

+ + + +

Please see the Ranch guide for more information about sending files.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_cond.png b/_build/static/docs/en/cowboy/1.0/guide/rest_cond.png new file mode 100644 index 00000000..64cda347 Binary files /dev/null and b/_build/static/docs/en/cowboy/1.0/guide/rest_cond.png differ diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_cond.svg b/_build/static/docs/en/cowboy/1.0/guide/rest_cond.svg new file mode 100644 index 00000000..542ae17d --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/rest_cond.svg @@ -0,0 +1,1656 @@ + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + some text + some text + has if-unmodified-since? + has if-none-match? + some text + ... + generate_etag + has if-modified-since? + has if-match? + generate_etag + last_modified + + true + match* + true + not modified* + true + no match* + + + + + false + false, orinvalid + modified* + false + + + + + + 412 precondition failed + + middlewares + + + + + + + + + + + + + + + + + no match* + + + + + + date is in the future? + + + + + + + + + + last_modified + + + + + + 304 not modified + + ... + false, orinvalid + match* + + method is GET/HEAD? + true + false + true + false + true + modified* + not modified* + + + + + + generate_etag + + + + + + expires + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_conneg.png b/_build/static/docs/en/cowboy/1.0/guide/rest_conneg.png new file mode 100644 index 00000000..65ecdcf3 Binary files /dev/null and b/_build/static/docs/en/cowboy/1.0/guide/rest_conneg.png differ diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_conneg.svg b/_build/static/docs/en/cowboy/1.0/guide/rest_conneg.svg new file mode 100644 index 00000000..247567a0 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/rest_conneg.svg @@ -0,0 +1,1135 @@ + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + some text + some text + has accept-language? + has accept-charset? + some text + start + charsets_provided + variances + has accept? + content_types_provided + languages_provided + + true + provided* + true + provided* + true + provided* + + + + + false + false + not provided* + false + not provided* + + + + + + 406 not acceptable + + middlewares + + + + + + + + + + + + + + + + + not provided* + + ... + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_delete.png b/_build/static/docs/en/cowboy/1.0/guide/rest_delete.png new file mode 100644 index 00000000..56a861c0 Binary files /dev/null and b/_build/static/docs/en/cowboy/1.0/guide/rest_delete.png differ diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_delete.svg b/_build/static/docs/en/cowboy/1.0/guide/rest_delete.svg new file mode 100644 index 00000000..2f5513cd --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/rest_delete.svg @@ -0,0 +1,1718 @@ + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + some text + some text + delete_completed + has response body? + some text + conneg + multiple_choices + resource_exists + delete_resource + + true + false + + + + + false + + + + + + middlewares + + + + + true + true + + + + + + cond + + 300 multiple choices + + 200 OK + + + + + + has if-match? + false + + + + + + + + + + previously_existed + + 404 not found + false + + + + + + + + + + moved_permanently + + + + + + 412 precondition failed + true + true* + false + + 301 moved permanently + + + + + + + + + + moved_temporarily + true* + false + + 307 moved temporarily + + 410 gone + + + + + false + + 202 accepted + + 204 no content + true + true + + 500 internal server error + false + true + false + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_flowcharts/index.html b/_build/static/docs/en/cowboy/1.0/guide/rest_flowcharts/index.html new file mode 100644 index 00000000..24208561 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/rest_flowcharts/index.html @@ -0,0 +1,304 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

REST flowcharts

+ +

This chapter will explain the REST handler state machine through a number of different diagrams.

+ +

There are four main paths that requests may follow. One for the method OPTIONS; one for the methods GET and HEAD; one for the methods PUT, POST and PATCH; and one for the method DELETE.

+ +

All paths start with the "Start" diagram, and all paths excluding the OPTIONS path go through the "Content negotiation" diagram and optionally the "Conditional requests" diagram if the resource exists.

+ +

The red squares refer to another diagram. The light green squares indicate a response. Other squares may be either a callback or a question answered by Cowboy itself. Green arrows tend to indicate the default behavior if the callback is undefined.

+ +

Start

+ +

All requests start from here.

+ +

+ +

A series of callbacks are called in succession to perform a general checkup of the service, the request line and request headers.

+ +

The request body, if any, is not expected to have been received for any of these steps. It is only processed at the end of the "PUT, POST and PATCH methods" diagram, when all conditions have been met.

+ +

The known_methods and allowed_methods callbacks return a list of methods. Cowboy then checks if the request method is in the list, and stops otherwise.

+ +

The is_authorized callback may be used to check that access to the resource is authorized. Authentication may also be performed as needed. When authorization is denied, the return value from the callback must include a challenge applicable to the requested resource, which will be sent back to the client in the www-authenticate header.

+ +

This diagram is immediately followed by either the "OPTIONS method" diagram when the request method is OPTIONS, or the "Content negotiation" diagram otherwise.

+ +

OPTIONS method

+ +

This diagram only applies to OPTIONS requests.

+ +

+ +

The options callback may be used to add information about the resource, such as media types or languages provided; allowed methods; any extra information. A response body may also be set, although clients should not be expected to read it.

+ +

If the options callback is not defined, Cowboy will send a response containing the list of allowed methods by default.

+ +

Content negotiation

+ +

This diagram applies to all request methods other than OPTIONS. It is executed right after the "Start" diagram is completed.

+ +

+ +

The purpose of these steps is to determine an appropriate representation to be sent back to the client.

+ +

The request may contain any of the accept header; the accept-language header; or the accept-charset header. When present, Cowboy will parse the headers and then call the corresponding callback to obtain the list of provided content-type, language or charset for this resource. It then automatically select the best match based on the request.

+ +

If a callback is not defined, Cowboy will select the content-type, language or charset that the client prefers.

+ +

The content_types_provided also returns the name of a callback for every content-type it accepts. This callback will only be called at the end of the "GET and HEAD methods" diagram, when all conditions have been met.

+ +

The selected content-type, language and charset are saved as meta values in the Req object. You should use the appropriate representation if you set a response body manually (alongside an error code, for example).

+ +

This diagram is immediately followed by the "GET and HEAD methods" diagram, the "PUT, POST and PATCH methods" diagram, or the "DELETE method" diagram, depending on the method.

+ +

GET and HEAD methods

+ +

This diagram only applies to GET and HEAD requests.

+ +

For a description of the cond step, please see the "Conditional requests" diagram.

+ +

+ +

When the resource exists, and the conditional steps succeed, the resource can be retrieved.

+ +

Cowboy prepares the response by first retrieving metadata about the representation, then by calling the ProvideResource callback. This is the callback you defined for each content-types you returned from content_types_provided. This callback returns the body that will be sent back to the client, or a fun if the body must be streamed.

+ +

When the resource does not exist, Cowboy will figure out whether the resource existed previously, and if so whether it was moved elsewhere in order to redirect the client to the new URI.

+ +

The moved_permanently and moved_temporarily callbacks must return the new location of the resource if it was in fact moved.

+ +

PUT, POST and PATCH methods

+ +

This diagram only applies to PUT, POST and PATCH requests.

+ +

For a description of the cond step, please see the "Conditional requests" diagram.

+ +

+ +

When the resource exists, first the conditional steps are executed. When that succeeds, and the method is PUT, Cowboy will call the is_conflict callback. This function can be used to prevent potential race conditions, by locking the resource for example.

+ +

Then all three methods reach the content_types_accepted step that we will describe in a few paragraphs.

+ +

When the resource does not exist, and the method is PUT, Cowboy will check for conflicts and then move on to the content_types_accepted step. For other methods, Cowboy will figure out whether the resource existed previously, and if so whether it was moved elsewhere. If the resource is truly non-existent, the method is POST and the call for allow_missing_post returns true, then Cowboy will move on to the content_types_accepted step. Otherwise the request processing ends there.

+ +

The moved_permanently and moved_temporarily callbacks must return the new location of the resource if it was in fact moved.

+ +

The content_types_accepted returns a list of content-types it accepts, but also the name of a callback for each of them. Cowboy will select the appropriate callback for processing the request body and call it.

+ +

This callback may return one of three different return values.

+ +

If an error occurred while processing the request body, it must return false and Cowboy will send an appropriate error response.

+ +

If the method is POST, then you may return true with an URI of where the resource has been created. This is especially useful for writing handlers for collections.

+ +

Otherwise, return true to indicate success. Cowboy will select the appropriate response to be sent depending on whether a resource has been created, rather than modified, and on the availability of a location header or a body in the response.

+ +

DELETE method

+ +

This diagram only applies to DELETE requests.

+ +

For a description of the cond step, please see the "Conditional requests" diagram.

+ +

+ +

When the resource exists, and the conditional steps succeed, the resource can be deleted.

+ +

Deleting the resource is a two steps process. First the callback delete_resource is executed. Use this callback to delete the resource.

+ +

Because the resource may be cached, you must also delete all cached representations of this resource in the system. This operation may take a while though, so you may return before it finished.

+ +

Cowboy will then call the delete_completed callback. If you know that the resource has been completely deleted from your system, including from caches, then you can return true. If any doubts persist, return false. Cowboy will assume true by default.

+ +

To finish, Cowboy checks if you set a response body, and depending on that, sends the appropriate response.

+ +

When the resource does not exist, Cowboy will figure out whether the resource existed previously, and if so whether it was moved elsewhere in order to redirect the client to the new URI.

+ +

The moved_permanently and moved_temporarily callbacks must return the new location of the resource if it was in fact moved.

+ +

Conditional requests

+ +

This diagram applies to all request methods other than OPTIONS. It is executed right after the resource_exists callback, when the resource exists.

+ +

+ +

A request becomes conditional when it includes either of the if-match header; the if-unmodified-since header; the if-none-match header; or the if-modified-since header.

+ +

If the condition fails, the request ends immediately without any retrieval or modification of the resource.

+ +

The generate_etag and last_modified are called as needed. Cowboy will only call them once and then cache the results for subsequent use.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_get_head.png b/_build/static/docs/en/cowboy/1.0/guide/rest_get_head.png new file mode 100644 index 00000000..efee892a Binary files /dev/null and b/_build/static/docs/en/cowboy/1.0/guide/rest_get_head.png differ diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_get_head.svg b/_build/static/docs/en/cowboy/1.0/guide/rest_get_head.svg new file mode 100644 index 00000000..c78e9399 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/rest_get_head.svg @@ -0,0 +1,1523 @@ + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + some text + some text + last_modified + ProvideResource + some text + conneg + multiple_choices + resource_exists + generate_etag + expires + + true + false + + + + + false + + + + + + middlewares + + + + + true + true + + + + + + cond + + 300 multiple choices + + 200 OK + + + + + + has if-match? + false + + + + + + + + + + previously_existed + + 404 not found + false + + + + + + + + + + moved_permanently + + + + + + 412 precondition failed + true + true* + false + + 301 moved permanently + + + + + + + + + + moved_temporarily + true* + false + + 307 moved temporarily + + 410 gone + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_handlers/index.html b/_build/static/docs/en/cowboy/1.0/guide/rest_handlers/index.html new file mode 100644 index 00000000..69f2b001 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/rest_handlers/index.html @@ -0,0 +1,289 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

REST handlers

+ +

REST is implemented in Cowboy as a protocol upgrade. Once upgraded, the request is handled as a state machine with many optional callbacks describing the resource and modifying the machine's behavior.

+ +

The REST handler is the recommended way to handle requests.

+ +

Initialization

+ +

First, the init/3 callback is called. This callback is common to all handlers. To use REST for the current request, this function must return an upgrade tuple.

+ + + +

Cowboy will then switch to the REST protocol and start executing the state machine, starting from rest_init/2 if it's defined, and ending with rest_terminate/2 also if defined.

+ +

Methods

+ +

The REST component has code for handling the following HTTP methods: HEAD, GET, POST, PATCH, PUT, DELETE and OPTIONS.

+ +

Other methods can be accepted, however they have no specific callback defined for them at this time.

+ +

Callbacks

+ +

All callbacks are optional. Some may become mandatory depending on what other defined callbacks return. The various flowcharts in the next chapter should be a useful to determine which callbacks you need.

+ +

When the request starts being processed, Cowboy will call the rest_init/2 function if it is defined, with the Req object and the handler options as arguments. This function must return {ok, Req, State} where State is the handler's state that all subsequent callbacks will receive.

+ +

At the end of every request, the special callback rest_terminate/2 will be called if it is defined. It cannot be used to send a reply, and must always return ok.

+ +

All other callbacks are resource callbacks. They all take two arguments, the Req object and the State, and return a three-element tuple of the form {Value, Req, State}.

+ +

The following table summarizes the callbacks and their default values. If the callback isn't defined, then the default value will be used. Please look at the flowcharts to find out the result of each return value.

+ +

All callbacks can also return {halt, Req, State} to stop execution of the request, at which point rest_terminate/2 will be called.

+ +

In the following table, "skip" means the callback is entirely skipped if it is undefined, moving directly to the next step. Similarly, "none" means there is no default value for this callback.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Callback nameDefault value
allowed_methods[<<"GET">>, <<"HEAD">>, <<"OPTIONS">>]
allow_missing_posttrue
charsets_providedskip
content_types_acceptednone
content_types_provided[{{<<"text">>, <<"html">>, '*'}, to_html}]
delete_completedtrue
delete_resourcefalse
expiresundefined
forbiddenfalse
generate_etagundefined
is_authorizedtrue
is_conflictfalse
known_content_typetrue
known_methods[<<"GET">>, <<"HEAD">>, <<"POST">>, <<"PUT">>, <<"PATCH">>, <<"DELETE">>, <<"OPTIONS">>]
languages_providedskip
last_modifiedundefined
malformed_requestfalse
moved_permanentlyfalse
moved_temporarilyfalse
multiple_choicesfalse
optionsok
previously_existedfalse
resource_existstrue
service_availabletrue
uri_too_longfalse
valid_content_headerstrue
valid_entity_lengthtrue
variances[]
+ +

As you can see, Cowboy tries to move on with the request whenever possible by using well thought out default values.

+ +

In addition to these, there can be any number of user-defined callbacks that are specified through content_types_accepted/2 and content_types_provided/2. They can take any name, however it is recommended to use a separate prefix for the callbacks of each function. For example, from_html and to_html indicate in the first case that we're accepting a resource given as HTML, and in the second case that we send one as HTML.

+ +

Meta data

+ +

Cowboy will set informative meta values at various points of the execution. You can retrieve them using cowboy_req:meta/{2,3}. The values are defined in the following table.

+ + + + + + + + + + +
Meta keyDetails
media_typeThe content-type negotiated for the response entity.
languageThe language negotiated for the response entity.
charsetThe charset negotiated for the response entity.
+ +

They can be used to send a proper body with the response to a request that used a method other than HEAD or GET.

+ +

Response headers

+ +

Cowboy will set response headers automatically over the execution of the REST code. They are listed in the following table.

+ + + + + + + + + + + + + + +
Header nameDetails
content-languageLanguage used in the response body
content-typeMedia type and charset of the response body
etagEtag of the resource
expiresExpiration date of the resource
last-modifiedLast modification date for the resource
locationRelative or absolute URI to the requested resource
varyList of headers that may change the representation of the resource
+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_options.png b/_build/static/docs/en/cowboy/1.0/guide/rest_options.png new file mode 100644 index 00000000..90fd6f06 Binary files /dev/null and b/_build/static/docs/en/cowboy/1.0/guide/rest_options.png differ diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_options.svg b/_build/static/docs/en/cowboy/1.0/guide/rest_options.svg new file mode 100644 index 00000000..496c050c --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/rest_options.svg @@ -0,0 +1,387 @@ + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + some text + some text + some text + start + options + 200 OK + + + + + + + middlewares + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_principles/index.html b/_build/static/docs/en/cowboy/1.0/guide/rest_principles/index.html new file mode 100644 index 00000000..0be16d14 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/rest_principles/index.html @@ -0,0 +1,238 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

REST principles

+ +

This chapter will attempt to define the concepts behind REST and explain what makes a service RESTful.

+ +

REST is often confused with performing a distinct operation depending on the HTTP method, while using more than the GET and POST methods. That's highly misguided at best.

+ +

We will first attempt to define REST and will look at what it means in the context of HTTP and the Web. For a more in-depth explanation of REST, you can read Roy T. Fielding's dissertation as it does a great job explaining where it comes from and what it achieves.

+ +

REST architecture

+ +

REST is a client-server architecture. The client and the server both have a different set of concerns. The server stores and/or manipulates information and makes it available to the user in an efficient manner. The client takes that information and displays it to the user and/or uses it to perform subsequent requests for information. This separation of concerns allows both the client and the server to evolve independently as it only requires that the interface stays the same.

+ +

REST is stateless. That means the communication between the client and the server always contains all the information needed to perform the request. There is no session state in the server, it is kept entirely on the client's side. If access to a resource requires authentication, then the client needs to authenticate itself with every request.

+ +

REST is cacheable. The client, the server and any intermediary components can all cache resources in order to improve performance.

+ +

REST provides a uniform interface between components. This simplifies the architecture, as all components follow the same rules to speak to one another. It also makes it easier to understand the interactions between the different components of the system. A number of constraints are required to achieve this. They are covered in the rest of the chapter.

+ +

REST is a layered system. Individual components cannot see beyond the immediate layer with which they are interacting. This means that a client connecting to an intermediate component, like a proxy, has no knowledge of what lies beyond. This allows components to be independent and thus easily replaceable or extendable.

+ +

REST optionally provides code on demand. Code may be downloaded to extend client functionality. This is optional however because the client may not be able to download or run this code, and so a REST component cannot rely on it being executed.

+ +

Resources and resource identifiers

+ +

A resource is an abstract concept. In a REST system, any information that can be named may be a resource. This includes documents, images, a collection of resources and any other information. Any information that can be the target of an hypertext link can be a resource.

+ +

A resource is a conceptual mapping to a set of entities. The set of entities evolves over time; a resource doesn't. For example a resource can map to "users who have logged in this past month" and another to "all users". At some point in time they may map to the same set of entities, because all users logged in this past month. But they are still different resources. Similarly, if nobody logged in recently, then the first resource may map to the empty set. This resource exists regardless of the information it maps to.

+ +

Resources are identified by uniform resource identifiers, also known as URIs. Sometimes internationalized resource identifiers, or IRIs, may also be used, but these can be directly translated into a URI.

+ +

In practice we will identify two kinds of resources. Individual resources map to a set of one element, for example "user Joe". Collection of resources map to a set of 0 to N elements, for example "all users".

+ +

Resource representations

+ +

The representation of a resource is a sequence of bytes associated with metadata.

+ +

The metadata comes as a list of key-value pairs, where the name corresponds to a standard that defines the value's structure and semantics. With HTTP, the metadata comes in the form of request or response headers. The headers' structure and semantics are well defined in the HTTP standard. Metadata includes representation metadata, resource metadata and control data.

+ +

The representation metadata gives information about the representation, such as its media type, the date of last modification, or even a checksum.

+ +

Resource metadata could be link to related resources or information about additional representations of the resource.

+ +

Control data allows parameterizing the request or response. For example, we may only want the representation returned if it is more recent than the one we have in cache. Similarly, we may want to instruct the client about how it should cache the representation. This isn't restricted to caching. We may for example want to store a new representation of a resource only if it wasn't modified since we first retrieved it.

+ +

The data format of a representation is also known as the media type. Some media types are intended for direct rendering to the user, while others are intended for automated processing. The media type is a key component of the REST architecture.

+ +

Self-descriptive messages

+ +

Messages must be self-descriptive. That means that the data format of a representation must always come with its media type (and similarly requesting a resource involves choosing the media type of the representation returned). If you are sending HTML, then you must say it is HTML by sending the media type with the representation. In HTTP this is done using the content-type header.

+ +

The media type is often an IANA registered media type, like text/html or image/png, but does not need to be. Exactly two things are important for respecting this constraint: that the media type is well specified, and that the sender and recipient agree about what the media type refers to.

+ +

This means that you can create your own media types, like application/x-mine, and that as long as you write the specifications for it and that both endpoints agree about it then the constraint is respected.

+ +

Hypermedia as the engine of application state

+ +

The last constraint is generally where services that claim to be RESTful fail. Interactions with a server must be entirely driven by hypermedia. The client does not need any prior knowledge of the service in order to use it, other than an entry point and of course basic understanding of the media type of the representations, at the very least enough to find and identify hyperlinks and link relations.

+ +

To give a simple example, if your service only works with the application/json media type then this constraint cannot be respected (as there are no concept of links in JSON) and thus your service isn't RESTful. This is the case for the majority of self-proclaimed REST services.

+ +

On the other hand if you create a JSON based media type that has a concept of links and link relations, then your service might be RESTful.

+ +

Respecting this constraint means that the entirety of the service becomes self-discoverable, not only the resources in it, but also the operations you can perform on it. This makes clients very thin as there is no need to implement anything specific to the service to operate on it.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_put_post_patch.png b/_build/static/docs/en/cowboy/1.0/guide/rest_put_post_patch.png new file mode 100644 index 00000000..4afca9e9 Binary files /dev/null and b/_build/static/docs/en/cowboy/1.0/guide/rest_put_post_patch.png differ diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_put_post_patch.svg b/_build/static/docs/en/cowboy/1.0/guide/rest_put_post_patch.svg new file mode 100644 index 00000000..263cc942 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/rest_put_post_patch.svg @@ -0,0 +1,2856 @@ + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + some text + some text + some text + conneg + resource_exists + + true + + + + + false + + + + + + middlewares + + + + + true + + + + + + + + + + + + + + + cond + + + + + + has if-match? + false + + + + + + method is POST/PATCH? + true + + + + + + + + + + + + + + + + + + + method is POST? + + 412 precondition failed + + + + + + + + + + + + + + previously_existed + + + + + + 404 not found + false + + + + + + + + + true* + false + + 301 moved permanently + + + + + + + + + + moved_temporarily + true* + false + + 307 moved temporarily + + 400 bad request + + + + + true + + + + + + allow_missing_post + + method is POST? + allow_missing_post + + + + + + method is PUT? + + + + + + + + + + is_conflict + true + + 409 conflict + + + + + + content_types_accepted + + AcceptResource + + + + + + + + + + new resource? + + + + + + + + + + new resource? + + 201 created + + 303 see other + + + + + + + + + + has resp location? + + + + + + + + + + + has resp body? + + + + + + + + + + multiple_choices + false + + 300 multiple choices + + 200 OK + 204 no content + true + + + + + true + + moved_permanently + + 410 gone + false + true + false + false + false + false + + + + + true + + + + + true, URI* + + + + + true + false + true + true + false + true + false + true + false + false + false + + + + + + + + true + + + + + false + true + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_start.png b/_build/static/docs/en/cowboy/1.0/guide/rest_start.png new file mode 100644 index 00000000..7f264642 Binary files /dev/null and b/_build/static/docs/en/cowboy/1.0/guide/rest_start.png differ diff --git a/_build/static/docs/en/cowboy/1.0/guide/rest_start.svg b/_build/static/docs/en/cowboy/1.0/guide/rest_start.svg new file mode 100644 index 00000000..d75e1cc6 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/rest_start.svg @@ -0,0 +1,1468 @@ + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + some text + some text + uri_too_long + malformed_request + some text + init + is_authorized + forbidden + valid_content_headers + known_content_type + valid_entity_length + ... + service_available + known_methods + allowed_methods + + true + known* + false + allowed* + false + true + false + true + true + true + + + + + false + unknown* + true + unallowed* + true + false* + true + false + false + false + + 503 service unavailable + + + + + + + + + + 501 not implemented + 414 request URI too long + 405 method not allowed + 400 bad request + 401 unauthorized + 403 forbidden + 501 not implemented + 415 unsupported media type + 413 request entity too large + + middlewares + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/routing/index.html b/_build/static/docs/en/cowboy/1.0/guide/routing/index.html new file mode 100644 index 00000000..9f0923f0 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/routing/index.html @@ -0,0 +1,365 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Routing

+ +

Cowboy does nothing by default.

+ +

To make Cowboy useful, you need to map URLs to Erlang modules that will handle the requests. This is called routing.

+ +

When Cowboy receives a request, it tries to match the requested host and path to the resources given in the dispatch rules. If it matches, then the associated Erlang code will be executed.

+ +

Routing rules are given per host. Cowboy will first match on the host, and then try to find a matching path.

+ +

Routes need to be compiled before they can be used by Cowboy.

+ +

Structure

+ +

The general structure for the routes is defined as follow.

+ + + +

Each host contains matching rules for the host along with optional constraints, and a list of routes for the path component.

+ + + +

The list of routes for the path component is defined similar to the list of hosts.

+ + + +

Finally, each path contains matching rules for the path along with optional constraints, and gives us the handler module to be used along with options that will be given to it on initialization.

+ + + +

Continue reading to learn more about the match syntax and the optional constraints.

+ +

Match syntax

+ +

The match syntax is used to associate host names and paths with their respective handlers.

+ +

The match syntax is the same for host and path with a few subtleties. Indeed, the segments separator is different, and the host is matched starting from the last segment going to the first. All examples will feature both host and path match rules and explain the differences when encountered.

+ +

Excluding special values that we will explain at the end of this section, the simplest match value is a host or a path. It can be given as either a string() or a binary().

+ + + +

As you can see, all paths defined this way must start with a slash character. Note that these two paths are identical as far as routing is concerned.

+ + + +

Hosts with and without a trailing dot are equivalent for routing. Similarly, hosts with and without a leading dot are also equivalent.

+ + + +

It is possible to extract segments of the host and path and to store the values in the Req object for later use. We call these kind of values bindings.

+ +

The syntax for bindings is very simple. A segment that begins with the : character means that what follows until the end of the segment is the name of the binding in which the segment value will be stored.

+ + + +

If these two end up matching when routing, you will end up with two bindings defined, subdomain and name, each containing the segment value where they were defined. For example, the URL http://test.example.org/hats/wild_cowboy_legendary/prices will result in having the value test bound to the name subdomain and the value wild_cowboy_legendary bound to the name name. They can later be retrieved using cowboy_req:binding/{2,3}. The binding name must be given as an atom.

+ +

There is a special binding name you can use to mimic the underscore variable in Erlang. Any match against the _ binding will succeed but the data will be discarded. This is especially useful for matching against many domain names in one go.

+ + + +

Similarly, it is possible to have optional segments. Anything between brackets is optional.

+ + + +

You can also have imbricated optional segments.

+ + + +

You can retrieve the rest of the host or path using [...]. In the case of hosts it will match anything before, in the case of paths anything after the previously matched segments. It is a special case of optional segments, in that it can have zero, one or many segments. You can then find the segments using cowboy_req:host_info/1 and cowboy_req:path_info/1 respectively. They will be represented as a list of segments.

+ + + +

If a binding appears twice in the routing rules, then the match will succeed only if they share the same value. This copies the Erlang pattern matching behavior.

+ + + +

This is also true when an optional segment is present. In this case the two values must be identical only if the segment is available.

+ + + +

If a binding is defined in both the host and path, then they must also share the same value.

+ + + +

Finally, there are two special match values that can be used. The first is the atom '_' which will match any host or path.

+ + + +

The second is the special host match "*" which will match the wildcard path, generally used alongside the OPTIONS method.

+ + + +

Constraints

+ +

After the matching has completed, the resulting bindings can be tested against a set of constraints. Constraints are only tested when the binding is defined. They run in the order you defined them. The match will succeed only if they all succeed.

+ +

They are always given as a two or three elements tuple, where the first element is the name of the binding, the second element is the constraint's name, and the optional third element is the constraint's arguments.

+ +

The following constraints are currently defined:

+ +
    +
  • {Name, int}
    • +
  • {Name, function, fun ((Value) -> true | {true, NewValue} | false)}
    • +
+ +

The int constraint will check if the binding is a binary string representing an integer, and if it is, will convert the value to integer.

+ +

The function constraint will pass the binding value to a user specified function that receives the binary value as its only argument and must return whether it fulfills the constraint, optionally modifying the value. The value thus returned can be of any type.

+ +

Note that constraint functions SHOULD be pure and MUST NOT crash.

+ +

Compilation

+ +

The structure defined in this chapter needs to be compiled before it is passed to Cowboy. This allows Cowboy to efficiently lookup the correct handler to run instead of having to parse the routes repeatedly.

+ +

This can be done with a simple call to cowboy_router:compile/1.

+ + + +

Note that this function will return {error, badarg} if the structure given is incorrect.

+ +

Live update

+ +

You can use the cowboy:set_env/3 function for updating the dispatch list used by routing. This will apply to all new connections accepted by the listener.

+ + + +

Note that you need to compile the routes before updating.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/static_handlers/index.html b/_build/static/docs/en/cowboy/1.0/guide/static_handlers/index.html new file mode 100644 index 00000000..98e9c833 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/static_handlers/index.html @@ -0,0 +1,280 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Static handler

+ +

The static handler is a built-in REST handler for serving files. It is available as a convenience and provides a quick solution for serving files during development.

+ +

For systems in production, consider using one of the many Content Distribution Network (CDN) available on the market, as they are the best solution for serving files. They are covered in the next chapter. If you decide against using a CDN solution, then please look at the chapter after that, as it explains how to efficiently serve static files on your own.

+ +

The static handler can serve either one file or all files from a given directory. It can also send etag headers for client-side caching.

+ +

To use the static file handler, simply add routes for it with the appropriate options.

+ +

Serve one file

+ +

You can use the static handler to serve one specific file from an application's private directory. This is particularly useful to serve an index.html file when the client requests the / path, for example. The path configured is relative to the given application's private directory.

+ +

The following rule will serve the file static/index.html from the application my_app's priv directory whenever the path / is accessed.

+ + + +

You can also specify the absolute path to a file, or the path to the file relative to the current directory.

+ + + +

Serve all files from a directory

+ +

You can also use the static handler to serve all files that can be found in the configured directory. The handler will use the path_info information to resolve the file location, which means that your route must end with a [...] pattern for it to work. All files are served, including the ones that may be found in subfolders.

+ +

You can specify the directory relative to an application's private directory.

+ +

The following rule will serve any file found in the application my_app's priv directory inside the static/assets folder whenever the requested path begins with /assets/.

+ + + +

You can also specify the absolute path to the directory or set it relative to the current directory.

+ + + +

Customize the mimetype detection

+ +

By default, Cowboy will attempt to recognize the mimetype of your static files by looking at the extension.

+ +

You can override the function that figures out the mimetype of the static files. It can be useful when Cowboy is missing a mimetype you need to handle, or when you want to reduce the list to make lookups faster. You can also give a hard-coded mimetype that will be used unconditionally.

+ +

Cowboy comes with two functions built-in. The default function only handles common file types used when building Web applications. The other function is an extensive list of hundreds of mimetypes that should cover almost any need you may have. You can of course create your own function.

+ +

To use the default function, you should not have to configure anything, as it is the default. If you insist, though, the following will do the job.

+ + + +

As you can see, there is an optional field that may contain a list of less used options, like mimetypes or etag. All option types have this optional field.

+ +

To use the function that will detect almost any mimetype, the following configuration will do.

+ + + +

You probably noticed the pattern by now. The configuration expects a module and a function name, so you can use any of your own functions instead.

+ + + +

The function that performs the mimetype detection receives a single argument that is the path to the file on disk. It is recommended to return the mimetype in tuple form, although a binary string is also allowed (but will require extra processing). If the function can't figure out the mimetype, then it should return {<<"application">>, <<"octet-stream">>, []}.

+ +

When the static handler fails to find the extension in the list, it will send the file as application/octet-stream. A browser receiving such file will attempt to download it directly to disk.

+ +

Finally, the mimetype can be hard-coded for all files. This is especially useful in combination with the file and priv_file options as it avoids needless computation.

+ + + +

Generate an etag

+ +

By default, the static handler will generate an etag header value based on the size and modified time. This solution can not be applied to all systems though. It would perform rather poorly over a cluster of nodes, for example, as the file metadata will vary from server to server, giving a different etag on each server.

+ +

You can however change the way the etag is calculated.

+ + + +

This function will receive three arguments: the path to the file on disk, the size of the file and the last modification time. In a distributed setup, you would typically use the file path to retrieve an etag value that is identical across all your servers.

+ +

You can also completely disable etag handling.

+ + + + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/upgrade_protocol/index.html b/_build/static/docs/en/cowboy/1.0/guide/upgrade_protocol/index.html new file mode 100644 index 00000000..41aa090e --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/upgrade_protocol/index.html @@ -0,0 +1,200 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Protocol upgrades

+ +

Cowboy features many different handlers, each for different purposes. All handlers have a common entry point: the init/3 function.

+ +

The default handler type is the simple HTTP handler.

+ +

To switch to a different protocol, you must perform a protocol upgrade. This is what is done for Websocket and REST and is explained in details in the respective chapters.

+ +

You can also create your own protocol on top of Cowboy and use the protocol upgrade mechanism to switch to it.

+ +

For example, if you create the my_protocol module implementing the cowboy_sub_protocol behavior, then you can upgrade to it by simply returning the module name from init/3.

+ + + +

The cowboy_sub_protocol behavior only requires one callback, upgrade/4. It receives the Req object, the middleware environment, and the handler and options for this request. This is the same module as the init/3 function and the same options that were passed to it.

+ + + +

This callback is expected to behave like a middleware. Please see the corresponding chapter for more information.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/ws_handlers/index.html b/_build/static/docs/en/cowboy/1.0/guide/ws_handlers/index.html new file mode 100644 index 00000000..e1d3d9a2 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/ws_handlers/index.html @@ -0,0 +1,327 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Handling Websocket connections

+ +

A special handler is required for handling Websocket connections. Websocket handlers allow you to initialize the connection, handle incoming frames from the socket, handle incoming Erlang messages and then clean up on termination.

+ +

Websocket handlers essentially act as a bridge between the client and the Erlang system. They will typically do little more than socket communication and decoding/encoding of frames.

+ +

Initialization

+ +

First, the init/3 callback is called. This callback is common to all handlers. To establish a Websocket connection, this function must return an upgrade tuple.

+ + + +

It is also possible to return an update Req object and options using the longer form of this tuple.

+ + + +

Upon receiving this tuple, Cowboy will switch to the code that handles Websocket connections. It does not immediately perform the handshake however. First, it calls the websocket_init/3 callback.

+ +

This function must be used to initialize the state, and can also be used to register the process, start a timer, etc. As long as the function returns an ok tuple, then Cowboy performs the Websocket handshake.

+ + + +

A shutdown tuple can be returned to refuse to perform the handshake. When doing so, Cowboy will send a 400 Bad Request response to the client and close the connection.

+ + + +

It is also possible to perform a cowboy_req:reply/{2,3,4} before returning a shutdown tuple, allowing you to override the response sent back to the client.

+ +

Note that browser support for handling Websocket connection failures may vary.

+ +

If the sec-websocket-protocol header was sent with the request for establishing a Websocket connection, then the Websocket handler must select one of these subprotocol and send it back to the client, otherwise the client might decide to close the connection, assuming no correct subprotocol was found.

+ + + +

It is not recommended to wait too long inside the websocket_init/3 function. Any extra initialization may be done after returning by sending yourself a message before doing anything. Any message sent to self() from websocket_init/3 is guaranteed to arrive before any frames from the client.

+ +

It is also very easy to ensure that this message arrives before any message from other processes by sending it before registering or enabling timers.

+ + + +

Handling frames from the client

+ +

Cowboy will call websocket_handle/3 whenever a text, binary, ping or pong frame arrives from the client. Note that in the case of ping and pong frames, no action is expected as Cowboy automatically replies to ping frames.

+ +

The handler can decide to send frames to the socket, shutdown or just continue without sending anything.

+ +

The following snippet echoes back any text frame received and ignores all others.

+ + + +

Handling Erlang messages

+ +

Cowboy will call websocket_info/3 whenever an Erlang message arrives.

+ +

The handler can decide to send frames to the socket, shutdown or just continue without sending anything.

+ +

The following snippet forwards any log message to the socket and ignores all others.

+ + + +

Sending frames to the socket

+ +

Cowboy allows sending either a single frame or a list of frames to the socket. Any frame can be sent: text, binary, ping, pong or close frames.

+ +

The following example sends three frames using a single reply tuple.

+ + + +

Note that the payload for text and binary frames is of type iodata(), meaning it can be either a binary() or an iolist().

+ +

Sending a close frame will immediately initiate the closing of the Websocket connection. Be aware that any additional frames sent by the client or any Erlang messages waiting to be received will not be processed. Also note that when replying a list of frames that includes close, any frame found after the close frame will not be sent.

+ +

Ping and timeout

+ +

The biggest performance improvement you can do when dealing with a huge number of Websocket connections is to reduce the number of timers that are started on the server. A common use of timers when dealing with connections is for sending a ping every once in a while. This should be done exclusively on the client side. Indeed, a server handling one million Websocket connections will perform a lot better when it doesn't have to handle one million extra timers too!

+ +

Cowboy will automatically respond to ping frames sent by the client. It will still forward the frame to the handler for informative purpose, but no further action is required.

+ +

Cowboy can be configured to automatically close the Websocket connection when no data arrives on the socket. It is highly recommended to configure a timeout for it, as otherwise you may end up with zombie "half-connected" sockets that may leave the process alive forever.

+ +

A good timeout value is 60 seconds.

+ + + +

This value cannot be changed once it is set. It defaults to infinity.

+ +

Hibernate

+ +

Most tuples returned from handler callbacks can include an extra value hibernate. After doing any necessary operations following the return of the callback, Cowboy will hibernate the process.

+ +

It is highly recommended to hibernate processes that do not handle much traffic. It is a good idea to hibernate all connections by default and investigate only when you start noticing increased CPU usage.

+ +

Supporting older browsers

+ +

Unfortunately Websocket is a relatively recent technology, which means that not all browsers support it. A library like Bullet can be used to emulate Websocket connections on older browsers.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/guide/ws_protocol/index.html b/_build/static/docs/en/cowboy/1.0/guide/ws_protocol/index.html new file mode 100644 index 00000000..05d2bdeb --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/guide/ws_protocol/index.html @@ -0,0 +1,194 @@ + + + + + Nine Nines Support: Cowboy User Guide + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

The Websocket protocol

+ +

This chapter explains what Websocket is and why it is a vital component of soft realtime Web applications.

+ +

Description

+ +

Websocket is an extension to HTTP that emulates plain TCP connections between the client, typically a Web browser, and the server. It uses the HTTP Upgrade mechanism to establish the connection.

+ +

Websocket connections are asynchronous, unlike HTTP. This means that not only can the client send frames to the server at any time, but the server can also send frames to the client without the client initiating anything other than the Websocket connection itself. This allows the server to push data to the client directly.

+ +

Websocket is an IETF standard. Cowboy supports the standard and all drafts that were previously implemented by browsers, excluding the initial flawed draft sometimes known as "version 0".

+ +

Implementation

+ +

Cowboy implements Websocket as a protocol upgrade. Once the upgrade is performed from the init/3 callback, Cowboy switches to Websocket. Please consult the next chapter for more information on initiating and handling Websocket connections.

+ +

The implementation of Websocket in Cowboy is validated using the Autobahn test suite, which is an extensive suite of tests covering all aspects of the protocol. Cowboy passes the suite with 100% success, including all optional tests.

+ +

Cowboy's Websocket implementation also includes the x-webkit-deflate-frame compression draft which is being used by some browsers to reduce the size of data being transmitted. Cowboy will automatically use compression as long as the compress protocol option is set when starting the listener.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/index.html b/_build/static/docs/en/cowboy/1.0/index.html new file mode 100644 index 00000000..b1ab57ba --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/index.html @@ -0,0 +1,206 @@ + + + + + Nine Nines Support: Cowboy README + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

Cowboy

+
+

Cowboy is a small, fast and modular HTTP server written in Erlang.

+

Goals

+

Cowboy aims to provide a complete HTTP stack in a small code base. It is optimized for low latency and low memory usage, in part because it uses binary strings.

+

Cowboy provides routing capabilities, selectively dispatching requests to handlers written in Erlang.

+

Because it uses Ranch for managing connections, Cowboy can easily be embedded in any other application.

+

No parameterized module. No process dictionary. Clean Erlang code.

+

Sponsors

+

The SPDY implementation was sponsored by LeoFS Cloud Storage.

+

The project is currently sponsored by Kato.im.

+

Online documentation

+ +

Offline documentation

+
    +
  • While still online, run make docs
    • +
  • Function reference man pages available in doc/man3/ and doc/man7/
    • +
  • Run make install-docs to install man pages on your system
    • +
  • Full documentation in Markdown available in doc/markdown/
    • +
  • Examples available in examples/
    • +
+

Getting help

+ +
+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy/index.html new file mode 100644 index 00000000..892103f5 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy/index.html @@ -0,0 +1,273 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy

+ +

The cowboy module provides convenience functions for manipulating Ranch listeners.

+ +

Types

+ +

http_headers() = [{binary(), iodata()}]

+ +

HTTP headers as a list of key/values.

+ +

http_status() = non_neg_integer() | binary()

+ +

HTTP status.

+ +

A binary status can be used to set a custom message.

+ +

http_version() = 'HTTP/1.1' | 'HTTP/1.0'

+ +

HTTP version.

+ +

onrequest_fun() = fun((cowboy_req:req()) -> cowboy_req:req())

+ +

Fun called immediately after receiving a request.

+ +

It can perform any operation on the Req object, including reading the request body or replying. If a reply is sent, the processing of the request ends here, before any middleware is executed.

+ +

onresponse_fun() = fun((http_status(), http_headers(), iodata(), cowboy_req:req()) -> cowboy_req:req())

+ +

Fun called immediately before sending the response.

+ +

It can perform any operation on the Req object, including reading the request body or replying. If a reply is sent, it overrides the reply initially sent. The callback will not be called again for the new reply.

+ +

Exports

+ +

start_http(Ref, NbAcceptors, TransOpts, ProtoOpts) -> {ok, pid()}

+ +

Types:

+ +
    +
  • Ref = ranch:ref()
    • +
  • NbAcceptors = non_neg_integer()
    • +
  • TransOpts = ranch_tcp:opts()
    • +
  • ProtoOpts = cowboy_protocol:opts()
    • +
+ +

Start listening for HTTP connections. Returns the pid for this listener's supervisor.

+ +

start_https(Ref, NbAcceptors, TransOpts, ProtoOpts) -> {ok, pid()}

+ +

Types:

+ +
    +
  • Ref = ranch:ref()
    • +
  • NbAcceptors = non_neg_integer()
    • +
  • TransOpts = ranch_ssl:opts()
    • +
  • ProtoOpts = cowboy_protocol:opts()
    • +
+ +

Start listening for HTTPS connections. Returns the pid for this listener's supervisor.

+ +

start_spdy(Ref, NbAcceptors, TransOpts, ProtoOpts) -> {ok, pid()}

+ +

Types:

+ +
    +
  • Ref = ranch:ref()
    • +
  • NbAcceptors = non_neg_integer()
    • +
  • TransOpts = ranch_ssl:opts()
    • +
  • ProtoOpts = cowboy_spdy:opts()
    • +
+ +

Start listening for SPDY connections. Returns the pid for this listener's supervisor.

+ +

stop_listener(Ref) -> ok | {error, not_found}

+ +

Types:

+ +
    +
  • Ref = ranch:ref()
    • +
+ +

Stop a previously started listener.

+ +

set_env(Ref, Name, Value) -> ok

+ +

Types:

+ +
    +
  • Ref = ranch:ref()
    • +
  • Name = atom()
    • +
  • Value = any()
    • +
+ +

Set or update an environment value for an already running listener. This will take effect on all subsequent connections.

+ +

See also

+ +

The Ranch guide provides detailed information about how listeners work.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_app/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_app/index.html new file mode 100644 index 00000000..bd353e67 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_app/index.html @@ -0,0 +1,188 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

The Cowboy Application

+ +

Small, fast, modular HTTP server.

+ +

Dependencies

+ +

The cowboy application uses the Erlang applications ranch for listening and accepting TCP connections, crypto for establishing Websocket connections, and cowlib for parsing and building messages for Web protocols. These dependencies must be loaded for the cowboy application to work. In an embedded environment this means that they need to be started with the application:start/{1,2} function before the cowboy application is started.

+ +

The cowboy application also uses the Erlang applications asn1, public_key and ssl when listening for HTTPS connections. These are started automatically if they weren't before.

+ +

Environment

+ +

The cowboy application does not define any application environment configuration parameters.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_handler/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_handler/index.html new file mode 100644 index 00000000..8761e46d --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_handler/index.html @@ -0,0 +1,199 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_handler

+ +

The cowboy_handler middleware executes the handler passed through the environment values handler and handler_opts, and adds the result of this execution to the environment as the value result, indicating that the request has been handled and received a response.

+ +

Environment input:

+ +
    +
  • handler = module()
    • +
  • handler_opts = any()
    • +
+ +

Environment output:

+ +
    +
  • result = ok
    • +
+ +

Types

+ +

None.

+ +

Exports

+ +

None.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_http_handler/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_http_handler/index.html new file mode 100644 index 00000000..1791c88e --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_http_handler/index.html @@ -0,0 +1,229 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_http_handler

+ +

The cowboy_http_handler behaviour defines the interface used by plain HTTP handlers.

+ +

Unless noted otherwise, the callbacks will be executed sequentially.

+ +

Types

+ +

None.

+ +

Callbacks

+ +

init({TransportName, ProtocolName}, Req, Opts) -> {ok, Req, State} | {shutdown, Req, State}

+ +

Types:

+ +
    +
  • TransportName = tcp | ssl | atom()
    • +
  • ProtocolName = http | atom()
    • +
  • Req = cowboy_req:req()
    • +
  • Opts = any()
    • +
  • State = any()
    • +
+ +

Initialize the state for this request.

+ +

The shutdown return value can be used to skip the handle/2 call entirely.

+ +

handle(Req, State) -> {ok, Req, State}

+ +

Types:

+ +
    +
  • Req = cowboy_req:req()
    • +
  • State = any()
    • +
+ +

Handle the request.

+ +

This callback is where the request is handled and a response should be sent. If a response is not sent, Cowboy will send a 204 No Content response automatically.

+ +

terminate(Reason, Req, State) -> ok

+ +

Types:

+ +
    +
  • Reason = {normal, shutdown} | {error, atom()}
    • +
  • Req = cowboy_req:req()
    • +
  • State = any()
    • +
+ +

Perform any necessary cleanup of the state.

+ +

This callback should release any resource currently in use, clear any active timer and reset the process to its original state, as it might be reused for future requests sent on the same connection. Typical plain HTTP handlers rarely need to use it.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_loop_handler/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_loop_handler/index.html new file mode 100644 index 00000000..94fa6f32 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_loop_handler/index.html @@ -0,0 +1,245 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_loop_handler

+ +

The cowboy_loop_handler behaviour defines the interface used by HTTP handlers that do not send a response directly, instead requiring a receive loop to process Erlang messages.

+ +

This interface is best fit for long-polling types of requests.

+ +

The init/3 callback will always be called, followed by zero or more calls to info/3. The terminate/3 callback will always be called last.

+ +

Types

+ +

None.

+ +

Callbacks

+ +

init({TransportName, ProtocolName}, Req, Opts) -> {loop, Req, State} | {loop, Req, State, hibernate} | {loop, Req, State, Timeout} | {loop, Req, State, Timeout, hibernate} | {shutdown, Req, State}

+ +

Types:

+ +
    +
  • TransportName = tcp | ssl | atom()
    • +
  • ProtocolName = http | atom()
    • +
  • Req = cowboy_req:req()
    • +
  • Opts = any()
    • +
  • State = any()
    • +
  • Timeout = timeout()
    • +
+ +

Initialize the state for this request.

+ +

This callback will typically be used to register this process to an event manager or a message queue in order to receive the messages the handler wants to process.

+ +

The receive loop will run for a duration of up to Timeout milliseconds after it last received data from the socket, at which point it will stop and send a 204 No Content reply. By default this value is set to infinity. It is recommended to either set this value or ensure by any other mechanism that the handler will be closed after a certain period of inactivity.

+ +

The hibernate option will hibernate the process until it starts receiving messages.

+ +

The shutdown return value can be used to skip the receive loop entirely.

+ +

info(Info, Req, State) -> {ok, Req, State} | {loop, Req, State} | {loop, Req, State, hibernate}

+ +

Types:

+ +
    +
  • Info = any()
    • +
  • Req = cowboy_req:req()
    • +
  • State = any()
    • +
+ +

Handle the Erlang message received.

+ +

This function will be called every time an Erlang message has been received. The message can be any Erlang term.

+ +

The ok return value can be used to stop the receive loop, typically because a response has been sent.

+ +

The hibernate option will hibernate the process until it receives another message.

+ +

terminate(Reason, Req, State) -> ok

+ +

Types:

+ +
    +
  • Reason = {normal, shutdown} | {normal, timeout} | {error, closed} | {error, overflow} | {error, atom()}
    • +
  • Req = cowboy_req:req()
    • +
  • State = any()
    • +
+ +

Perform any necessary cleanup of the state.

+ +

This callback will typically unregister from any event manager or message queue it registered to in init/3.

+ +

This callback should release any resource currently in use, clear any active timer and reset the process to its original state, as it might be reused for future requests sent on the same connection.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_middleware/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_middleware/index.html new file mode 100644 index 00000000..5c9189f1 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_middleware/index.html @@ -0,0 +1,213 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_middleware

+ +

The cowboy_middleware behaviour defines the interface used by Cowboy middleware modules.

+ +

Middlewares process the request sequentially in the order they are configured.

+ +

Types

+ +

env() = [{atom(), any()}]

+ +

The environment variable.

+ +

One is created for every request. It is passed to each middleware module executed and subsequently returned, optionally with its contents modified.

+ +

Callbacks

+ +

execute(Req, Env) -> {ok, Req, Env} | {suspend, Module, Function, Args} | {halt, Req} | {error, StatusCode, Req}

+ +

Types:

+ +
    +
  • Req = cowboy_req:req()
    • +
  • Env = env()
    • +
  • Module = module()
    • +
  • Function = atom()
    • +
  • Args = [any()]
    • +
  • StatusCode = cowboy:http_status()
    • +
+ +

Execute the middleware.

+ +

The ok return value indicates that everything went well and that Cowboy should continue processing the request. A response may or may not have been sent.

+ +

The suspend return value will hibernate the process until an Erlang message is received. Note that when resuming, any previous stacktrace information will be gone.

+ +

The halt return value stops Cowboy from doing any further processing of the request, even if there are middlewares that haven't been executed yet. The connection may be left open to receive more requests from the client.

+ +

The error return value sends an error response identified by the StatusCode and then proceeds to terminate the connection. Middlewares that haven't been executed yet will not be called.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html new file mode 100644 index 00000000..89e549c1 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_protocol/index.html @@ -0,0 +1,244 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_protocol

+ +

The cowboy_protocol module implements HTTP/1.1 and HTTP/1.0 as a Ranch protocol.

+ +

Types

+ +

opts() = [{compress, boolean()} | {env, cowboy_middleware:env()} | {max_empty_lines, non_neg_integer()} | {max_header_name_length, non_neg_integer()} | {max_header_value_length, non_neg_integer()} | {max_headers, non_neg_integer()} | {max_keepalive, non_neg_integer()} | {max_request_line_length, non_neg_integer()} | {middlewares, [module()]} | {onrequest, cowboy:onrequest_fun()} | {onresponse, cowboy:onresponse_fun()} | {timeout, timeout()}]

+ +

Configuration for the HTTP protocol handler.

+ +

This configuration is passed to Cowboy when starting listeners using cowboy:start_http/4 or cowboy:start_https/4 functions.

+ +

It can be updated without restarting listeners using the Ranch functions ranch:get_protocol_options/1 and ranch:set_protocol_options/2.

+ +

Option descriptions

+ +

The default value is given next to the option name.

+ +

compress (false)

+ +

When enabled, Cowboy will attempt to compress the response body.

+ +

env ([{listener, Ref}])

+ +

Initial middleware environment.

+ +

max_empty_lines (5)

+ +

Maximum number of empty lines before a request.

+ +

max_header_name_length (64)

+ +

Maximum length of header names.

+ +

max_header_value_length (4096)

+ +

Maximum length of header values.

+ +

max_headers (100)

+ +

Maximum number of headers allowed per request.

+ +

max_keepalive (100)

+ +

Maximum number of requests allowed per connection.

+ +

max_request_line_length (4096)

+ +

Maximum length of the request line.

+ +

middlewares ([cowboy_router, cowboy_handler])

+ +

List of middlewares to execute for every requests.

+ +

onrequest (undefined)

+ +

Fun called every time a request is received.

+ +

onresponse (undefined)

+ +

Fun called every time a response is sent.

+ +

timeout (5000)

+ +

Time in ms with no requests before Cowboy closes the connection.

+ +

Exports

+ +

None.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_req/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_req/index.html new file mode 100644 index 00000000..b3e122d4 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_req/index.html @@ -0,0 +1,854 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_req

+ +

The cowboy_req module provides functions to access, manipulate and respond to requests.

+ +

The functions in this module follow patterns for their return types, based on the kind of function.

+ +
    +
  • access: {Value, Req}
    • +
  • action: {Result, Req} | {Result, Value, Req} | {error, atom()}
    • +
  • modification: Req
    • +
  • question: boolean()
    • +
+ +

The only exception is the chunk/2 function which may return ok.

+ +

Whenever Req is returned, you must use this returned value and ignore any previous you may have had. This value contains various state informations which are necessary for Cowboy to do some lazy evaluation or cache results where appropriate.

+ +

All functions which perform an action should only be called once. This includes reading the request body or replying. Cowboy will generally throw an error on the second call.

+ +

It is highly discouraged to pass the Req object to another process. Doing so and calling cowboy_req functions from it leads to undefined behavior.

+ +

Types

+ +

body_opts() = [{continue, boolean()} | {length, non_neg_integer()} | {read_length, non_neg_integer()} | {read_timeout, timeout()} | {transfer_decode, transfer_decode_fun(), any()} | {content_decode, content_decode_fun()}]

+ +

Request body reading options.

+ + + +

Cookie options.

+ +

req() - opaque to the user

+ +

The Req object.

+ +

All functions in this module receive a Req as argument, and most of them return a new object labelled Req2 in the function descriptions below.

+ + + +

binding(Name, Req) -> binding(Name, Req, undefined)

+ +

binding(Name, Req, Default) -> {Value, Req2}

+ +

Types:

+ +
    +
  • Name = atom()
    • +
  • Default = any()
    • +
  • Value = any() | Default
    • +
+ +

Return the value for the given binding.

+ +

By default the value is a binary, however constraints may change the type of this value (for example automatically converting numbers to integer).

+ +

bindings(Req) -> {[{Name, Value}], Req2}

+ +

Types:

+ +
    +
  • Name = atom()
    • +
  • Value = any()
    • +
+ +

Return all bindings.

+ +

By default the value is a binary, however constraints may change the type of this value (for example automatically converting numbers to integer).

+ + + + + +

Types:

+ +
    +
  • Name = binary()
    • +
  • Default = any()
    • +
  • Value = binary() | Default
    • +
+ +

Return the value for the given cookie.

+ +

Cookie names are case sensitive.

+ +

cookies(Req) -> {[{Name, Value}], Req2}

+ +

Types:

+ +
    +
  • Name = binary()
    • +
  • Value = binary()
    • +
+ +

Return all cookies.

+ + + + + +

Types:

+ +
    +
  • Name = binary()
    • +
  • Default = any()
    • +
  • Value = binary() | Default
    • +
+ +

Return the value for the given header.

+ +

While header names are case insensitive, this function expects the name to be a lowercase binary.

+ +

headers(Req) -> {Headers, Req2}

+ +

Types:

+ +
    +
  • Headers = cowboy:http_headers()
    • +
+ +

Return all headers.

+ +

host(Req) -> {Host, Req2}

+ +

Types:

+ +
    +
  • Host = binary()
    • +
+ +

Return the requested host.

+ +

host_info(Req) -> {HostInfo, Req2}

+ +

Types:

+ +
    +
  • HostInfo = cowboy_router:tokens() | undefined
    • +
+ +

Return the extra tokens from matching against ... during routing.

+ +

host_url(Req) -> {HostURL, Req2}

+ +

Types:

+ +
    +
  • HostURL = binary() | undefined
    • +
+ +

Return the requested URL excluding the path component.

+ +

This function will always return undefined until the cowboy_router middleware has been executed. This includes the onrequest hook.

+ +

meta(Name, Req) -> meta(Name, Req, undefined)

+ +

meta(Name, Req, Default) -> {Value, Req2}

+ +

Types:

+ +
    +
  • Name = atom()
    • +
  • Default = any()
    • +
  • Value = any()
    • +
+ +

Return metadata about the request.

+ +

method(Req) -> {Method, Req2}

+ +

Types:

+ +
    +
  • Method = binary()
    • +
+ +

Return the method.

+ +

Methods are case sensitive. Standard methods are always uppercase.

+ +

parse_header(Name, Req) ->

+ +

parse_header(Name, Req, Default) -> {ok, ParsedValue, Req2} | {undefined, Value, Req2} | {error, badarg}

+ +

Types:

+ +
    +
  • Name = binary()
    • +
  • Default = any()
    • +
  • ParsedValue - see below
    • +
  • Value = any()
    • +
+ +

Parse the given header.

+ +

While header names are case insensitive, this function expects the name to be a lowercase binary.

+ +

The parse_header/2 function will call parser_header/3 with a different default value depending on the header being parsed. The following table summarizes the default values used.

+ + + + + + + + + +
Header nameDefault value
transfer-encoding[<<"identity">>]
Any other headerundefined
+ +

The parsed value differs depending on the header being parsed. The following table summarizes the different types returned.

+ + + + + + + + + + + + + + + + + + + + + + + + + +
Header nameType
accept[{{Type, SubType, Params}, Quality, AcceptExt}]
accept-charset[{Charset, Quality}]
accept-encoding[{Encoding, Quality}]
accept-language[{LanguageTag, Quality}]
authorization{AuthType, Credentials}
content-lengthnon_neg_integer()
content-type{Type, SubType, ContentTypeParams}
cookie[{binary(), binary()}]
expect[Expect | {Expect, ExpectValue, Params}]
if-match'*' | [{weak | strong, OpaqueTag}]
if-modified-sincecalendar:datetime()
if-none-match'*' | [{weak | strong, OpaqueTag}]
if-unmodified-sincecalendar:datetime()
range{Unit, [Range]}
sec-websocket-protocol[binary()]
transfer-encoding[binary()]
upgrade[binary()]
x-forwarded-for[binary()]
+ +

Types for the above table:

+ +
    +
  • Type = SubType = Charset = Encoding = LanguageTag = binary()
    • +
  • AuthType = Expect = OpaqueTag = Unit = binary()
    • +
  • Params = ContentTypeParams = [{binary(), binary()}]
    • +
  • Quality = 0..1000
    • +
  • AcceptExt = [{binary(), binary()} | binary()]
    • +
  • Credentials - see below
    • +
  • Range = {non_neg_integer(), non_neg_integer() | infinity} | neg_integer()
    • +
+ +

The cookie names and values, the values of the sec-websocket-protocol and x-forwarded-for headers, the values in AcceptExt and Params, the authorization Credentials, the ExpectValue and OpaqueTag are case sensitive. All values in ContentTypeParams are case sensitive except the value of the charset parameter, which is case insensitive. All other values are case insensitive and will be returned as lowercase.

+ +

The headers accept, accept-encoding and cookie headers can return an empty list. Others will return {error, badarg} if the header value is empty.

+ +

The authorization header parsing code currently only supports basic HTTP authentication. The Credentials type is thus {Username, Password} with Username and Password being binary().

+ +

The range header value Range can take three forms:

+ +
    +
  • {From, To}: from From to To units
    • +
  • {From, infinity}: everything after From units
    • +
  • -Final: the final Final units
    • +
+ +

An undefined tuple will be returned if Cowboy doesn't know how to parse the requested header.

+ +

path(Req) -> {Path, Req2}

+ +

Types:

+ +
    +
  • Path = binary()
    • +
+ +

Return the requested path.

+ +

path_info(Req) -> {PathInfo, Req2}

+ +

Types:

+ +
    +
  • PathInfo = cowboy_router:tokens() | undefined
    • +
+ +

Return the extra tokens from matching against ... during routing.

+ +

peer(Req) -> {Peer, Req2}

+ +

Types:

+ +
    +
  • Peer = {inet:ip_address(), inet:port_number()}
    • +
+ +

Return the client's IP address and port number.

+ +

port(Req) -> {Port, Req2}

+ +

Types:

+ +
    +
  • Port = inet:port_number()
    • +
+ +

Return the request's port.

+ +

The port returned by this function is obtained by parsing the host header. It may be different than the actual port the client used to connect to the Cowboy server.

+ +

qs(Req) -> {QueryString, Req2}

+ +

Types:

+ +
    +
  • QueryString = binary()
    • +
+ +

Return the request's query string.

+ +

qs_val(Name, Req) -> qs_val(Name, Req, undefined)

+ +

qs_val(Name, Req, Default) -> {Value, Req2}

+ +

Types:

+ +
    +
  • Name = binary()
    • +
  • Default = any()
    • +
  • Value = binary() | true
    • +
+ +

Return a value from the request's query string.

+ +

The value true will be returned when the name was found in the query string without an associated value.

+ +

qs_vals(Req) -> {[{Name, Value}], Req2}

+ +

Types:

+ +
    +
  • Name = binary()
    • +
  • Value = binary() | true
    • +
+ +

Return the request's query string as a list of tuples.

+ +

The value true will be returned when a name was found in the query string without an associated value.

+ +

set_meta(Name, Value, Req) -> Req2

+ +

Types:

+ +
    +
  • Name = atom()
    • +
  • Value = any()
    • +
+ +

Set metadata about the request.

+ +

An existing value will be overwritten.

+ +

url(Req) -> {URL, Req2}

+ +

Types:

+ +
    +
  • URL = binary() | undefined
    • +
+ +

Return the requested URL.

+ +

This function will always return undefined until the cowboy_router middleware has been executed. This includes the onrequest hook.

+ +

version(Req) -> {Version, Req2}

+ +

Types:

+ +
    +
  • Version = cowboy:http_version()
    • +
+ +

Return the HTTP version used for this request.

+ +

Request body related exports

+ +

body(Req) -> body(Req, [])

+ +

body(Req, Opts) -> {ok, Data, Req2} | {more, Data, Req2} | {error, Reason}

+ +

Types:

+ +
    +
  • Opts = [body_opt()]
    • +
  • Data = binary()
    • +
  • Reason = atom()
    • +
+ +

Read the request body.

+ +

This function will read a chunk of the request body. If there is more data to be read after this function call, then a more tuple is returned. Otherwise an ok tuple is returned.

+ +

Cowboy will automatically send a 100 Continue reply if required. If this behavior is not desirable, it can be disabled by setting the continue option to false.

+ +

Cowboy will by default attempt to read up to 8MB of the body, but in chunks of 1MB. It will use a timeout of 15s per chunk. All these values can be changed using the length, read_length and read_timeout options respectively. Note that the size of the data may not be the same as requested as the decoding functions may grow or shrink it, and Cowboy makes not attempt at returning an exact amount.

+ +

Cowboy will properly handle chunked transfer-encoding by default. If any other transfer-encoding or content-encoding has been used for the request, custom decoding functions can be used. The content_decode and transfer_decode options allow setting the decode functions manually.

+ +

After the body has been streamed fully, Cowboy will remove the transfer-encoding header from the Req object, and add the content-length header if it wasn't already there.

+ +

This function can only be called once. Cowboy will not cache the result of this call.

+ +

body_length(Req) -> {Length, Req2}

+ +

Types:

+ +
    +
  • Length = non_neg_integer() | undefined
    • +
+ +

Return the length of the request body.

+ +

The length will only be returned if the request does not use any transfer-encoding and if the content-length header is present.

+ +

body_qs(Req) -> body_qs(Req, [{length, 64000}, {read_length, 64000}, {read_timeout, 5000}])

+ +

body_qs(Req, Opts) -> {ok, [{Name, Value}], Req2} | {badlength, Req2} | {error, Reason}

+ +

Types:

+ +
    +
  • Opts = [body_opt()]
    • +
  • Name = binary()
    • +
  • Value = binary() | true
    • +
  • Reason = chunked | badlength | atom()
    • +
+ +

Return the request body as a list of tuples.

+ +

This function will parse the body assuming the content-type application/x-www-form-urlencoded, commonly used for the query string.

+ +

This function calls body/2 for reading the body, with the same options it received. By default it will attempt to read a body of 64KB in one chunk, with a timeout of 5s. If the body is larger then a badlength tuple is returned.

+ +

This function can only be called once. Cowboy will not cache the result of this call.

+ +

has_body(Req) -> boolean()

+ +

Return whether the request has a body.

+ +

part(Req) -> part(Req, [{length, 64000}, {read_length, 64000}, {read_timeout, 5000}])

+ +

part(Req, Opts) -> {ok, Headers, Req2} | {done, Req2}

+ +

Types:

+ +
    +
  • Opts = [body_opt()]
    • +
  • Headers = cow_multipart:headers()
    • +
+ +

Read the headers for the next part of the multipart message.

+ +

Cowboy will skip any data remaining until the beginning of the next part. This includes the preamble to the multipart message but also the body of a previous part if it hasn't been read. Both are skipped automatically when calling this function.

+ +

The headers returned are MIME headers, NOT HTTP headers. They can be parsed using the functions from the cow_multipart module. In addition, the cow_multipart:form_data/1 function can be used to quickly figure out multipart/form-data messages. It takes the list of headers and returns whether this part is a simple form field or a file being uploaded.

+ +

Note that once a part has been read, or skipped, it cannot be read again.

+ +

This function calls body/2 for reading the body, with the same options it received. By default it will only read chunks of 64KB with a timeout of 5s. This is tailored for reading part headers, not for skipping the previous part's body. You might want to consider skipping large parts manually.

+ +

part_body(Req) -> part_body(Req, [])

+ +

part_body(Req, Opts) -> {ok, Data, Req2} | {more, Data, Req2}

+ +

Types:

+ +
    +
  • Opts = [body_opt()]
    • +
  • Data = binary()
    • +
+ +

Read the body of the current part of the multipart message.

+ +

This function calls body/2 for reading the body, with the same options it received. It uses the same defaults.

+ +

If there are more data to be read from the socket for this part, the function will return what it could read inside a more tuple. Otherwise, it will return an ok tuple.

+ +

Calling this function again after receiving a more tuple will return another chunk of body. The last chunk will be returned inside an ok tuple.

+ +

Note that once the body has been read, fully or partially, it cannot be read again.

+ + + +

chunk(Data, Req) -> ok | {error, Reason}

+ +

Types:

+ +
    +
  • Data = iodata()
    • +
  • Reason = atom()
    • +
+ +

Send a chunk of data.

+ +

This function should be called as many times as needed to send data chunks after calling chunked_reply/{2,3}.

+ +

When the method is HEAD, no data will actually be sent.

+ +

If the request uses HTTP/1.0, the data is sent directly without wrapping it in an HTTP/1.1 chunk, providing compatibility with older clients.

+ +

chunked_reply(StatusCode, Req) -> chunked_reply(StatusCode, [], Req)

+ +

chunked_reply(StatusCode, Headers, Req) -> {ok, Req2}

+ +

Types:

+ +
    +
  • StatusCode = cowboy:http_status()
    • +
  • Headers = cowboy:http_headers()
    • +
+ +

Send a response using chunked transfer-encoding.

+ +

This function effectively sends the response status line and headers to the client.

+ +

This function will not send any body set previously. After this call the handler must use the chunk/2 function repeatedly to send the body in as many chunks as needed.

+ +

If the request uses HTTP/1.0, the data is sent directly without wrapping it in an HTTP/1.1 chunk, providing compatibility with older clients.

+ +

This function can only be called once, with the exception of overriding the response in the onresponse hook.

+ +

continue(Req) -> ok | {error, Reason}

+ +

Types:

+ +
    +
  • Reason = atom()
    • +
+ +

Send a 100 Continue intermediate reply.

+ +

This reply is required before the client starts sending the body when the request contains the expect header with the 100-continue value.

+ +

Cowboy will send this automatically when required. However you may want to do it manually by disabling this behavior with the continue body option and then calling this function.

+ +

delete_resp_header(Name, Req) -> Req2

+ +

Types:

+ +
    +
  • Name = binary()
    • +
+ +

Delete the given response header.

+ +

While header names are case insensitive, this function expects the name to be a lowercase binary.

+ +

has_resp_body(Req) -> boolean()

+ +

Return whether a response body has been set.

+ +

This function will return false if a response body has been set with a length of 0.

+ +

has_resp_header(Name, Req) -> boolean()

+ +

Types:

+ +
    +
  • Name = binary()
    • +
+ +

Return whether the given response header has been set.

+ +

While header names are case insensitive, this function expects the name to be a lowercase binary.

+ +

reply(StatusCode, Req) -> reply(StatusCode, [], Req)

+ +

reply(StatusCode, Headers, Req) - see below

+ +

reply(StatusCode, Headers, Body, Req) -> {ok, Req2}

+ +

Types:

+ +
    +
  • StatusCode = cowboy:http_status()
    • +
  • Headers = cowboy:http_headers()
    • +
  • Body = iodata()
    • +
+ +

Send a response.

+ +

This function effectively sends the response status line, headers and body to the client, in a single send function call.

+ +

The reply/2 and reply/3 functions will send the body set previously, if any. The reply/4 function overrides any body set previously and sends Body instead.

+ +

If a body function was set, and reply/2 or reply/3 was used, it will be called before returning.

+ +

No more data can be sent to the client after this function returns.

+ +

This function can only be called once, with the exception of overriding the response in the onresponse hook.

+ +

set_resp_body(Body, Req) -> Req2

+ +

Types:

+ +
    +
  • Body = iodata()
    • +
+ +

Set a response body.

+ +

This body will not be sent if chunked_reply/{2,3} or reply/4 is used, as they override it.

+ +

set_resp_body_fun(Fun, Req) -> Req2

+ +

set_resp_body_fun(Length, Fun, Req) -> Req2

+ +

Types:

+ +
    +
  • Fun = fun((Socket, Transport) -> ok)
    • +
  • Socket = inet:socket()
    • +
  • Transport = module()
    • +
  • Length = non_neg_integer()
    • +
+ +

Set a fun for sending the response body.

+ +

If a Length is provided, it will be sent in the content-length header in the response. It is recommended to set the length if it can be known in advance. Otherwise, the transfer-encoding header will be set to identity.

+ +

This function will only be called if the response is sent using the reply/2 or reply/3 function.

+ +

The fun will receive the Ranch Socket and Transport as arguments. Only send and sendfile operations are supported.

+ +

set_resp_body_fun(chunked, Fun, Req) -> Req2

+ +

Types:

+ +
    +
  • Fun = fun((ChunkFun) -> ok)
    • +
  • ChunkFun = fun((iodata()) -> ok | {error, atom()})
    • +
+ +

Set a fun for sending the response body using chunked transfer-encoding.

+ +

This function will only be called if the response is sent using the reply/2 or reply/3 function.

+ +

The fun will receive another fun as argument. This fun is to be used to send chunks in a similar way to the chunk/2 function, except the fun only takes one argument, the data to be sent in the chunk.

+ + + +

Types:

+ +
    +
  • Name = iodata()
    • +
  • Value = iodata()
    • +
  • Opts = cookie_opts()
    • +
+ +

Set a cookie in the response.

+ +

Cookie names are case sensitive.

+ +

set_resp_header(Name, Value, Req) -> Req2

+ +

Types:

+ +
    +
  • Name = binary()
    • +
  • Value = iodata()
    • +
+ +

Set a response header.

+ +

You should use set_resp_cookie/4 instead of this function to set cookies.

+ +

Misc. exports

+ +

compact(Req) -> Req2

+ +

Remove any non-essential data from the Req object.

+ +

Long-lived connections usually only need to manipulate the Req object at initialization. Compacting allows saving up memory by discarding extraneous information.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_rest/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_rest/index.html new file mode 100644 index 00000000..31af54c0 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_rest/index.html @@ -0,0 +1,698 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_rest

+ +

The cowboy_rest module implements REST semantics on top of the HTTP protocol.

+ +

This module cannot be described as a behaviour due to most of the callbacks it defines being optional. It has the same semantics as a behaviour otherwise.

+ +

The only mandatory callback is init/3, needed to perform the protocol upgrade.

+ +

Types

+ +

None.

+ +

Meta values

+ +

charset

+ +

Type: binary()

+ +

Negotiated charset.

+ +

This value may not be defined if no charset was negotiated.

+ +

language

+ +

Type: binary()

+ +

Negotiated language.

+ +

This value may not be defined if no language was negotiated.

+ +

media_type

+ +

Type: {binary(), binary(), '*' | [{binary(), binary()}]}

+ +

Negotiated media-type.

+ +

The media-type is the content-type, excluding the charset.

+ +

This value is always defined after the call to content_types_provided/2.

+ +

Callbacks

+ +

init({TransportName, ProtocolName}, Req, Opts) -> {upgrade, protocol, cowboy_rest} | {upgrade, protocol, cowboy_rest, Req, Opts}

+ +

Types:

+ +
    +
  • TransportName = tcp | ssl | atom()
    • +
  • ProtocolName = http | atom()
    • +
  • Req = cowboy_req:req()
    • +
  • Opts = any()
    • +
+ +

Upgrade the protocol to cowboy_rest.

+ +

This is the only mandatory callback.

+ +

rest_init(Req, Opts) -> {ok, Req, State}

+ +

Types:

+ +
    +
  • Req = cowboy_req:req()
    • +
  • Opts = any()
    • +
  • State = any()
    • +
+ +

Initialize the state for this request.

+ +

rest_terminate(Req, State) -> ok

+ +

Types:

+ +
    +
  • Req = cowboy_req:req()
    • +
  • State = any()
    • +
+ +

Perform any necessary cleanup of the state.

+ +

This callback should release any resource currently in use, clear any active timer and reset the process to its original state, as it might be reused for future requests sent on the same connection.

+ +

Callback(Req, State) -> {Value, Req, State} | {halt, Req, State}

+ +

Types:

+ +
    +
  • Callback - one of the REST callbacks described below
    • +
  • Req = cowboy_req:req()
    • +
  • State = any()
    • +
  • Value - see the REST callbacks description below
    • +
+ +

Please see the REST callbacks description below for details on the Value type, the default value if the callback is not defined, and more general information on when the callback is called and what its intended use is.

+ +

The halt tuple can be returned to stop REST processing. It is up to the resource code to send a reply before that, otherwise a 204 No Content will be sent.

+ +

REST callbacks description

+ +

allowed_methods

+ +
    +
  • Methods: all
    • +
  • Value type: [binary()]
    • +
  • Default value: [<<"GET">>, <<"HEAD">>, <<"OPTIONS">>]
    • +
+ +

Return the list of allowed methods.

+ +

Methods are case sensitive. Standard methods are always uppercase.

+ +

allow_missing_post

+ +
    +
  • Methods: POST
    • +
  • Value type: boolean()
    • +
  • Default value: true
    • +
+ +

Return whether POST is allowed when the resource doesn't exist.

+ +

Returning true here means that a new resource will be created. The URL to the created resource should also be returned from the AcceptResource callback.

+ +

charsets_provided

+ +
    +
  • Methods: GET, HEAD, POST, PUT, PATCH, DELETE
    • +
  • Value type: [binary()]
    • +
  • Skip to the next step if undefined
    • +
+ +

Return the list of charsets the resource provides.

+ +

The list must be ordered in order of preference.

+ +

If the accept-charset header was not sent, the first charset in the list will be selected. Otherwise Cowboy will select the most appropriate charset from the list.

+ +

The chosen charset will be set in the Req object as the meta value charset.

+ +

While charsets are case insensitive, this callback is expected to return them as lowercase binary.

+ +

content_types_accepted

+ +
    +
  • Methods: POST, PUT, PATCH
    • +
  • No default
    • +
+ +

Types:

+ +
    +
  • Value = [{binary() | {Type, SubType, Params}, AcceptResource}]
    • +
  • Type = SubType = binary()
    • +
  • Params = '*' | [{binary(), binary()}]
    • +
  • AcceptResource = atom()
    • +
+ +

Return the list of content-types the resource accepts.

+ +

The list must be ordered in order of preference.

+ +

Each content-type can be given either as a binary string or as a tuple containing the type, subtype and parameters.

+ +

Cowboy will select the most appropriate content-type from the list. If any parameter is acceptable, then the tuple form should be used with parameters set to '*'. If the parameters value is set to [] only content-type values with no parameters will be accepted. All parameter values are treated in a case sensitive manner except the charset parameter, if present, which is case insensitive.

+ +

This function will be called for POST, PUT and PATCH requests. It is entirely possible to define different callbacks for different methods if the handling of the request differs. Simply verify what the method is with cowboy_req:method/1 and return a different list for each methods.

+ +

The AcceptResource value is the name of the callback that will be called if the content-type matches. It is defined as follow.

+ +
    +
  • Value type: true | {true, URL} | false
    • +
  • No default
    • +
+ +

Process the request body.

+ +

This function should create or update the resource with the information contained in the request body. This information may be full or partial depending on the request method.

+ +

If the request body was processed successfully, true must be returned. If the request method is POST, {true, URL} may be returned instead, and Cowboy will redirect the client to the location of the newly created resource.

+ +

If a response body must be sent, the appropriate media-type, charset and language can be retrieved using the cowboy_req:meta/{2,3} functions. The respective keys are media_type, charset and language. The body can be set using cowboy_req:set_resp_body/2.

+ +

content_types_provided

+ +
    +
  • Methods: GET, HEAD, POST, PUT, PATCH, DELETE
    • +
  • Default value: [{{<<"text">>, <<"html">>, '*'}, to_html}]
    • +
+ +

Types:

+ +
    +
  • Value = [{binary() | {Type, SubType, Params}, ProvideResource}]
    • +
  • Type = SubType = binary()
    • +
  • Params = '*' | [{binary(), binary()}]
    • +
  • ProvideResource = atom()
    • +
+ +

Return the list of content-types the resource provides.

+ +

The list must be ordered in order of preference.

+ +

Each content-type can be given either as a binary string or as a tuple containing the type, subtype and parameters.

+ +

Cowboy will select the most appropriate content-type from the list. If any parameter is acceptable, then the tuple form should be used with parameters set to '*'. If the parameters value is set to [] only content-type values with no parameters will be accepted. All parameter values are treated in a case sensitive manner except the charset parameter, if present, which is case insensitive.

+ +

The ProvideResource value is the name of the callback that will be called if the content-type matches. It will only be called when a representation of the resource needs to be returned. It is defined as follow.

+ +
    +
  • Methods: GET, HEAD
    • +
  • Value type: iodata() | {stream, Fun} | {stream, Len, Fun} | {chunked, ChunkedFun}
    • +
  • No default
    • +
+ +

Return the response body.

+ +

The response body may be provided directly or through a fun. If a fun tuple is returned, the appropriate set_resp_body_fun function will be called. Please refer to the documentation for these functions for more information about the types.

+ +

The call to this callback happens a good time after the call to content_types_provided/2, when it is time to start rendering the response body.

+ +

delete_completed

+ +
    +
  • Methods: DELETE
    • +
  • Value type: boolean()
    • +
  • Default value: true
    • +
+ +

Return whether the delete action has been completed.

+ +

This function should return false if there is no guarantee that the resource gets deleted immediately from the system, including from any internal cache.

+ +

When this function returns false, a 202 Accepted response will be sent instead of a 200 OK or 204 No Content.

+ +

delete_resource

+ +
    +
  • Methods: DELETE
    • +
  • Value type: boolean()
    • +
  • Default value: false
    • +
+ +

Delete the resource.

+ +

The value returned indicates if the action was successful, regardless of whether the resource is immediately deleted from the system.

+ +

expires

+ +
    +
  • Methods: GET, HEAD
    • +
  • Value type: calendar:datetime() | binary() | undefined
    • +
  • Default value: undefined
    • +
+ +

Return the date of expiration of the resource.

+ +

This date will be sent as the value of the expires header.

+ +

forbidden

+ +
    +
  • Methods: all
    • +
  • Value type: boolean()
    • +
  • Default value: false
    • +
+ +

Return whether access to the resource is forbidden.

+ +

A 403 Forbidden response will be sent if this function returns true. This status code means that access is forbidden regardless of authentication, and that the request shouldn't be repeated.

+ +

generate_etag

+ +
    +
  • Methods: GET, HEAD, POST, PUT, PATCH, DELETE
    • +
  • Value type: binary() | {weak | strong, binary()}
    • +
  • Default value: undefined
    • +
+ +

Return the entity tag of the resource.

+ +

This value will be sent as the value of the etag header.

+ +

If a binary is returned, then the value will be parsed to the tuple form automatically. The value must be in the same format as the etag header, including quotes.

+ +

is_authorized

+ +
    +
  • Methods: all
    • +
  • Value type: true | {false, AuthHeader}
    • +
  • Default value: true
    • +
+ +

Return whether the user is authorized to perform the action.

+ +

This function should be used to perform any necessary authentication of the user before attempting to perform any action on the resource.

+ +

If the authentication fails, the value returned will be sent as the value for the www-authenticate header in the 401 Unauthorized response.

+ +

is_conflict

+ +
    +
  • Methods: PUT
    • +
  • Value type: boolean()
    • +
  • Default value: false
    • +
+ +

Return whether the put action results in a conflict.

+ +

A 409 Conflict response will be sent if this function returns true.

+ +

known_content_type

+ +
    +
  • Methods: all
    • +
  • Value type: boolean()
    • +
  • Default value: true
    • +
+ +

Return whether the content-type is known.

+ +

This function determines if the server understands the content-type, regardless of its use by the resource.

+ +

known_methods

+ +
    +
  • Methods: all
    • +
  • Value type: [binary()]
    • +
  • Default value: [<<"GET">>, <<"HEAD">>, <<"POST">>, <<"PUT">>, <<"PATCH">>, <<"DELETE">>, <<"OPTIONS">>]
    • +
+ +

Return the list of known methods.

+ +

The full list of methods known by the server should be returned, regardless of their use in the resource.

+ +

The default value lists the methods Cowboy knows and implement in cowboy_rest.

+ +

Methods are case sensitive. Standard methods are always uppercase.

+ +

languages_provided

+ +
    +
  • Methods: GET, HEAD, POST, PUT, PATCH, DELETE
    • +
  • Value type: [binary()]
    • +
  • Skip to the next step if undefined
    • +
+ +

Return the list of languages the resource provides.

+ +

The list must be ordered in order of preference.

+ +

If the accept-language header was not sent, the first language in the list will be selected. Otherwise Cowboy will select the most appropriate language from the list.

+ +

The chosen language will be set in the Req object as the meta value language.

+ +

While languages are case insensitive, this callback is expected to return them as lowercase binary.

+ +

last_modified

+ +
    +
  • Methods: GET, HEAD, POST, PUT, PATCH, DELETE
    • +
  • Value type: calendar:datetime()
    • +
  • Default value: undefined
    • +
+ +

Return the date of last modification of the resource.

+ +

This date will be used to test against the if-modified-since and if-unmodified-since headers, and sent as the last-modified header in the response of GET and HEAD requests.

+ +

malformed_request

+ +
    +
  • Methods: all
    • +
  • Value type: boolean()
    • +
  • Default value: false
    • +
+ +

Return whether the request is malformed.

+ +

Cowboy has already performed all the necessary checks by the time this function is called, so few resources are expected to implement it.

+ +

The check is to be done on the request itself, not on the request body, which is processed later.

+ +

moved_permanently

+ +
    +
  • Methods: GET, HEAD, POST, PUT, PATCH, DELETE
    • +
  • Value type: {true, URL} | false
    • +
  • Default value: false
    • +
+ +

Return whether the resource was permanently moved.

+ +

If it was, its new URL is also returned and sent in the location header in the response.

+ +

moved_temporarily

+ +
    +
  • Methods: GET, HEAD, POST, PATCH, DELETE
    • +
  • Value type: {true, URL} | false
    • +
  • Default value: false
    • +
+ +

Return whether the resource was temporarily moved.

+ +

If it was, its new URL is also returned and sent in the location header in the response.

+ +

multiple_choices

+ +
    +
  • Methods: GET, HEAD, POST, PUT, PATCH, DELETE
    • +
  • Value type: boolean()
    • +
  • Default value: false
    • +
+ +

Return whether there are multiple representations of the resource.

+ +

This function should be used to inform the client if there are different representations of the resource, for example different content-type. If this function returns true, the response body should include information about these different representations using cowboy_req:set_resp_body/2. The content-type of the response should be the one previously negociated and that can be obtained by calling cowboy_req:meta(media_type, Req).

+ +

options

+ +
    +
  • Methods: OPTIONS
    • +
  • Value type: ok
    • +
  • Default value: ok
    • +
+ +

Handle a request for information.

+ +

The response should inform the client the communication options available for this resource.

+ +

By default, Cowboy will send a 200 OK response with the allow header set.

+ +

previously_existed

+ +
    +
  • Methods: GET, HEAD, POST, PATCH, DELETE
    • +
  • Value type: boolean()
    • +
  • Default value: false
    • +
+ +

Return whether the resource existed previously.

+ +

resource_exists

+ +
    +
  • Methods: GET, HEAD, POST, PUT, PATCH, DELETE
    • +
  • Value type: boolean()
    • +
  • Default value: true
    • +
+ +

Return whether the resource exists.

+ +

If it exists, conditional headers will be tested before attempting to perform the action. Otherwise, Cowboy will check if the resource previously existed first.

+ +

service_available

+ +
    +
  • Methods: all
    • +
  • Value type: boolean()
    • +
  • Default value: true
    • +
+ +

Return whether the service is available.

+ +

This function can be used to test that all relevant backend systems are up and able to handle requests.

+ +

A 503 Service Unavailable response will be sent if this function returns false.

+ +

uri_too_long

+ +
    +
  • Methods: all
    • +
  • Value type: boolean()
    • +
  • Default value: false
    • +
+ +

Return whether the requested URI is too long.

+ +

Cowboy has already performed all the necessary checks by the time this function is called, so few resources are expected to implement it.

+ +

A 414 Request-URI Too Long response will be sent if this function returns true.

+ +

valid_content_headers

+ +
    +
  • Methods: all
    • +
  • Value type: boolean()
    • +
  • Default value: true
    • +
+ +

Return whether the content-* headers are valid.

+ +

This also applies to the transfer-encoding header. This function must return false for any unknown content-* headers, or if the headers can't be understood. The function cowboy_req:parse_header/2 can be used to quickly check the headers can be parsed.

+ +

A 501 Not Implemented response will be sent if this function returns false.

+ +

valid_entity_length

+ +
    +
  • Methods: all
    • +
  • Value type: boolean()
    • +
  • Default value: true
    • +
+ +

Return whether the request body length is within acceptable boundaries.

+ +

A 413 Request Entity Too Large response will be sent if this function returns false.

+ +

variances

+ +
    +
  • Methods: GET, HEAD, POST, PUT, PATCH, DELETE
    • +
  • Value type: [binary()]
    • +
  • Default value: []
    • +
+ +

Return the list of headers that affect the representation of the resource.

+ +

These request headers return the same resource but with different parameters, like another language or a different content-type.

+ +

Cowboy will automatically add the accept, accept-language and accept-charset headers to the list if the respective functions were defined in the resource.

+ +

This operation is performed right before the resource_exists/2 callback. All responses past that point will contain the vary header which holds this list.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_router/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_router/index.html new file mode 100644 index 00000000..fd191650 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_router/index.html @@ -0,0 +1,247 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_router

+ +

The cowboy_router middleware maps the requested host and path to the handler to be used for processing the request. It uses the dispatch rules compiled from the routes given to the compile/1 function for this purpose. It adds the handler name and options to the environment as the values handler and handler_opts respectively.

+ +

Environment input:

+ +
    +
  • dispatch = dispatch_rules()
    • +
+ +

Environment output:

+ +
    +
  • handler = module()
    • +
  • handler_opts = any()
    • +
+ +

Types

+ +

bindings() = [{atom(), binary()}]

+ +

List of bindings found during routing.

+ +

constraints() = [IntConstraint | FunConstraint]

+ +

Types:

+ +
    +
  • IntConstraint = {atom(), int}
    • +
  • FunConstraint = {atom(), function, Fun}
    • +
  • Fun = fun((binary()) -> true | {true, any()} | false)
    • +
+ +

List of constraints to apply to the bindings.

+ +

The int constraint will convert the binding to an integer. The fun constraint allows writing custom code for checking the bindings. Returning a new value from that fun allows replacing the current binding with a new value.

+ +

dispatch_rules() - opaque to the user

+ +

Rules for dispatching request used by Cowboy.

+ +

routes() = [{Host, Paths} | {Host, constraints(), Paths}]

+ +

Types:

+ +
    +
  • Host = Path = '_' | iodata()
    • +
  • Paths = [{Path, Handler, Opts} | {Path, constraints(), Handler, Opts}]
    • +
  • Handler = module()
    • +
  • Opts = any()
    • +
+ +

Human readable list of routes mapping hosts and paths to handlers.

+ +

The syntax for routes is defined in the user guide.

+ +

tokens() = [binary()]

+ +

List of host_info and path_info tokens found during routing.

+ +

Exports

+ +

compile(Routes) -> Dispatch

+ +

Types:

+ +
    +
  • Routes = routes()
    • +
  • Dispatch = dispatch_rules()
    • +
+ +

Compile the routes for use by Cowboy.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_spdy/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_spdy/index.html new file mode 100644 index 00000000..39f0611c --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_spdy/index.html @@ -0,0 +1,212 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_spdy

+ +

The cowboy_spdy module implements SPDY/3 as a Ranch protocol.

+ +

Types

+ +

opts() = [{env, cowboy_middleware:env()} | {middlewares, [module()]} | {onrequest, cowboy:onrequest_fun()} | {onresponse, cowboy:onresponse_fun()}]

+ +

Configuration for the SPDY protocol handler.

+ +

This configuration is passed to Cowboy when starting listeners using the cowboy:start_spdy/4 function.

+ +

It can be updated without restarting listeners using the Ranch functions ranch:get_protocol_options/1 and ranch:set_protocol_options/2.

+ +

Option descriptions

+ +

The default value is given next to the option name.

+ +

env ([{listener, Ref}])

+ +

Initial middleware environment.

+ +

middlewares ([cowboy_router, cowboy_handler])

+ +

List of middlewares to execute for every requests.

+ +

onrequest (undefined)

+ +

Fun called every time a request is received.

+ +

onresponse (undefined)

+ +

Fun called every time a response is sent.

+ +

Exports

+ +

None.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_static/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_static/index.html new file mode 100644 index 00000000..8d6dd8a5 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_static/index.html @@ -0,0 +1,194 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_static

+ +

The cowboy_static module implements file serving capabilities by using the REST semantics provided by cowboy_rest.

+ +

Types

+ +

opts() = {priv_file, atom(), string() | binary()} | {priv_file, atom(), string() | binary(), extra()} | {file, string() | binary()} | {file, string() | binary(), extra()} | {priv_dir, atom(), string() | binary()} | {priv_dir, atom(), string() | binary(), extra()} | {dir, string() | binary()} | {dir, string() | binary(), extra()}

+ +

Configuration for the static handler.

+ +

The handler can be configured for sending either one file or a directory (including its subdirectories).

+ +

Extra options allow you to define how the etag should be calculated and how the mimetype of files should be detected. They are defined as follow, but do note that these types are not exported, only the opts/0 type is public.

+ +

extra() = [extra_etag() | extra_mimetypes()]

+ +

extra_etag() = {etag, module(), function()} | {etag, false}

+ +

extra_mimetypes() = {mimetypes, module(), function()} | {mimetypes, binary() | {binary(), binary(), [{binary(), binary()}]}}

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_sub_protocol/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_sub_protocol/index.html new file mode 100644 index 00000000..53b52bd4 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_sub_protocol/index.html @@ -0,0 +1,203 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_sub_protocol

+ +

The cowboy_sub_protocol behaviour defines the interface used by modules that implement a protocol on top of HTTP.

+ +

Types

+ +

None.

+ +

Callbacks

+ +

upgrade(Req, Env, Handler, Opts) -> {ok, Req, Env} | {suspend, Module, Function, Args} | {halt, Req} | {error, StatusCode, Req}

+ +

Types:

+ +
    +
  • Req = cowboy_req:req()
    • +
  • Env = env()
    • +
  • Handler = module()
    • +
  • Opts = any()
    • +
  • Module = module()
    • +
  • Function = atom()
    • +
  • Args = [any()]
    • +
  • StatusCode = cowboy:http_status()
    • +
+ +

Upgrade the protocol.

+ +

Please refer to the cowboy_middleware manual for a description of the return values.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_websocket/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_websocket/index.html new file mode 100644 index 00000000..e05e9829 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_websocket/index.html @@ -0,0 +1,208 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_websocket

+ +

The cowboy_websocket module implements the Websocket protocol.

+ +

The callbacks for websocket handlers are defined in the manual for the cowboy_websocket_handler behaviour.

+ +

Types

+ +

close_code() = 1000..4999

+ +

Reason for closing the connection.

+ +

frame() = close | ping | pong | {text | binary | close | ping | pong, iodata()} | {close, close_code(), iodata()}

+ +

Frames that can be sent to the client.

+ +

Meta values

+ +

websocket_compress

+ +

Type: true | false

+ +

Whether a websocket compression extension in in use.

+ +

websocket_version

+ +

Type: 7 | 8 | 13

+ +

The version of the Websocket protocol being used.

+ +

Exports

+ +

None.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/cowboy_websocket_handler/index.html b/_build/static/docs/en/cowboy/1.0/manual/cowboy_websocket_handler/index.html new file mode 100644 index 00000000..62ddd89a --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/cowboy_websocket_handler/index.html @@ -0,0 +1,273 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

cowboy_websocket_handler

+ +

The cowboy_websocket_handler behaviour defines the interface used by Websocket handlers.

+ +

The init/3 and websocket_init/3 callbacks will always be called, followed by zero or more calls to websocket_handle/3 and websocket_info/3. The websocket_terminate/3 will always be called last.

+ +

Types

+ +

None.

+ +

Callbacks

+ +

init({TransportName, ProtocolName}, Req, Opts) -> {upgrade, protocol, cowboy_websocket} | {upgrade, protocol, cowboy_websocket, Req, Opts}

+ +

Types:

+ +
    +
  • TransportName = tcp | ssl | atom()
    • +
  • ProtocolName = http | atom()
    • +
  • Req = cowboy_req:req()
    • +
  • Opts = any()
    • +
+ +

Upgrade the protocol to cowboy_websocket.

+ +

websocket_init(TransportName, Req, Opts) -> {ok, Req, State} | {ok, Req, State, hibernate} | {ok, Req, State, Timeout} | {ok, Req, State, Timeout, hibernate} | {shutdown, Req}

+ +

Types:

+ +
    +
  • TransportName = tcp | ssl | atom()
    • +
  • Req = cowboy_req:req()
    • +
  • Opts = any()
    • +
  • State = any()
    • +
  • Timeout = timeout()
    • +
+ +

Initialize the state for this session.

+ +

This function is called before the upgrade to Websocket occurs. It can be used to negotiate Websocket protocol extensions with the client. It will typically be used to register this process to an event manager or a message queue in order to receive the messages the handler wants to process.

+ +

The connection will stay up for a duration of up to Timeout milliseconds after it last received data from the socket, at which point it will stop and close the connection. By default this value is set to infinity. It is recommended to either set this value or ensure by any other mechanism that the handler will be closed after a certain period of inactivity.

+ +

The hibernate option will hibernate the process until it starts receiving either data from the Websocket connection or Erlang messages.

+ +

The shutdown return value can be used to close the connection before upgrading to Websocket.

+ +

websocket_handle(InFrame, Req, State) -> {ok, Req, State} | {ok, Req, State, hibernate} | {reply, OutFrame | [OutFrame], Req, State} | {reply, OutFrame | [OutFrame], Req, State, hibernate} | {shutdown, Req, State}

+ +

Types:

+ +
    +
  • InFrame = {text | binary | ping | pong, binary()}
    • +
  • Req = cowboy_req:req()
    • +
  • State = any()
    • +
  • OutFrame = cowboy_websocket:frame()
    • +
+ +

Handle the data received from the Websocket connection.

+ +

This function will be called every time data is received from the Websocket connection.

+ +

The shutdown return value can be used to close the connection. A close reply will also result in the connection being closed.

+ +

The hibernate option will hibernate the process until it receives new data from the Websocket connection or an Erlang message.

+ +

websocket_info(Info, Req, State) -> {ok, Req, State} | {ok, Req, State, hibernate} | {reply, OutFrame | [OutFrame], Req, State} | {reply, OutFrame | [OutFrame], Req, State, hibernate} | {shutdown, Req, State}

+ +

Types:

+ +
    +
  • Info = any()
    • +
  • Req = cowboy_req:req()
    • +
  • State = any()
    • +
  • OutFrame = cowboy_websocket:frame()
    • +
+ +

Handle the Erlang message received.

+ +

This function will be called every time an Erlang message has been received. The message can be any Erlang term.

+ +

The shutdown return value can be used to close the connection. A close reply will also result in the connection being closed.

+ +

The hibernate option will hibernate the process until it receives another message or new data from the Websocket connection.

+ +

websocket_terminate(Reason, Req, State) -> ok

+ +

Types:

+ +
    +
  • Reason = {normal, shutdown | timeout} | {remote, closed} | {remote, cowboy_websocket:close_code(), binary()} | {error, badencoding | badframe | closed | atom()}
    • +
  • Req = cowboy_req:req()
    • +
  • State = any()
    • +
+ +

Perform any necessary cleanup of the state.

+ +

The connection will be closed and the process stopped right after this call.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/http_status_codes/index.html b/_build/static/docs/en/cowboy/1.0/manual/http_status_codes/index.html new file mode 100644 index 00000000..d668474f --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/http_status_codes/index.html @@ -0,0 +1,305 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+
+ +

HTTP status codes

+ +

This chapter aims to list all HTTP status codes that Cowboy may return, with details on the reasons why. The list given here only includes the replies that Cowboy sends, not user replies.

+ +

100 Continue

+ +

When the client sends an expect: 100-continue header, Cowboy automatically sends a this status code before trying to read the request body. This behavior can be disabled using the appropriate body option.

+ +

101 Switching Protocols

+ +

This is the status code sent when switching to the Websocket protocol.

+ +

200 OK

+ +

This status code is sent by cowboy_rest.

+ +

201 Created

+ +

This status code is sent by cowboy_rest.

+ +

202 Accepted

+ +

This status code is sent by cowboy_rest.

+ +

204 No Content

+ +

This status code is sent when the processing of a request ends without any reply having been sent. It may also be sent by cowboy_rest under normal conditions.

+ +

300 Multiple Choices

+ +

This status code is sent by cowboy_rest.

+ +

301 Moved Permanently

+ +

This status code is sent by cowboy_rest.

+ +

303 See Other

+ +

This status code is sent by cowboy_rest.

+ +

304 Not Modified

+ +

This status code is sent by cowboy_rest.

+ +

307 Temporary Redirect

+ +

This status code is sent by cowboy_rest.

+ +

400 Bad Request

+ +

Cowboy will send this status code for any of the following reasons:

+ +
    +
  • Too many empty lines were sent before the request.
    • +
  • The request-line could not be parsed.
    • +
  • Too many headers were sent.
    • +
  • A header name was too long.
    • +
  • A header value was too long.
    • +
  • The host header was missing from an HTTP/1.1 request.
    • +
  • The host header could not be parsed.
    • +
  • The requested host was not found.
    • +
  • The requested path could not be parsed.
    • +
  • The accept header could not be parsed when using REST.
    • +
  • REST under normal conditions.
    • +
  • A Websocket upgrade failed.
    • +
+ +

401 Unauthorized

+ +

This status code is sent by cowboy_rest.

+ +

403 Forbidden

+ +

This status code is sent by cowboy_rest.

+ +

404 Not Found

+ +

This status code is sent when the router successfully resolved the host but didn't find a matching path for the request. It may also be sent by cowboy_rest under normal conditions.

+ +

405 Method Not Allowed

+ +

This status code is sent by cowboy_rest.

+ +

406 Not Acceptable

+ +

This status code is sent by cowboy_rest.

+ +

408 Request Timeout

+ +

Cowboy will send this status code to the client if the client started to send a request, indicated by the request-line being received fully, but failed to send all headers in a reasonable time.

+ +

409 Conflict

+ +

This status code is sent by cowboy_rest.

+ +

410 Gone

+ +

This status code is sent by cowboy_rest.

+ +

412 Precondition Failed

+ +

This status code is sent by cowboy_rest.

+ +

413 Request Entity Too Large

+ +

This status code is sent by cowboy_rest.

+ +

414 Request-URI Too Long

+ +

Cowboy will send this status code to the client if the request-line is too long. It may also be sent by cowboy_rest under normal conditions.

+ +

415 Unsupported Media Type

+ +

This status code is sent by cowboy_rest.

+ +

500 Internal Server Error

+ +

This status code is sent when a crash occurs in HTTP, loop or REST handlers, or when an invalid return value is returned. It may also be sent by cowboy_rest under normal conditions.

+ +

501 Not Implemented

+ +

This status code is sent by cowboy_rest.

+ +

503 Service Unavailable

+ +

This status code is sent by cowboy_rest.

+ +

505 HTTP Version Not Supported

+ +

Cowboy only supports the versions 1.0 and 1.1 of HTTP. In all other cases this status code is sent back to the client and the connection is closed.

+ + + +
+ +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/docs/en/cowboy/1.0/manual/index.html b/_build/static/docs/en/cowboy/1.0/manual/index.html new file mode 100644 index 00000000..b5b11489 --- /dev/null +++ b/_build/static/docs/en/cowboy/1.0/manual/index.html @@ -0,0 +1,197 @@ + + + + + Nine Nines Support: Cowboy Function Reference + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+

99s

+
+
+ +
+ + +
+
+
+
+ + +
+ + +
+
+
+ + +
+
+ +
+ +

Navigation

+ +

See also

+ +

Version select

+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + diff --git a/_build/static/res/erlanger-preview.pdf b/_build/static/res/erlanger-preview.pdf new file mode 100644 index 00000000..33fc7c18 Binary files /dev/null and b/_build/static/res/erlanger-preview.pdf differ diff --git a/_build/static/res/tictactoe.erl b/_build/static/res/tictactoe.erl new file mode 100644 index 00000000..abbc78e0 --- /dev/null +++ b/_build/static/res/tictactoe.erl @@ -0,0 +1,89 @@ +-module(tictactoe). + +-export([new/0]). +-export([play/4]). +-export([check/1]). + +new() -> + {undefined, undefined, undefined, + undefined, undefined, undefined, + undefined, undefined, undefined}. + +play(Who, X, Y, Board) -> + setelement((Y - 1) * 3 + X, Board, Who). + +check(Board) -> + case Board of + {x, x, x, + _, _, _, + _, _, _} -> {victory, x}; + + {_, _, _, + x, x, x, + _, _, _} -> {victory, x}; + + {_, _, _, + _, _, _, + x, x, x} -> {victory, x}; + + {x, _, _, + x, _, _, + x, _, _} -> {victory, x}; + + {_, x, _, + _, x, _, + _, x, _} -> {victory, x}; + + {_, _, x, + _, _, x, + _, _, x} -> {victory, x}; + + {x, _, _, + _, x, _, + _, _, x} -> {victory, x}; + + {_, _, x, + _, x, _, + x, _, _} -> {victory, x}; + + {o, o, o, + _, _, _, + _, _, _} -> {victory, o}; + + {_, _, _, + o, o, o, + _, _, _} -> {victory, o}; + + {_, _, _, + _, _, _, + o, o, o} -> {victory, o}; + + {o, _, _, + o, _, _, + o, _, _} -> {victory, o}; + + {_, o, _, + _, o, _, + _, o, _} -> {victory, o}; + + {_, _, o, + _, _, o, + _, _, o} -> {victory, o}; + + {o, _, _, + _, o, _, + _, _, o} -> {victory, o}; + + {_, _, o, + _, o, _, + o, _, _} -> {victory, o}; + + {A, B, C, + D, E, F, + G, H, I} when A =/= undefined, B =/= undefined, C =/= undefined, + D =/= undefined, E =/= undefined, F =/= undefined, + G =/= undefined, H =/= undefined, I =/= undefined -> + draw; + + _ -> ok + end. diff --git a/_build/static/talks/PDF/cowboy.pdf b/_build/static/talks/PDF/cowboy.pdf new file mode 100644 index 00000000..049b2e49 Binary files /dev/null and b/_build/static/talks/PDF/cowboy.pdf differ diff --git a/_build/static/talks/PDF/sheriff.pdf b/_build/static/talks/PDF/sheriff.pdf new file mode 100644 index 00000000..ee954482 Binary files /dev/null and b/_build/static/talks/PDF/sheriff.pdf differ diff --git a/_build/static/talks/bed/bed.ezdoc b/_build/static/talks/bed/bed.ezdoc new file mode 100644 index 00000000..0b36513d --- /dev/null +++ b/_build/static/talks/bed/bed.ezdoc @@ -0,0 +1,432 @@ +::: The last REST client you will ever need + +It's better to REST in BED. + +:: Author + +* Loïc Hoguin +* @lhoguin +* Nine Nines +* Erlang Cowboy and Nine Nines founder + +:: Conference + +* EUC 2014 +* 20140609 + +:: Why this talk? + +: REST is great + +^!rest.jpg + +: The family business + +^!family_business.jpg + +: Open your mind + +^!mind_blown.jpg + +:: REST constraints + +: Client-server architecture + +* Different set of concerns +* Client cares about processing or rendering +* Server cares about storing and making information available efficiently +* Keeping concerns separate allow client and server to evolve independently + +: Stateless + +* Messages always contain all data needed to process the request +* Including authentication information if required +** That doesn't mean you can't use cookies! +** That means you must use them responsibly +* The server keeps no session state around +** The client may + +: Cacheable + +* Resources may be cached by any component, including the client, + the server and any intermediary +* All resources are explicitly or implicitly marked as (not) cacheable + +: Uniform interface + +* All components use the same rules to speak to each other +* Makes it easy to understand the interactions +* A number of constraints are required to achieve this +** We will see them in a few minutes! + +: Layered system + +* Components only know about the components they talk to +* For example a proxy completely hides what's behind it +** This is true for both directions +** There may be more proxies in one way or another + + perhaps use the picture here + +: Code on demand (optional) + +* Code may be downloaded to extend the client functionality +* This is optional, you can't assume the client will receive + or be able to execute the code +* Javascript is a common example of this + +:: Uniform interface in details + +: Resources and resource identifiers + +* Any information that can be named can be a resource +* A resource is a conceptual mapping to a set of entities +** For example one user or a group of users +* A resource is identified by a URI +* Typically we talk about resources and resource collections + +: Resource representations + +* Sequence of bytes + metadata +* Representation metadata (media type, modification time...) +* Resource metadata (related resources, additional representations...) +* Control data (parameterized requests, handling instructions...) + +: Self-descriptive messages + +* Messages contain everything needed to decipher them +* All representations must have a media type in the message +* The media type must be agreed upon by both endpoints +* Negotiating the appropriate media type is a big part of REST + +: Hypermedia as the engine of the application state + +* Interactions must be entirely driven by hypermedia +* A client only needs an entry point and basic understanding + of the media types being used by the service +* Resources and functionality can be discovered at runtime + +:: What media type should we use? + +: Not just one media type + +* Each resource should have at least one media type +* The media type defines the structure and accepted values +* It's pretty much what you do when you document your API +** So why not give them a name and use that in the protocol? +* We still need a basic type to extend upon + +: Why not JSON? + +* No concept of links or link relations +* Unable to deal with binary data +* Not very good with the map datatype +* Very slow and very expensive to parse +* Stop using JSON, save the planet! + +: Why not msgpack? + +* No concept of links or link relations +* No bignums +* No decimals +* Not very good with the map datatype + +: Why not HTML? + +* Everything is a string +* Unable to deal with binary data +* No easy mapping of types onto HTML +* Different use case than what we are looking for really + +: Why not XML? + +* Everything is a string +* Unable to deal with binary data +* No easy mapping of types onto XML +** You can, but it's damn verbose +* XML is probably slower and more expensive to parse than JSON +** The planet is doomed! + +: What then? + +^!wondering.jpg + +:: BED + +: Goals + +* Hyperlinks and link relations +* Binary, explicit sizes, efficient to parse +* Small, exponentially smaller the larger the data gets +* Good type coverage, extensible +* No NULL value +* Fully specified + +: Media types 1/2 + +* application/x-bed +* application/x-bed-stream +** Great with Websockets + +: Media types 2/2 + +* Again, don't be shy, define your own media types! +* Make sure to advertise both your custom type and the basic type +* This way you can process the data even if you don't know its structure + +: Hyperlink 1/2 + +* Link without link relation +* Link with link relation +** Better for automated processing +* Link relations are standard but you may use custom relations + +: Hyperlink 2/2 + +* Link is a string +* Link relation is a symbol +* Highly recommended to only use fully qualified links +** The client should not build links unless strictly required +** This is true with any media type + +: Symbol 1/9 + +``` js +{ + "firstName": "John", + "lastName": "Smith", + "isAlive": true, + "age": 25, + "phoneNumbers": [ + { "type": "home", "number": "212 555-1234" }, + { "type": "office", "number": "646 555-4567" } + ] +} +``` + +: Symbol 2/9 + +* A lot of data is sent as maps +* A lot of maps share the same keys +* Repeating these keys over and over is madness +* There's a better way + +: Symbol 3/9 + +* Keep track of symbols already sent +* Replace repeated symbols with a numerical value +* Continue doing that until the end of the message +** Or the end of the stream! +* It's just like atoms, isn't it? + +: Symbol 4/9 + +* Symbol dictionary starts with `false` (0) and `true` (1) +* You can create a custom content-type that has more pre-defined + +: Symbol 5/9 + +* First message +* JSON: `{"compact":true,"schema":0}` (27 bytes) +* MsgPack: `82 A7 compact C3 A6 schema 00` (18 bytes) +* BED: `C2 27 compact 41 26 schema 80` (18 bytes) + +: Symbol 6/9 + +* Subsequent messages +* JSON: `{"compact":true,"schema":0}` (27 bytes) +* MsgPack: `82 A7 compact C3 A6 schema 00` (18 bytes) +* BED: `C2 42 41 43 80` (5 bytes) + +: Symbol 7/9 + +* We sacrifice a little CPU power for a large size gain +** Especially for collections and large streams +* We don't sacrifice too much +** Even streams tend to use a limited number of symbols +** That means the lookup time is not significant + +: Symbol 8/9 + +* All this without compression +* All this without schemas +* Just call the encode function and you're done! +** Okay some languages might need a little more wrapping than others... + +: Symbol 9/9 + +* The symbol string is limited to 255 bytes (not characters!) +* The first 32 symbols cost exactly 1 byte +** This never changes, so choose these 32 symbols well! +* Subsequent symbols cost 2 or 3 bytes +** 2 bytes when there are less than 8192 symbols defined total +** 3 bytes when there are more + +: Binary + +* Size followed by sequence of bytes +* Size may be encoded as 16-bit, 32-bit or 64-bit unsigned integer +* Minimal binary size: 3 bytes + +: String + +* Must be valid UTF-8 +** Decoding validates UTF-8 by default (optionally can be disabled) +* Size followed by sequence of bytes +** Character-terminated strings are the devil! +* Size may be encoded as 8-bit, 16-bit or 32-bit unsigned integer +* Minimal string size: 2 bytes + +: RFC 3339 date + +* Why? +* Because they are a lot more common than you think +* By standardizing we avoid having tons of different formats +** That means less bugs, especially when converting +* RFC 3339 includes time, date and timezone information +** It's a subset of ISO 8601 +* 2 bytes followed by the date as a sequence of bytes + +: Integer + +* 6-bit, 8-bit, 16-bit, 32-bit and 64-bit signed integer +* Positive and negative bignum integer +** Same encoding as Erlang +* Minimal integer size: 1 byte (-32 to 31) + +: Floating-point + +* IEEE 754 binary64 (double) +* IEEE 754 decimal64 +* Both take 9 bytes + +: Map + +* Size followed by unordered list of pairs of key/values +** If any duplicate, only the last key/value is kept +* Size may be encoded as 5-bit, 16-bit or 32-bit unsigned integer +* Minimal map size: 1 byte +** Maps smaller than 32 keys take 1 byte + the size of pairs + +: Array + +* Size followed by list of values +* Size may be encoded as 5-bit, 16-bit or 32-bit unsigned integer +* Minimal array size: 1 byte +** Arrays smaller than 32 values take 1 byte + the size of the values + +: List + +* 1 byte to indicate the start of a list +* 1 byte to indicate the end +* For special cases only + +: Extensions + +* Define up to 256 additional types +** You can do that through custom media types +* 8-bit, 16-bit, 32-bit or 64-bit value +* Blob of 8-bit, 16-bit, 32-bit or 64-bit unsigned size + +: Wrap-up + +* BED is... +* Great for REST (hypertext) +* Great for Websockets (exponentially smaller as time goes on) +* Comfy! + +: But wait... + +* Doesn't binary make it harder to debug things? +* No +* A large enough JSON is as indecipherable as a large enough binary +* When debugging you can just add a well placed decode call +* Plus nothing is stopping you from providing JSON at the same time! + +:: Writing a REST client + +: Warning + +* This part has no code written for it at this point +* Sorry! +* The BED format was just too interesting to work on +* And we're probably running out of time anyway + +: Goals + +* Manipulate resources +** Only use URIs +** Don't look into or validate representations +** Don't parse representations (with exceptions) +* Automatic caching +** Provide a default but replaceable implementation +** Again, URI based! +* Automatic discovery of service capabilities + +: HTTP client + +* Use `gun` as the client +* Always connected, so great for automation +* What do you call a `gun` based REST client? + +: HTTP client + +* Use `gun` as the client +* Always connected, so great for automation +* What do you call a `gun` based REST client? +* `gunr` of course! + +: Service map 1/2 + +* We don't want to hardcode URIs +* We want to obtain them directly from the service +* We can generate a wrapper using this information +* We could use "crawling" but it's impractical +* RSDL specifications do what we want + +: Service map 2/2 + +* RSDL is ugly XML though :( +* RSDL includes way more information than we need +** It literally describes everything +** It's good, but life is too short +* A subset of RSDL generated from a simpler DSL might be workable +** Or just send that simpler DSL + +: Interface + +``` erlang +my_generated_api_users:get_all(). +my_generated_api_users:get(Key, MediaType). +my_generated_api_users:put(Key, MediaType, Representation). +... +``` + +: Cache + +* A `get` call first looks into the cache +* It builds a request based on cache contents +** In some cases it may not +* The server dictates the client how cache should be used +* So we can safely rely on it + +: Going further + +* We could go further with RSDL +* Is it worth it, though? +* Would people really use this stuff to its full potential? +* I'm not so sure... +* Sounds like too much work for too little reward + +:: Putting it to rest + +: Let's be lazy now! + +* BED: ^https://github.com/bed-project/ +** Help welcome! +* gun: ^https://github.com/extend/gun +** Yes, I promise, I'll add Websockets support soon +* gunr: help welcome! +* Me +** Twitter: @lhoguin +** ^http://ninenines.eu diff --git a/_build/static/talks/bed/bed.html b/_build/static/talks/bed/bed.html new file mode 100644 index 00000000..7609b765 --- /dev/null +++ b/_build/static/talks/bed/bed.html @@ -0,0 +1,767 @@ + + + + +D3 + Websocket for live Web applications + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+ + + +
+ + +
+ +
+

The last REST client you will ever need

+

It's better to REST in BED.

+

Loïc Hoguin - @lhoguin

+

Erlang Cowboy and Nine Nines founder

+
+ + +
+

Why this talk?

+
+ + +
+

REST is great

+

+
+ + +
+

The family business

+

+
+ + +
+

Open your mind

+

+
+ + +
+

REST constraints

+
+ + +
+

Client-server architecture

+
    +
  • Different set of concerns
    • +
  • Client cares about processing or rendering
    • +
  • Server cares about storing and making information available efficiently
    • +
  • Keeping concerns separate allow client and server to evolve independently
    • +
+
+ + +
+

Stateless

+
    +
  • Messages always contain all data needed to process the request
    • +
  • Including authentication information if required
      +
    • That doesn't mean you can't use cookies!
      • +
    • That means you must use them responsibly
      • +
    +
    • +
  • The server keeps no session state around
      +
    • The client may
      • +
    +
    • +
+
+ + +
+

Cacheable

+
    +
  • Resources may be cached by any component, including the client, the server and any intermediary
    • +
  • All resources are explicitly or implicitly marked as (not) cacheable
    • +
+
+ + +
+

Uniform interface

+
    +
  • All components use the same rules to speak to each other
    • +
  • Makes it easy to understand the interactions
    • +
  • A number of constraints are required to achieve this
      +
    • We will see them in a few minutes!
      • +
    +
    • +
+
+ + +
+

Layered system

+
    +
  • Components only know about the components they talk to
    • +
  • For example a proxy completely hides what's behind it
      +
    • This is true for both directions
      • +
    • There may be more proxies in one way or another
      • +
    +
    • +
+
+ + +
+

Code on demand (optional)

+
    +
  • Code may be downloaded to extend the client functionality
    • +
  • This is optional, you can't assume the client will receive or be able to execute the code
    • +
  • Javascript is a common example of this
    • +
+
+ + +
+

Uniform interface in details

+
+ + +
+

Resources and resource identifiers

+
    +
  • Any information that can be named can be a resource
    • +
  • A resource is a conceptual mapping to a set of entities
      +
    • For example one user or a group of users
      • +
    +
    • +
  • A resource is identified by a URI
    • +
  • Typically we talk about resources and resource collections
    • +
+
+ + +
+

Resource representations

+
    +
  • Sequence of bytes + metadata
    • +
  • Representation metadata (media type, modification time...)
    • +
  • Resource metadata (related resources, additional representations...)
    • +
  • Control data (parameterized requests, handling instructions...)
    • +
+
+ + +
+

Self-descriptive messages

+
    +
  • Messages contain everything needed to decipher them
    • +
  • All representations must have a media type in the message
    • +
  • The media type must be agreed upon by both endpoints
    • +
  • Negotiating the appropriate media type is a big part of REST
    • +
+
+ + +
+

Hypermedia as the engine of the application state

+
    +
  • Interactions must be entirely driven by hypermedia
    • +
  • A client only needs an entry point and basic understanding of the media types being used by the service
    • +
  • Resources and functionality can be discovered at runtime
    • +
+
+ + +
+

What media type should we use?

+
+ + +
+

Not just one media type

+
    +
  • Each resource should have at least one media type
    • +
  • The media type defines the structure and accepted values
    • +
  • It's pretty much what you do when you document your API
      +
    • So why not give them a name and use that in the protocol?
      • +
    +
    • +
  • We still need a basic type to extend upon
    • +
+
+ + +
+

Why not JSON?

+
    +
  • No concept of links or link relations
    • +
  • Unable to deal with binary data
    • +
  • Not very good with the map datatype
    • +
  • Very slow and very expensive to parse
    • +
  • Stop using JSON, save the planet!
    • +
+
+ + +
+

Why not msgpack?

+
    +
  • No concept of links or link relations
    • +
  • No bignums
    • +
  • No decimals
    • +
  • Not very good with the map datatype
    • +
+
+ + +
+

Why not HTML?

+
    +
  • Everything is a string
    • +
  • Unable to deal with binary data
    • +
  • No easy mapping of types onto HTML
    • +
  • Different use case than what we are looking for really
    • +
+
+ + +
+

Why not XML?

+
    +
  • Everything is a string
    • +
  • Unable to deal with binary data
    • +
  • No easy mapping of types onto XML
      +
    • You can, but it's damn verbose
      • +
    +
    • +
  • XML is probably slower and more expensive to parse than JSON
      +
    • The planet is doomed!
      • +
    +
    • +
+
+ + +
+

What then?

+

+
+ + +
+

BED

+
+ + +
+

Goals

+
    +
  • Hyperlinks and link relations
    • +
  • Binary, explicit sizes, efficient to parse
    • +
  • Small, exponentially smaller the larger the data gets
    • +
  • Good type coverage, extensible
    • +
  • No NULL value
    • +
  • Fully specified
    • +
+
+ + +
+

Media types 1/2

+
    +
  • application/x-bed
    • +
  • application/x-bed-stream
      +
    • Great with Websockets
      • +
    +
    • +
+
+ + +
+

Media types 2/2

+
    +
  • Again, don't be shy, define your own media types!
    • +
  • Make sure to advertise both your custom type and the basic type
    • +
  • This way you can process the data even if you don't know its structure
    • +
+
+ + +
+

Hyperlink 1/2

+
    +
  • Link without link relation
    • +
  • Link with link relation
      +
    • Better for automated processing
      • +
    +
    • +
  • Link relations are standard but you may use custom relations
    • +
+
+ + +
+

Hyperlink 2/2

+
    +
  • Link is a string
    • +
  • Link relation is a symbol
    • +
  • Highly recommended to only use fully qualified links
      +
    • The client should not build links unless strictly required
      • +
    • This is true with any media type
      • +
    +
    • +
+
+ + +
+

Symbol 1/9

+
+ + +
+

Symbol 2/9

+
    +
  • A lot of data is sent as maps
    • +
  • A lot of maps share the same keys
    • +
  • Repeating these keys over and over is madness
    • +
  • There's a better way
    • +
+
+ + +
+

Symbol 3/9

+
    +
  • Keep track of symbols already sent
    • +
  • Replace repeated symbols with a numerical value
    • +
  • Continue doing that until the end of the message
      +
    • Or the end of the stream!
      • +
    +
    • +
  • It's just like atoms, isn't it?
    • +
+
+ + +
+

Symbol 4/9

+
    +
  • Symbol dictionary starts with false (0) and true (1)
    • +
  • You can create a custom content-type that has more pre-defined
    • +
+
+ + +
+

Symbol 5/9

+
    +
  • First message
    • +
  • JSON: {"compact":true,"schema":0} (27 bytes)
    • +
  • MsgPack: 82 A7 compact C3 A6 schema 00 (18 bytes)
    • +
  • BED: C2 27 compact 41 26 schema 80 (18 bytes)
    • +
+
+ + +
+

Symbol 6/9

+
    +
  • Subsequent messages
    • +
  • JSON: {"compact":true,"schema":0} (27 bytes)
    • +
  • MsgPack: 82 A7 compact C3 A6 schema 00 (18 bytes)
    • +
  • BED: C2 42 41 43 80 (5 bytes)
    • +
+
+ + +
+

Symbol 7/9

+
    +
  • We sacrifice a little CPU power for a large size gain
      +
    • Especially for collections and large streams
      • +
    +
    • +
  • We don't sacrifice too much
      +
    • Even streams tend to use a limited number of symbols
      • +
    • That means the lookup time is not significant
      • +
    +
    • +
+
+ + +
+

Symbol 8/9

+
    +
  • All this without compression
    • +
  • All this without schemas
    • +
  • Just call the encode function and you're done!
      +
    • Okay some languages might need a little more wrapping than others...
      • +
    +
    • +
+
+ + +
+

Symbol 9/9

+
    +
  • The symbol string is limited to 255 bytes (not characters!)
    • +
  • The first 32 symbols cost exactly 1 byte
      +
    • This never changes, so choose these 32 symbols well!
      • +
    +
    • +
  • Subsequent symbols cost 2 or 3 bytes
      +
    • 2 bytes when there are less than 8192 symbols defined total
      • +
    • 3 bytes when there are more
      • +
    +
    • +
+
+ + +
+

Binary

+
    +
  • Size followed by sequence of bytes
    • +
  • Size may be encoded as 16-bit, 32-bit or 64-bit unsigned integer
    • +
  • Minimal binary size: 3 bytes
    • +
+
+ + +
+

String

+
    +
  • Must be valid UTF-8
      +
    • Decoding validates UTF-8 by default (optionally can be disabled)
      • +
    +
    • +
  • Size followed by sequence of bytes
      +
    • Character-terminated strings are the devil!
      • +
    +
    • +
  • Size may be encoded as 8-bit, 16-bit or 32-bit unsigned integer
    • +
  • Minimal string size: 2 bytes
    • +
+
+ + +
+

RFC 3339 date

+
    +
  • Why?
    • +
  • Because they are a lot more common than you think
    • +
  • By standardizing we avoid having tons of different formats
      +
    • That means less bugs, especially when converting
      • +
    +
    • +
  • RFC 3339 includes time, date and timezone information
      +
    • It's a subset of ISO 8601
      • +
    +
    • +
  • 2 bytes followed by the date as a sequence of bytes
    • +
+
+ + +
+

Integer

+
    +
  • 6-bit, 8-bit, 16-bit, 32-bit and 64-bit signed integer
    • +
  • Positive and negative bignum integer
      +
    • Same encoding as Erlang
      • +
    +
    • +
  • Minimal integer size: 1 byte (-32 to 31)
    • +
+
+ + +
+

Floating-point

+
    +
  • IEEE 754 binary64 (double)
    • +
  • IEEE 754 decimal64
    • +
  • Both take 9 bytes
    • +
+
+ + +
+

Map

+
    +
  • Size followed by unordered list of pairs of key/values
      +
    • If any duplicate, only the last key/value is kept
      • +
    +
    • +
  • Size may be encoded as 5-bit, 16-bit or 32-bit unsigned integer
    • +
  • Minimal map size: 1 byte
      +
    • Maps smaller than 32 keys take 1 byte + the size of pairs
      • +
    +
    • +
+
+ + +
+

Array

+
    +
  • Size followed by list of values
    • +
  • Size may be encoded as 5-bit, 16-bit or 32-bit unsigned integer
    • +
  • Minimal array size: 1 byte
      +
    • Arrays smaller than 32 values take 1 byte + the size of the values
      • +
    +
    • +
+
+ + +
+

List

+
    +
  • 1 byte to indicate the start of a list
    • +
  • 1 byte to indicate the end
    • +
  • For special cases only
    • +
+
+ + +
+

Extensions

+
    +
  • Define up to 256 additional types
      +
    • You can do that through custom media types
      • +
    +
    • +
  • 8-bit, 16-bit, 32-bit or 64-bit value
    • +
  • Blob of 8-bit, 16-bit, 32-bit or 64-bit unsigned size
    • +
+
+ + +
+

Wrap-up

+
    +
  • BED is...
    • +
  • Great for REST (hypertext)
    • +
  • Great for Websockets (exponentially smaller as time goes on)
    • +
  • Comfy!
    • +
+
+ + +
+

But wait...

+
    +
  • Doesn't binary make it harder to debug things?
    • +
  • No
    • +
  • A large enough JSON is as indecipherable as a large enough binary
    • +
  • When debugging you can just add a well placed decode call
    • +
  • Plus nothing is stopping you from providing JSON at the same time!
    • +
+
+ + +
+

Writing a REST client

+
+ + +
+

Warning

+
    +
  • This part has no code written for it at this point
    • +
  • Sorry!
    • +
  • The BED format was just too interesting to work on
    • +
  • And we're probably running out of time anyway
    • +
+
+ + +
+

Goals

+
    +
  • Manipulate resources
      +
    • Only use URIs
      • +
    • Don't look into or validate representations
      • +
    • Don't parse representations (with exceptions)
      • +
    +
    • +
  • Automatic caching
      +
    • Provide a default but replaceable implementation
      • +
    • Again, URI based!
      • +
    +
    • +
  • Automatic discovery of service capabilities
    • +
+
+ + +
+

HTTP client

+
    +
  • Use gun as the client
    • +
  • Always connected, so great for automation
    • +
  • What do you call a gun based REST client?
    • +
+
+ + +
+

HTTP client

+
    +
  • Use gun as the client
    • +
  • Always connected, so great for automation
    • +
  • What do you call a gun based REST client?
    • +
  • gunr of course!
    • +
+
+ + +
+

Service map 1/2

+
    +
  • We don't want to hardcode URIs
    • +
  • We want to obtain them directly from the service
    • +
  • We can generate a wrapper using this information
    • +
  • We could use "crawling" but it's impractical
    • +
  • RSDL specifications do what we want
    • +
+
+ + +
+

Service map 2/2

+
    +
  • RSDL is ugly XML though :(
    • +
  • RSDL includes way more information than we need
      +
    • It literally describes everything
      • +
    • It's good, but life is too short
      • +
    +
    • +
  • A subset of RSDL generated from a simpler DSL might be workable
      +
    • Or just send that simpler DSL
      • +
    +
    • +
+
+ + +
+

Interface

+
+ + +
+

Cache

+
    +
  • A get call first looks into the cache
    • +
  • It builds a request based on cache contents
      +
    • In some cases it may not
      • +
    +
    • +
  • The server dictates the client how cache should be used
    • +
  • So we can safely rely on it
    • +
+
+ + +
+

Going further

+
    +
  • We could go further with RSDL
    • +
  • Is it worth it, though?
    • +
  • Would people really use this stuff to its full potential?
    • +
  • I'm not so sure...
    • +
  • Sounds like too much work for too little reward
    • +
+
+ + +
+

Putting it to rest

+
+ + +
+

Let's be lazy now!

+ +
+ + +
+ + + + + diff --git a/_build/static/talks/bed/pics/family_business.jpg b/_build/static/talks/bed/pics/family_business.jpg new file mode 100644 index 00000000..96f58e1b Binary files /dev/null and b/_build/static/talks/bed/pics/family_business.jpg differ diff --git a/_build/static/talks/bed/pics/mind_blown.jpg b/_build/static/talks/bed/pics/mind_blown.jpg new file mode 100644 index 00000000..2a679719 Binary files /dev/null and b/_build/static/talks/bed/pics/mind_blown.jpg differ diff --git a/_build/static/talks/bed/pics/rest.jpg b/_build/static/talks/bed/pics/rest.jpg new file mode 100644 index 00000000..ef029965 Binary files /dev/null and b/_build/static/talks/bed/pics/rest.jpg differ diff --git a/_build/static/talks/bed/pics/wondering.jpg b/_build/static/talks/bed/pics/wondering.jpg new file mode 100644 index 00000000..9a017654 Binary files /dev/null and b/_build/static/talks/bed/pics/wondering.jpg differ diff --git a/_build/static/talks/bed/ui/default/blank.gif b/_build/static/talks/bed/ui/default/blank.gif new file mode 100644 index 00000000..75b945d2 Binary files /dev/null and b/_build/static/talks/bed/ui/default/blank.gif differ diff --git a/_build/static/talks/bed/ui/default/bodybg.gif b/_build/static/talks/bed/ui/default/bodybg.gif new file mode 100755 index 00000000..5f448a16 Binary files /dev/null and b/_build/static/talks/bed/ui/default/bodybg.gif differ diff --git a/_build/static/talks/bed/ui/default/framing.css b/_build/static/talks/bed/ui/default/framing.css new file mode 100644 index 00000000..14d8509e --- /dev/null +++ b/_build/static/talks/bed/ui/default/framing.css @@ -0,0 +1,23 @@ +/* The following styles size, place, and layer the slide components. + Edit these if you want to change the overall slide layout. + The commented lines can be uncommented (and modified, if necessary) + to help you with the rearrangement process. */ + +/* target = 1024x768 */ + +div#header, div#footer, .slide {width: 100%; top: 0; left: 0;} +div#header {top: 0; height: 3em; z-index: 1;} +div#footer {top: auto; bottom: 0; height: 2.5em; z-index: 5;} +.slide {top: 0; width: 92%; padding: 3.5em 4% 4%; z-index: 2; list-style: none;} +div#controls {left: 50%; bottom: 0; width: 50%; z-index: 100;} +div#controls form {position: absolute; bottom: 0; right: 0; width: 100%; + margin: 0;} +#currentSlide {position: absolute; width: 10%; left: 45%; bottom: 1em; z-index: 10;} +html>body #currentSlide {position: fixed;} + +/* +div#header {background: #FCC;} +div#footer {background: #CCF;} +div#controls {background: #BBD;} +div#currentSlide {background: #FFC;} +*/ diff --git a/_build/static/talks/bed/ui/default/iepngfix.htc b/_build/static/talks/bed/ui/default/iepngfix.htc new file mode 100644 index 00000000..bba2db75 --- /dev/null +++ b/_build/static/talks/bed/ui/default/iepngfix.htc @@ -0,0 +1,42 @@ + + + + + \ No newline at end of file diff --git a/_build/static/talks/bed/ui/default/opera.css b/_build/static/talks/bed/ui/default/opera.css new file mode 100644 index 00000000..9e9d2a3c --- /dev/null +++ b/_build/static/talks/bed/ui/default/opera.css @@ -0,0 +1,7 @@ +/* DO NOT CHANGE THESE unless you really want to break Opera Show */ +.slide { + visibility: visible !important; + position: static !important; + page-break-before: always; +} +#slide0 {page-break-before: avoid;} diff --git a/_build/static/talks/bed/ui/default/outline.css b/_build/static/talks/bed/ui/default/outline.css new file mode 100644 index 00000000..62db519e --- /dev/null +++ b/_build/static/talks/bed/ui/default/outline.css @@ -0,0 +1,15 @@ +/* don't change this unless you want the layout stuff to show up in the outline view! */ + +.layout div, #footer *, #controlForm * {display: none;} +#footer, #controls, #controlForm, #navLinks, #toggle { + display: block; visibility: visible; margin: 0; padding: 0;} +#toggle {float: right; padding: 0.5em;} +html>body #toggle {position: fixed; top: 0; right: 0;} + +/* making the outline look pretty-ish */ + +#slide0 h1, #slide0 h2, #slide0 h3, #slide0 h4 {border: none; margin: 0;} +#slide0 h1 {padding-top: 1.5em;} +.slide h1 {margin: 1.5em 0 0; padding-top: 0.25em; + border-top: 1px solid #888; border-bottom: 1px solid #AAA;} +#toggle {border: 1px solid; border-width: 0 0 1px 1px; background: #FFF;} diff --git a/_build/static/talks/bed/ui/default/pretty.css b/_build/static/talks/bed/ui/default/pretty.css new file mode 100644 index 00000000..1d9b8a8c --- /dev/null +++ b/_build/static/talks/bed/ui/default/pretty.css @@ -0,0 +1,255 @@ +/* Following are the presentation styles -- edit away! */ + +body {background: #FFF -16px 0 no-repeat; color: #000; font-size: 2em;} +:link, :visited {text-decoration: none; color: #00C;} +#controls :active {color: #88A !important;} +#controls :focus {outline: 1px dotted #227;} +h1, h2, h3, h4 {font-size: 100%; margin: 0; padding: 0; font-weight: inherit;} +ul, ol, pre {margin: 0; line-height: 1em;} +html, body {margin: 0; padding: 0;} + +blockquote, q {font-style: italic;} +blockquote {padding: 0 2em 0.5em; margin: 0 1.5em 0.5em; text-align: center; font-size: 1em;} +blockquote p {margin: 0;} +blockquote i {font-style: normal;} +blockquote b {display: block; margin-top: 0.5em; font-weight: normal; font-size: smaller; font-style: normal;} +blockquote b i {font-style: italic;} + +kbd {font-weight: bold; font-size: 1em;} +sup {font-size: smaller; line-height: 1px;} + +.slide code {padding: 2px 0.25em; font-weight: bold; color: #533;} +.slide code.bad, code del {color: red;} +.slide code.old {color: silver;} +.slide pre {padding: 0; margin: 0.25em 0 0.5em 0.5em; color: #533; font-size: 90%;} +.slide pre code {display: block;} +.slide ul {margin-left: 5%; margin-right: 7%; list-style: disc;} +.slide ol {margin-left: 5%; margin-right: 7%;} +.slide li {margin-top: 0.75em; margin-right: 0;} +.slide ul ul {line-height: 1;} +.slide ul ul li {margin: .2em; font-size: 85%; list-style: square;} +.slide img.leader {display: block; margin: 0 auto;} + +div#header, div#footer {color: #ccc; + font-family: Verdana, Helvetica, sans-serif; background: url("../img/footer_bg.png") repeat scroll 0 0 transparent; + +} +div#header { + +background-image: linear-gradient(bottom, rgb(234,234,234) 26%, rgb(246,246,246) 49%, rgb(252,252,252) 83%); +background-image: -o-linear-gradient(bottom, rgb(234,234,234) 26%, rgb(246,246,246) 49%, rgb(252,252,252) 83%); +background-image: -moz-linear-gradient(bottom, rgb(234,234,234) 26%, rgb(246,246,246) 49%, rgb(252,252,252) 83%); +background-image: -webkit-linear-gradient(bottom, rgb(234,234,234) 26%, rgb(246,246,246) 49%, rgb(252,252,252) 83%); +background-image: -ms-linear-gradient(bottom, rgb(234,234,234) 26%, rgb(246,246,246) 49%, rgb(252,252,252) 83%); +line-height: 1px; +border-bottom: 1px solid #ccc; +} + +div#sub_header { + display: block; z-index: 2; top: 0pt; background: none repeat scroll 0% 0% rgba(255, 255, 255, 0.4); left: 50%; position: fixed; border-radius: 100em 100em 100em 100em; height: 80em; width: 80em; margin-top: -77.3em; margin-left: -40em; +} + +div#footer {font-size: 0.5em; font-weight: bold; padding: 0 0 1em; height: 5em;} +#footer h1, #footer h2 {display: block; padding: 0 1em;} +#footer h2 {font-style: italic;} + +#footer_shadow { + background: url("../img/footer_shadow.png") repeat scroll 0 0 transparent; + width: 100%; + height: 7px; + margin-bottom: 1em; +} + + +div.long {font-size: 0.75em;} +.slide h1 {position: absolute; top: 0.3em; left: 87px; z-index: 1; + margin: 0; padding: 0.3em 0 0 15px; white-space: nowrap; + font: bold 150%/1em Helvetica, sans-serif; text-transform: capitalize; + color: #333;} +.slide h3 {font-size: 130%;} +h1 abbr {font-variant: small-caps;} + +div#controls {position: absolute; left: 50%; bottom: 0; + width: 50%; + text-align: right; font: bold 0.9em Verdana, Helvetica, sans-serif;} +html>body div#controls {position: fixed; padding: 0 0 1em 0; + top: auto;} +div#controls form {position: absolute; bottom: 0; right: 0; width: 100%; + margin: 0; padding: 0;} +#controls #navLinks a {padding: 0; margin: 0 0.5em; + border: none; color: #ccc; + cursor: pointer;} +#controls #navList {height: 1em;} +#controls #navList #jumplist {position: absolute; bottom: 0; right: 0; background: #DDD; color: #227;} + +#currentSlide {text-align: center; font-size: 0.5em; color: #ccc;} + +#logo {text-align: right; position: fixed; width: 100%; bottom: 0pt;} +#logo img { height: 18em; width: 24em; margin-right: 0em; } + +#slide0 {padding-top: 3.5em; font-size: 90%;} +#slide0 h1 {position: static; margin: 1em 0 0; padding: 0; + font: bold 2em Helvetica, sans-serif; white-space: normal; + color: #000; background: transparent;} +#slide0 h2 {font: bold italic 1em Helvetica, sans-serif; margin: 0.25em;} +#slide0 h3 {margin-top: 1.5em; font-size: 1.5em;} +#slide0 h4 {margin-top: 0; font-size: 1em;} + +ul.urls {list-style: none; display: inline; margin: 0;} +.urls li {display: inline; margin: 0;} +.note {display: none;} +.external {border-bottom: 1px dotted gray;} +html>body .external {border-bottom: none;} +.external:after {content: " \274F"; font-size: smaller; color: #77B;} + +.incremental, .incremental *, .incremental *:after {color: #DDE; visibility: visible;} +img.incremental {visibility: hidden;} +.slide .current {color: #B02;} + +button.btn, input[type="submit"].btn { + *padding-top: 2px; + *padding-bottom: 2px; +} +button.btn::-moz-focus-inner, input[type="submit"].btn::-moz-focus-inner { + padding: 0; + border: 0; +} +button.btn.large, input[type="submit"].btn.large { + *padding-top: 7px; + *padding-bottom: 7px; +} +button.btn.small, input[type="submit"].btn.small { + *padding-top: 3px; + *padding-bottom: 3px; +} +.btn-group { + position: relative; + *zoom: 1; + *margin-left: .3em; +} +.btn-group:before, .btn-group:after { + display: table; + content: ""; +} +.btn-group:after { + clear: both; +} +.btn-group:first-child { + *margin-left: 0; +} +.btn-group + .btn-group { + margin-left: 5px; +} +.btn-toolbar { + margin-top: 9px; + margin-bottom: 9px; +} +.btn-toolbar .btn-group { + display: inline-block; + *display: inline; + /* IE7 inline-block hack */ + + *zoom: 1; +} +.btn-group .btn { + position: relative; + float: left; + margin-left: -1px; + -webkit-border-radius: 0; + -moz-border-radius: 0; + border-radius: 0; +} +.btn-group .btn:first-child { + margin-left: 0; + -webkit-border-top-left-radius: 4px; + -moz-border-radius-topleft: 4px; + border-top-left-radius: 4px; + -webkit-border-bottom-left-radius: 4px; + -moz-border-radius-bottomleft: 4px; + border-bottom-left-radius: 4px; +} +.btn-group .btn:last-child, .btn-group .dropdown-toggle { + -webkit-border-top-right-radius: 4px; + -moz-border-radius-topright: 4px; + border-top-right-radius: 4px; + -webkit-border-bottom-right-radius: 4px; + -moz-border-radius-bottomright: 4px; + border-bottom-right-radius: 4px; +} +.btn-group .btn.large:first-child { + margin-left: 0; + -webkit-border-top-left-radius: 6px; + -moz-border-radius-topleft: 6px; + border-top-left-radius: 6px; + -webkit-border-bottom-left-radius: 6px; + -moz-border-radius-bottomleft: 6px; + border-bottom-left-radius: 6px; +} +.btn-group .btn.large:last-child, .btn-group .large.dropdown-toggle { + -webkit-border-top-right-radius: 6px; + -moz-border-radius-topright: 6px; + border-top-right-radius: 6px; + -webkit-border-bottom-right-radius: 6px; + -moz-border-radius-bottomright: 6px; + border-bottom-right-radius: 6px; +} +.btn-group .btn:hover, +.btn-group .btn:focus, +.btn-group .btn:active, +.btn-group .btn.active { + z-index: 2; +} +.btn-group .dropdown-toggle:active, .btn-group.open .dropdown-toggle { + outline: 0; +} +.btn-group .dropdown-toggle { + padding-left: 8px; + padding-right: 8px; + -webkit-box-shadow: inset 1px 0 0 rgba(255, 255, 255, 0.125), inset 0 1px 0 rgba(255, 255, 255, 0.2), 0 1px 2px rgba(0, 0, 0, 0.05); + -moz-box-shadow: inset 1px 0 0 rgba(255, 255, 255, 0.125), inset 0 1px 0 rgba(255, 255, 255, 0.2), 0 1px 2px rgba(0, 0, 0, 0.05); + box-shadow: inset 1px 0 0 rgba(255, 255, 255, 0.125), inset 0 1px 0 rgba(255, 255, 255, 0.2), 0 1px 2px rgba(0, 0, 0, 0.05); + *padding-top: 5px; + *padding-bottom: 5px; +} +.btn-group.open { + *z-index: 1000; +} +.btn-group.open .dropdown-menu { + display: block; + margin-top: 1px; + -webkit-border-radius: 5px; + -moz-border-radius: 5px; + border-radius: 5px; +} +.btn-group.open .dropdown-toggle { + background-image: none; + -webkit-box-shadow: inset 0 1px 6px rgba(0, 0, 0, 0.15), 0 1px 2px rgba(0, 0, 0, 0.05); + -moz-box-shadow: inset 0 1px 6px rgba(0, 0, 0, 0.15), 0 1px 2px rgba(0, 0, 0, 0.05); + box-shadow: inset 0 1px 6px rgba(0, 0, 0, 0.15), 0 1px 2px rgba(0, 0, 0, 0.05); +} +.btn .caret { + margin-top: 7px; + margin-left: 0; +} +.btn:hover .caret, .open.btn-group .caret { + opacity: 1; + filter: alpha(opacity=100); +} +.btn-primary .caret, +.btn-danger .caret, +.btn-info .caret, +.btn-success .caret, +.btn-inverse .caret { + border-top-color: #ffffff; + opacity: 0.75; + filter: alpha(opacity=75); +} +.btn-small .caret { + margin-top: 4px; +} + + +/* diagnostics + +li:after {content: " [" attr(class) "]"; color: #F88;} + */ diff --git a/_build/static/talks/bed/ui/default/print.css b/_build/static/talks/bed/ui/default/print.css new file mode 100644 index 00000000..e7a71d14 --- /dev/null +++ b/_build/static/talks/bed/ui/default/print.css @@ -0,0 +1 @@ +/* The following rule is necessary to have all slides appear in print! DO NOT REMOVE IT! */ .slide, ul {page-break-inside: avoid; visibility: visible !important;} h1 {page-break-after: avoid;} body {font-size: 12pt; background: white;} * {color: black;} #slide0 h1 {font-size: 200%; border: none; margin: 0.5em 0 0.25em;} #slide0 h3 {margin: 0; padding: 0;} #slide0 h4 {margin: 0 0 0.5em; padding: 0;} #slide0 {margin-bottom: 3em;} h1 {border-top: 2pt solid gray; border-bottom: 1px dotted silver;} .extra {background: transparent !important;} div.extra, pre.extra, .example {font-size: 10pt; color: #333;} ul.extra a {font-weight: bold;} p.example {display: none;} #header {display: none;} #footer h1 {margin: 0; border-bottom: 1px solid; color: gray; font-style: italic;} #footer h2, #controls {display: none;} /* The following rule keeps the layout stuff out of print. Remove at your own risk! */ .layout, .layout * {display: none !important;} \ No newline at end of file diff --git a/_build/static/talks/bed/ui/default/s5-core.css b/_build/static/talks/bed/ui/default/s5-core.css new file mode 100644 index 00000000..86444e04 --- /dev/null +++ b/_build/static/talks/bed/ui/default/s5-core.css @@ -0,0 +1,9 @@ +/* Do not edit or override these styles! The system will likely break if you do. */ + +div#header, div#footer, div#controls, .slide {position: absolute;} +html>body div#header, html>body div#footer, + html>body div#controls, html>body .slide {position: fixed;} +.handout {display: none;} +.layout {display: block;} +.slide, .hideme, .incremental {visibility: hidden;} +#slide0 {visibility: visible;} diff --git a/_build/static/talks/bed/ui/default/slides.css b/_build/static/talks/bed/ui/default/slides.css new file mode 100644 index 00000000..0786d7db --- /dev/null +++ b/_build/static/talks/bed/ui/default/slides.css @@ -0,0 +1,3 @@ +@import url(s5-core.css); /* required to make the slide show run at all */ +@import url(framing.css); /* sets basic placement and size of slide components */ +@import url(pretty.css); /* stuff that makes the slides look better than blah */ \ No newline at end of file diff --git a/_build/static/talks/bed/ui/default/slides.js b/_build/static/talks/bed/ui/default/slides.js new file mode 100644 index 00000000..3d9ad756 --- /dev/null +++ b/_build/static/talks/bed/ui/default/slides.js @@ -0,0 +1,545 @@ +// S5 v1.1 slides.js -- released into the Public Domain +// +// Please see http://www.meyerweb.com/eric/tools/s5/credits.html for information +// about all the wonderful and talented contributors to this code! + +var undef; +var slideCSS = ''; +var snum = 0; +var smax = 1; +var incpos = 0; +var number = undef; +var s5mode = true; +var defaultView = 'slideshow'; +var controlVis = 'visible'; + +var isIE = navigator.appName == 'Microsoft Internet Explorer' && navigator.userAgent.indexOf('Opera') < 1 ? 1 : 0; +var isOp = navigator.userAgent.indexOf('Opera') > -1 ? 1 : 0; +var isGe = navigator.userAgent.indexOf('Gecko') > -1 && navigator.userAgent.indexOf('Safari') < 1 ? 1 : 0; + +function hasClass(object, className) { + if (!object.className) return false; + return (object.className.search('(^|\\s)' + className + '(\\s|$)') != -1); +} + +function hasValue(object, value) { + if (!object) return false; + return (object.search('(^|\\s)' + value + '(\\s|$)') != -1); +} + +function removeClass(object,className) { + if (!object) return; + object.className = object.className.replace(new RegExp('(^|\\s)'+className+'(\\s|$)'), RegExp.$1+RegExp.$2); +} + +function addClass(object,className) { + if (!object || hasClass(object, className)) return; + if (object.className) { + object.className += ' '+className; + } else { + object.className = className; + } +} + +function GetElementsWithClassName(elementName,className) { + var allElements = document.getElementsByTagName(elementName); + var elemColl = new Array(); + for (var i = 0; i< allElements.length; i++) { + if (hasClass(allElements[i], className)) { + elemColl[elemColl.length] = allElements[i]; + } + } + return elemColl; +} + +function isParentOrSelf(element, id) { + if (element == null || element.nodeName=='BODY') return false; + else if (element.id == id) return true; + else return isParentOrSelf(element.parentNode, id); +} + +function nodeValue(node) { + var result = ""; + if (node.nodeType == 1) { + var children = node.childNodes; + for (var i = 0; i < children.length; ++i) { + result += nodeValue(children[i]); + } + } + else if (node.nodeType == 3) { + result = node.nodeValue; + } + return(result); +} + +function slideLabel() { + var slideColl = GetElementsWithClassName('*','slide'); + var list = document.getElementById('jumplist'); + smax = slideColl.length; + for (var n = 0; n < smax; n++) { + var obj = slideColl[n]; + + var did = 'slide' + n.toString(); + obj.setAttribute('id',did); + if (isOp) continue; + + var otext = ''; + var menu = obj.firstChild; + if (!menu) continue; // to cope with empty slides + while (menu && menu.nodeType == 3) { + menu = menu.nextSibling; + } + if (!menu) continue; // to cope with slides with only text nodes + + var menunodes = menu.childNodes; + for (var o = 0; o < menunodes.length; o++) { + otext += nodeValue(menunodes[o]); + } + list.options[list.length] = new Option(n + ' : ' + otext, n); + } +} + +function currentSlide() { + var cs; + if (document.getElementById) { + cs = document.getElementById('currentSlide'); + } else { + cs = document.currentSlide; + } + cs.innerHTML = '' + snum + '<\/span> ' + + '\/<\/span> ' + + '' + (smax-1) + '<\/span>'; + if (snum == 0) { + cs.style.visibility = 'hidden'; + } else { + cs.style.visibility = 'visible'; + } +} + +function go(step) { + if (document.getElementById('slideProj').disabled || step == 0) return; + var jl = document.getElementById('jumplist'); + var cid = 'slide' + snum; + var ce = document.getElementById(cid); + if (incrementals[snum].length > 0) { + for (var i = 0; i < incrementals[snum].length; i++) { + removeClass(incrementals[snum][i], 'current'); + removeClass(incrementals[snum][i], 'incremental'); + } + } + if (step != 'j') { + snum += step; + lmax = smax - 1; + if (snum > lmax) snum = lmax; + if (snum < 0) snum = 0; + } else + snum = parseInt(jl.value); + var nid = 'slide' + snum; + var ne = document.getElementById(nid); + if (!ne) { + ne = document.getElementById('slide0'); + snum = 0; + } + if (step < 0) {incpos = incrementals[snum].length} else {incpos = 0;} + if (incrementals[snum].length > 0 && incpos == 0) { + for (var i = 0; i < incrementals[snum].length; i++) { + if (hasClass(incrementals[snum][i], 'current')) + incpos = i + 1; + else + addClass(incrementals[snum][i], 'incremental'); + } + } + if (incrementals[snum].length > 0 && incpos > 0) + addClass(incrementals[snum][incpos - 1], 'current'); + ce.style.visibility = 'hidden'; + ne.style.visibility = 'visible'; + jl.selectedIndex = snum; + currentSlide(); + number = 0; +} + +function goTo(target) { + if (target >= smax || target == snum) return; + go(target - snum); +} + +function subgo(step) { + if (step > 0) { + removeClass(incrementals[snum][incpos - 1],'current'); + removeClass(incrementals[snum][incpos], 'incremental'); + addClass(incrementals[snum][incpos],'current'); + incpos++; + } else { + incpos--; + removeClass(incrementals[snum][incpos],'current'); + addClass(incrementals[snum][incpos], 'incremental'); + addClass(incrementals[snum][incpos - 1],'current'); + } +} + +function toggle() { + var slideColl = GetElementsWithClassName('*','slide'); + var slides = document.getElementById('slideProj'); + var outline = document.getElementById('outlineStyle'); + if (!slides.disabled) { + slides.disabled = true; + outline.disabled = false; + s5mode = false; + fontSize('1em'); + for (var n = 0; n < smax; n++) { + var slide = slideColl[n]; + slide.style.visibility = 'visible'; + } + } else { + slides.disabled = false; + outline.disabled = true; + s5mode = true; + fontScale(); + for (var n = 0; n < smax; n++) { + var slide = slideColl[n]; + slide.style.visibility = 'hidden'; + } + slideColl[snum].style.visibility = 'visible'; + } +} + +function showHide(action) { + var obj = GetElementsWithClassName('*','hideme')[0]; + switch (action) { + case 's': obj.style.visibility = 'visible'; break; + case 'h': obj.style.visibility = 'hidden'; break; + case 'k': + if (obj.style.visibility != 'visible') { + obj.style.visibility = 'visible'; + } else { + obj.style.visibility = 'hidden'; + } + break; + } +} + +// 'keys' code adapted from MozPoint (http://mozpoint.mozdev.org/) +function keys(key) { + if (!key) { + key = event; + key.which = key.keyCode; + } + if (key.which == 84) { + toggle(); + return; + } + if (s5mode) { + switch (key.which) { + case 10: // return + case 13: // enter + if (window.event && isParentOrSelf(window.event.srcElement, 'controls')) return; + if (key.target && isParentOrSelf(key.target, 'controls')) return; + if(number != undef) { + goTo(number); + break; + } + case 32: // spacebar + case 34: // page down + case 39: // rightkey + case 40: // downkey + if(number != undef) { + go(number); + } else if (!incrementals[snum] || incpos >= incrementals[snum].length) { + go(1); + } else { + subgo(1); + } + break; + case 33: // page up + case 37: // leftkey + case 38: // upkey + if(number != undef) { + go(-1 * number); + } else if (!incrementals[snum] || incpos <= 0) { + go(-1); + } else { + subgo(-1); + } + break; + case 36: // home + goTo(0); + break; + case 35: // end + goTo(smax-1); + break; + case 67: // c + showHide('k'); + break; + } + if (key.which < 48 || key.which > 57) { + number = undef; + } else { + if (window.event && isParentOrSelf(window.event.srcElement, 'controls')) return; + if (key.target && isParentOrSelf(key.target, 'controls')) return; + number = (((number != undef) ? number : 0) * 10) + (key.which - 48); + } + } + return false; +} + +function clicker(e) { + number = undef; + var target; + if (window.event) { + target = window.event.srcElement; + e = window.event; + } else target = e.target; + if (target.getAttribute('href') != null || hasValue(target.rel, 'external') || isParentOrSelf(target, 'controls') || isParentOrSelf(target,'embed') || isParentOrSelf(target,'object')) return true; + if (!e.which || e.which == 1) { + if (!incrementals[snum] || incpos >= incrementals[snum].length) { + go(1); + } else { + subgo(1); + } + } +} + +function findSlide(hash) { + var target = null; + var slides = GetElementsWithClassName('*','slide'); + for (var i = 0; i < slides.length; i++) { + var targetSlide = slides[i]; + if ( (targetSlide.name && targetSlide.name == hash) + || (targetSlide.id && targetSlide.id == hash) ) { + target = targetSlide; + break; + } + } + while(target != null && target.nodeName != 'BODY') { + if (hasClass(target, 'slide')) { + return parseInt(target.id.slice(5)); + } + target = target.parentNode; + } + return null; +} + +function slideJump() { + if (window.location.hash == null) return; + var sregex = /^#slide(\d+)$/; + var matches = sregex.exec(window.location.hash); + var dest = null; + if (matches != null) { + dest = parseInt(matches[1]); + } else { + dest = findSlide(window.location.hash.slice(1)); + } + if (dest != null) + go(dest - snum); +} + +function fixLinks() { + var thisUri = window.location.href; + thisUri = thisUri.slice(0, thisUri.length - window.location.hash.length); + var aelements = document.getElementsByTagName('A'); + for (var i = 0; i < aelements.length; i++) { + var a = aelements[i].href; + var slideID = a.match('\#slide[0-9]{1,2}'); + if ((slideID) && (slideID[0].slice(0,1) == '#')) { + var dest = findSlide(slideID[0].slice(1)); + if (dest != null) { + if (aelements[i].addEventListener) { + aelements[i].addEventListener("click", new Function("e", + "if (document.getElementById('slideProj').disabled) return;" + + "go("+dest+" - snum); " + + "if (e.preventDefault) e.preventDefault();"), true); + } else if (aelements[i].attachEvent) { + aelements[i].attachEvent("onclick", new Function("", + "if (document.getElementById('slideProj').disabled) return;" + + "go("+dest+" - snum); " + + "event.returnValue = false;")); + } + } + } + } +} + +function externalLinks() { + if (!document.getElementsByTagName) return; + var anchors = document.getElementsByTagName('a'); + for (var i=0; i' + + '