Mirrors/httpstatuses
1
0
Fork 0
mirror of https://github.com/rmaake1/httpstatuses.git synced 2024-11-20 01:12:43 +01:00
Code Issues Packages Projects Releases Wiki Activity
f26eeb43c6
httpstatuses/README.md
Samuel Ryan d8a693bf27 Remove markdown line limit (#52) 
* Removes line length limit from Status Code Markdown

This will make the data easier to use when we develop the API, it needs
to be consistent, arbitrary new lines (especially in text format) will
be a major issue, so some sort of workaround would have to be
implemented, easier to simply fix the source files.

* Removes line length limit from misc. Markdown files
2016-04-23 01:12:07 +01:00

2.7 KiB
Raw Blame History

httpstatuses.com

Build Status

httpstatuses.com is an easy to reference database of HTTP Status Codes with their definitions and helpful code references, each code is at httpstatuses.com/code. All standard codes are included, as are some non-standard codes that have significant presence in the wild.

Contributing

To build you need nodejs, run npm install to pull in dependencies and then node build, a preview will be available at localhost:4887.

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 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:

  • 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"

httpstatus.es

Previously the project was known as httpstatus.es but as per this GitHub issue we migrated to httpstatuses.com in November 2015 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. The months following the migration have seen a significant uptake in search engine traffic, if you're running a project on a ccTLD not considered generic by Google and SEO matters it might be worth switching to a generic too.