Go to file
Samuel Ryan 6383b80064 Adds meta descriptions to status code pages and index
Makes use of the first paragraph of the status code!
2015-12-11 03:02:39 +00:00
contents Hosts fonts locally 2015-11-12 16:05:20 +00:00
templates Adds meta descriptions to status code pages and index 2015-12-11 03:02:39 +00:00
.gitignore Listens to the master branch for deploys 2015-11-07 14:55:55 +00:00
bower.json Renames project from "httpstatus.es" to "httpstatuses" with the domain "httpstatuses.com" 2015-11-08 00:13:13 +00:00
build.js Adds meta descriptions to status code pages and index 2015-12-11 03:02:39 +00:00
circle.yml Listens to the master branch for deploys 2015-11-07 14:55:55 +00:00
deploy.sh Fixes project name reference 2015-11-08 00:28:14 +00:00
LICENSE Removes old project files 2015-11-01 18:09:40 +00:00
package.json Adds meta descriptions to status code pages and index 2015-12-11 03:02:39 +00:00
README.md Renames project from "httpstatus.es" to "httpstatuses" with the domain "httpstatuses.com" 2015-11-08 00:13:13 +00:00
Vagrantfile Adds development environment using Vagrant 2015-11-01 18:32:59 +00:00

httpstatuses.com

httpstatuses.com is an easy to reference database of HTTP Status Codes with their definitions and helpful code references.

httpstatus.es

Previously the project was known as httpstatus.es but as per this GitHub issue we have migrated to httpstatuses.com for SEO reasons. The httpstatus.es domain will remain available long term but use of httpstatuses.com is preferred, everything 301's to https://httpstatuses.com.

Contributing

All contributions are welcome! If you have an idea to improve the website please submit a pull request or create an issue, or provide your thoughts on any open issues.

Each status code lives in a Markdown file at contents/codes, the easiest way to submit changes is via the GitHub editor. When contributing changes to the status codes please be mindful of the following:

  • Soft line length of 80 for Markdown
  • Markdown links should be used as references instead of inline
  • If an RFC or external document is referenced, make the reference a link
  • Source information on a status code from the most recent standards available (Status Code standards directory is available on iana.org)
  • The opening paragraph of a status code should describe the meaning, following paragraphs can describe implementation
  • Don't edit the meaning of descriptions, but formatting and structural changes are a-okay
  • Don't double-space after a period, and remove any examples of it
  • If the description references a section in the current RFC, always add the RFC identifier. For example "Section 6.6" should become "RFC1234 Section 6.6"