What a website serves
A website serves the files you publish, over HTTPS, at one address.
File types
Each file is served as the type its extension names; a deploy with any other extension is refused, naming the file.
| Kind | Extensions |
|---|---|
| Pages and data | html, md, txt, xml, json, webmanifest, pdf |
| Styles and scripts | css, js, mjs, map, wasm |
| Images | svg, png, jpg, jpeg, gif, webp, avif, ico |
| Fonts | woff, woff2, ttf, otf |
| Audio and video | mp4, webm, mp3, wav |
- A path is at most 256 bytes, with no empty,
.or..parts, and no hidden file or folder except a top-level.well-known. - PDFs download rather than open in the browser.
- An agent that asks for Markdown gets a page’s
index.md, when there is one beside itsindex.html; browsers always get the HTML. - A website without its own
favicon.icohas no icon. - Deploy sizes and file counts are limited; see Deploy limits.
Addresses and pages
| Address | Serves |
|---|---|
/ | /index.html |
/about/ | /about/index.html |
/about | The file /about; else a redirect to /about/ when /about/index.html exists; else /about.html |
| Anything else | Your /404.html with status 404, or Benchy’s “Page not found” |
The redirect to /about/ keeps the query string and makes relative links inside about/index.html work. A website published from a canvas also redirects a renamed Page’s old address to its new one. Benchy does no other redirects or rewrites: to move a page in a website built as files, publish one at the old address with a <meta http-equiv="refresh"> tag.
App routing
A single-page app that routes in the browser, with addresses such as /products/42, needs each address to exist as a file:
- Build every route to its own page, such as
products/42/index.html(a static export or prerendering). - Or route after a
#, as in/#/products/42, so every address loads/index.html.
benchy.site.json declares your editable content and forms and is never served. A fallback page in it is accepted but unused: an address with no file answers your 404.html.
JavaScript, apps and backends
JavaScript and WebAssembly run in your visitors’ browsers, so games, tools and 3D viewers work. A website has no server of its own for server functions, API routes, server-side rendering, a database, visitor sign-in or secrets — every file is public, so an API key in one is leaked. For those, the browser calls a backend you run elsewhere.
Benchy itself answers only your content and your forms, under the reserved path /_benchy/; everything else takes only GET and HEAD. Service workers aren’t served, since one could keep serving a website after it was taken offline.
Caching
| Files | How long browsers keep them |
|---|---|
| HTML pages | Checked on every visit, so a new version shows at once |
Scripts, styles, fonts and images whose name carries a fingerprint of 8 or more characters, such as app.3f9a1c2b.js | A year. Build tools name files this way, so a change gets a new name |
| Everything else | 5 minutes |
| Content JSON | Checked on every visit, so a save shows within seconds |
| Content pictures | A year: the address holds a fingerprint of the picture |
Checking an unchanged file costs a visitor nothing, and audio and video can be streamed and seeked.
What Benchy sends with every page
Benchy sets every response header; _headers or _redirects files from other hosts do nothing. On every page:
- HTTPS only — browsers are told not to try plain HTTP;
- the camera, microphone and location are off;
- only your own website can show your pages in a frame;
- search engines are told not to index the page while the website is kept out of search. See Search engines.
A Content Security Policy in a <meta http-equiv> tag in your HTML still applies, so tighten what your pages may load there.
Cookies and storage
Benchy never sets a cookie on a website, and Benchy’s sign-in never reaches one. Every website on benchy.site shares the parent domain benchy.site, so one website’s script can set a cookie every other website receives.
- Don’t trust a cookie,
localStorageorsessionStoragevalue; use them for things a visitor can harmlessly change, such as a remembered theme. - Don’t set or rely on cookies on the parent domain.
- A custom domain gives the website its own origin, but write it so the advice above holds either way.
When a website is taken offline or suspended, visitors’ browsers are asked to clear what it stored.