Mirrors/httpstatuses
1
0
Fork 0
mirror of https://github.com/rmaake1/httpstatuses.git synced 2024-07-05 11:36:37 +02:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #28 from citricsquid/metalsmith

Browse Source 
Version 2
This commit is contained in:
Samuel Ryan 2015-11-07 14:58:48 +00:00
commit e81084ffcf
96 changed files with 2505 additions and 1800 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.gitignore vendored Normal file
View File

@ -0,0 +1,4 @@
.vagrant
node_modules
bower_components
build

31
LICENSE
View File

@ -1,18 +1,21 @@
Copyright (C) 2012 - 2013 Samuel Ryan (citricsquid)
The MIT License (MIT)
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the
Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
Copyright (c) 2015 Samuel Ryan <sam@samryan.co.uk>
The above copyright notice and this permission notice shall be included in all
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

67
README.markdown
View File

@ -1,67 +0,0 @@
[httpstatus.es](http://httpstatus.es) is an easy to use http status code reference
site. An individual code can be accessed via httpstatus.es/{status_code}.
Each individual code is stored in a file specific to the class it is a part of.
For example 404 is stored in 4.json, along with all other 4xx codes.
## json format
```json
{
"class":{
"title":"1xx Informational"
},
"codes":{
"100":{
"title":"Continue",
"summary":"Client should continue with request",
"descriptions":{
"wiki":{
"body":"Wikipedia description",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#100"
},
"ietf":{
"body":"IETF Description",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"item":{
"title":"Reference Title",
"value":"Reference Value"
},
"item2":{
"title":"Reference Title",
"value":"Reference Value"
}
}
}
}
}
```
JSON should be formatted as above using four space tab and \r\n for new lines in
descriptions. There is no validation on the output and the only processing is
turning new lines into line breaks, if you wish to include HTML that's fine
(preferably only links though and code tags).
# License
Copyright (C) 2012 - 2013 Samuel Ryan (citricsquid)
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the
Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

32
README.md Normal file
View File

@ -0,0 +1,32 @@
# [httpstatus.es](http://httpstatus.es)
[httpstatus.es](http://httpstatus.es) is an easy to reference database of HTTP Status Codes
with their definitions and helpful code references.
## Contributing
All contributions are welcome! If you have an idea to improve the website please
submit a pull request or [create an issue][1], or provide your thoughts on any
[open issues][1].
Each status code lives in a Markdown file at [contents/codes](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][2]
* 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][3])
* 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][4], 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"
[1]: <https://github.com/citricsquid/httpstatus.es/issues>
[2]: <https://daringfireball.net/projects/markdown/syntax#link>
[3]: <http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml>
[4]: <http://www.slate.com/articles/technology/technology/2011/01/space_invaders.html>

356
Vagrantfile vendored Normal file
View File

@ -0,0 +1,356 @@
# -*- mode: ruby -*-
# vi: set ft=ruby :
# Config Github Settings
github_username = "fideloper"
github_repo = "Vaprobash"
github_branch = "1.4.1"
github_url = "https://raw.githubusercontent.com/#{github_username}/#{github_repo}/#{github_branch}"
# Because this:https://developer.github.com/changes/2014-12-08-removing-authorizations-token/
# https://github.com/settings/tokens
github_pat = ""
# Server Configuration
hostname = "httpstatus.es.dev"
# Set a local private network IP address.
# See http://en.wikipedia.org/wiki/Private_network for explanation
# You can use the following IP ranges:
# 10.0.0.1 - 10.255.255.254
# 172.16.0.1 - 172.31.255.254
# 192.168.0.1 - 192.168.255.254
server_ip = "192.168.22.29"
server_cpus = "1" # Cores
server_memory = "384" # MB
server_swap = "768" # Options: false | int (MB) - Guideline: Between one or two times the server_memory
# UTC for Universal Coordinated Time
# EST for Eastern Standard Time
# US/Central for American Central
# US/Eastern for American Eastern
server_timezone = "UTC"
# Database Configuration
mysql_root_password = "root" # We'll assume user "root"
mysql_version = "5.5" # Options: 5.5 | 5.6
mysql_enable_remote = "false" # remote access enabled when true
pgsql_root_password = "root" # We'll assume user "root"
mongo_version = "2.6" # Options: 2.6 | 3.0
mongo_enable_remote = "false" # remote access enabled when true
# Languages and Packages
php_timezone = "UTC" # http://php.net/manual/en/timezones.php
php_version = "5.6" # Options: 5.5 | 5.6
ruby_version = "latest" # Choose what ruby version should be installed (will also be the default version)
ruby_gems = [ # List any Ruby Gems that you want to install
#"jekyll",
#"sass",
#"compass",
]
go_version = "latest" # Example: go1.4 (latest equals the latest stable version)
# To install HHVM instead of PHP, set this to "true"
hhvm = "false"
# PHP Options
composer_packages = [ # List any global Composer packages that you want to install
#"phpunit/phpunit:4.0.*",
#"codeception/codeception=*",
#"phpspec/phpspec:2.0.*@dev",
#"squizlabs/php_codesniffer:1.5.*",
]
# Default web server document root
# Symfony's public directory is assumed "web"
# Laravel's public directory is assumed "public"
public_folder = "/vagrant/build"
laravel_root_folder = "/vagrant/laravel" # Where to install Laravel. Will `composer install` if a composer.json file exists
laravel_version = "latest-stable" # If you need a specific version of Laravel, set it here
symfony_root_folder = "/vagrant/symfony" # Where to install Symfony.
nodejs_version = "5" # By default "latest" will equal the latest stable version
nodejs_packages = [ # List any global NodeJS packages that you want to install
#"grunt-cli",
"gulp",
"bower",
#"yo",
]
# RabbitMQ settings
rabbitmq_user = "user"
rabbitmq_password = "password"
sphinxsearch_version = "rel22" # rel20, rel21, rel22, beta, daily, stable
Vagrant.configure("2") do |config|
# Set server to Ubuntu 14.04
config.vm.box = "ubuntu/trusty64"
config.vm.define "httpstatus.es.dev" do |vapro|
end
if Vagrant.has_plugin?("vagrant-hostmanager")
config.hostmanager.enabled = true
config.hostmanager.manage_host = true
config.hostmanager.ignore_private_ip = false
config.hostmanager.include_offline = false
end
# Create a hostname, don't forget to put it to the `hosts` file
# This will point to the server's default virtual host
# TO DO: Make this work with virtualhost along-side xip.io URL
config.vm.hostname = hostname
# Create a static IP
config.vm.network :private_network, ip: server_ip
config.vm.network :forwarded_port, guest: 80, host: 8000
# Enable agent forwarding over SSH connections
config.ssh.forward_agent = true
# Use NFS for the shared folder
config.vm.synced_folder ".", "/vagrant",
id: "core",
:nfs => true,
:mount_options => ['nolock,vers=3,udp,noatime,actimeo=2']
# Replicate local .gitconfig file if it exists
if File.file?(File.expand_path("~/.gitconfig"))
config.vm.provision "file", source: "~/.gitconfig", destination: ".gitconfig"
end
# If using VirtualBox
config.vm.provider :virtualbox do |vb|
vb.name = "httpstatus.es.dev"
# Set server cpus
vb.customize ["modifyvm", :id, "--cpus", server_cpus]
# Set server memory
vb.customize ["modifyvm", :id, "--memory", server_memory]
# Set the timesync threshold to 10 seconds, instead of the default 20 minutes.
# If the clock gets more than 15 minutes out of sync (due to your laptop going
# to sleep for instance, then some 3rd party services will reject requests.
vb.customize ["guestproperty", "set", :id, "/VirtualBox/GuestAdd/VBoxService/--timesync-set-threshold", 10000]
# Prevent VMs running on Ubuntu to lose internet connection
# vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
# vb.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
end
# If using VMWare Fusion
config.vm.provider "vmware_fusion" do |vb, override|
override.vm.box_url = "http://files.vagrantup.com/precise64_vmware.box"
# Set server memory
vb.vmx["memsize"] = server_memory
end
# If using Vagrant-Cachier
# http://fgrehm.viewdocs.io/vagrant-cachier
if Vagrant.has_plugin?("vagrant-cachier")
# Configure cached packages to be shared between instances of the same base box.
# Usage docs: http://fgrehm.viewdocs.io/vagrant-cachier/usage
config.cache.scope = :box
config.cache.synced_folder_opts = {
type: :nfs,
mount_options: ['rw', 'vers=3', 'tcp', 'nolock']
}
end
# Adding vagrant-digitalocean provider - https://github.com/smdahlen/vagrant-digitalocean
# Needs to ensure that the vagrant plugin is installed
config.vm.provider :digital_ocean do |provider, override|
override.ssh.private_key_path = '~/.ssh/id_rsa'
override.ssh.username = 'vagrant'
override.vm.box = 'digital_ocean'
override.vm.box_url = "https://github.com/smdahlen/vagrant-digitalocean/raw/master/box/digital_ocean.box"
provider.token = 'YOUR TOKEN'
provider.image = 'ubuntu-14-04-x64'
provider.region = 'nyc2'
provider.size = '512mb'
end
####
# Base Items
##########
# Provision Base Packages
config.vm.provision "shell", path: "#{github_url}/scripts/base.sh", args: [github_url, server_swap, server_timezone]
# optimize base box
config.vm.provision "shell", path: "#{github_url}/scripts/base_box_optimizations.sh", privileged: true
# Provision PHP
# config.vm.provision "shell", path: "#{github_url}/scripts/php.sh", args: [php_timezone, hhvm, php_version]
# Enable MSSQL for PHP
# config.vm.provision "shell", path: "#{github_url}/scripts/mssql.sh"
# Provision Vim
# config.vm.provision "shell", path: "#{github_url}/scripts/vim.sh", args: github_url
# Provision Docker
# config.vm.provision "shell", path: "#{github_url}/scripts/docker.sh", args: "permissions"
####
# Web Servers
##########
# Provision Apache Base
# config.vm.provision "shell", path: "#{github_url}/scripts/apache.sh", args: [server_ip, public_folder, hostname, github_url]
# Provision Nginx Base
config.vm.provision "shell", path: "#{github_url}/scripts/nginx.sh", args: [server_ip, public_folder, hostname, github_url]
####
# Databases
##########
# Provision MySQL
# config.vm.provision "shell", path: "#{github_url}/scripts/mysql.sh", args: [mysql_root_password, mysql_version, mysql_enable_remote]
# Provision PostgreSQL
# config.vm.provision "shell", path: "#{github_url}/scripts/pgsql.sh", args: pgsql_root_password
# Provision SQLite
# config.vm.provision "shell", path: "#{github_url}/scripts/sqlite.sh"
# Provision RethinkDB
# config.vm.provision "shell", path: "#{github_url}/scripts/rethinkdb.sh", args: pgsql_root_password
# Provision Couchbase
# config.vm.provision "shell", path: "#{github_url}/scripts/couchbase.sh"
# Provision CouchDB
# config.vm.provision "shell", path: "#{github_url}/scripts/couchdb.sh"
# Provision MongoDB
# config.vm.provision "shell", path: "#{github_url}/scripts/mongodb.sh", args: [mongo_enable_remote, mongo_version]
# Provision MariaDB
# config.vm.provision "shell", path: "#{github_url}/scripts/mariadb.sh", args: [mysql_root_password, mysql_enable_remote]
# Provision Neo4J
# config.vm.provision "shell", path: "#{github_url}/scripts/neo4j.sh"
####
# Search Servers
##########
# Install Elasticsearch
# config.vm.provision "shell", path: "#{github_url}/scripts/elasticsearch.sh"
# Install SphinxSearch
# config.vm.provision "shell", path: "#{github_url}/scripts/sphinxsearch.sh", args: [sphinxsearch_version]
####
# Search Server Administration (web-based)
##########
# Install ElasticHQ
# Admin for: Elasticsearch
# Works on: Apache2, Nginx
# config.vm.provision "shell", path: "#{github_url}/scripts/elastichq.sh"
####
# In-Memory Stores
##########
# Install Memcached
# config.vm.provision "shell", path: "#{github_url}/scripts/memcached.sh"
# Provision Redis (without journaling and persistence)
# config.vm.provision "shell", path: "#{github_url}/scripts/redis.sh"
# Provision Redis (with journaling and persistence)
# config.vm.provision "shell", path: "#{github_url}/scripts/redis.sh", args: "persistent"
# NOTE: It is safe to run this to add persistence even if originally provisioned without persistence
####
# Utility (queue)
##########
# Install Beanstalkd
# config.vm.provision "shell", path: "#{github_url}/scripts/beanstalkd.sh"
# Install Heroku Toolbelt
# config.vm.provision "shell", path: "https://toolbelt.heroku.com/install-ubuntu.sh"
# Install Supervisord
# config.vm.provision "shell", path: "#{github_url}/scripts/supervisord.sh"
# Install Kibana
# config.vm.provision "shell", path: "#{github_url}/scripts/kibana.sh"
# Install ØMQ
# config.vm.provision "shell", path: "#{github_url}/scripts/zeromq.sh"
# Install RabbitMQ
# config.vm.provision "shell", path: "#{github_url}/scripts/rabbitmq.sh", args: [rabbitmq_user, rabbitmq_password]
####
# Additional Languages
##########
# Install Nodejs
config.vm.provision "shell", path: "#{github_url}/scripts/nodejs.sh", privileged: false, args: nodejs_packages.unshift(nodejs_version, github_url)
# Install Ruby Version Manager (RVM)
# config.vm.provision "shell", path: "#{github_url}/scripts/rvm.sh", privileged: false, args: ruby_gems.unshift(ruby_version)
# Install Go Version Manager (GVM)
# config.vm.provision "shell", path: "#{github_url}/scripts/go.sh", privileged: false, args: [go_version]
####
# Frameworks and Tooling
##########
# Provision Composer
# You may pass a github auth token as the first argument
# config.vm.provision "shell", path: "#{github_url}/scripts/composer.sh", privileged: false, args: [github_pat, composer_packages.join(" ")]
# Provision Laravel
# config.vm.provision "shell", path: "#{github_url}/scripts/laravel.sh", privileged: false, args: [server_ip, laravel_root_folder, public_folder, laravel_version]
# Provision Symfony
# config.vm.provision "shell", path: "#{github_url}/scripts/symfony.sh", privileged: false, args: [server_ip, symfony_root_folder, public_folder]
# Install Screen
# config.vm.provision "shell", path: "#{github_url}/scripts/screen.sh"
# Install Mailcatcher
# config.vm.provision "shell", path: "#{github_url}/scripts/mailcatcher.sh"
# Install git-ftp
# config.vm.provision "shell", path: "#{github_url}/scripts/git-ftp.sh", privileged: false
# Install Ansible
# config.vm.provision "shell", path: "#{github_url}/scripts/ansible.sh"
# Install Android
# config.vm.provision "shell", path: "#{github_url}/scripts/android.sh"
####
# Local Scripts
# Any local scripts you may want to run post-provisioning.
# Add these to the same directory as the Vagrantfile.
##########
# config.vm.provision "shell", path: "./local-script.sh"
end

176
assets/css/style.css
View File

@ -1,176 +0,0 @@
* {
padding: 0;
margin: 0;
}
body {
color: #556270;
font-family: Arial, Helvetica, sans-serif;
font-size: 12px;
font-style: normal;
font-variant: normal;
font-weight: normal;
line-height: 20px;
background-color: #FFF;
}
a {
font-weight: bold;
text-decoration: none;
color: #D6156C;
}
a:hover {
color: #f56991;
}
#wrapper {
margin: 0 auto;
padding: 10px;
max-width: 600px;
}
@media (min-width: 480px) {
#wrapper {
margin: 20px auto;
}
}
.header {
font-size: 22px;
font-weight: bold;
margin-bottom: 10px;
}
.header .status_title {
color: #BBB;
text-transform: uppercase;
line-height: 24px;
}
.share_buttons {
width: auto;
float: right;
}
.share_buttons .share_button {
float: left;
display: block;
}
#advert{
background-color: #FFEAF2;
height: 20px;
padding: 15px 0;
width: 100%;
}
.ad{
margin: auto;
width: 600px;
}
#return {
font-size: 14px;
}
#intro {
font-family: Georgia;
font-size: 14px;
line-height: 24px;
}
#intro p {
margin-bottom: 10px;
}
#desc {
font-family: Georgia;
font-size: 14px;
line-height: 24px;
}
#desc p {
margin-bottom: 10px;
}
#desc .reference {
font-size: 13px;
}
#statuses {
margin-top: 20px;
}
.status_list {
margin-bottom: 20px;
}
.status_list .head {
border-bottom: 2px solid #EEE;
margin-bottom: 10px;
padding-bottom: 2px;
}
.status_list .head .title {
font-weight: bold;
font-size: 14px;
float: left;
text-transform: lowercase;
}
.status_list .head .description {
font-style: italic;
float: right;
}
.status {
height: 70px;
float: left;
overflow: hidden;
width: 100%;
}
@media (min-width: 480px) {
.status {
margin: 0 2% 0 0;
width: 30%;
}
}
.status_list .status .st {
font-size: 14px;
font-weight: bold;
}
.status_list .status .description {
font-size: 11px;
height: 46px;
overflow: hidden;
}
#code_references {
margin: 20px 0;
}
.info_list {
font-size: 14px;
}
.info_list .info_item .title {
width: 200px;
float: left;
}
.info_list .info_item .value {
float: left;
}
#footer {
margin-top: 10px;
font-size: 11px;
}
.clear {
clear: both;
}

BIN
assets/img/favicon.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 312 B

22
bower.json Normal file
View File

@ -0,0 +1,22 @@
{
"name": "httpstatus.es",
"description": "An easy to reference directory of HTTP Status Codes",
"main": "build.js",
"authors": [
"Samuel Ryan <sam@samryan.co.uk>"
],
"license": "MIT",
"homepage": "https://github.com/citricsquid/httpstatus.es",
"moduleType": [],
"private": true,
"ignore": [
"**/.*",
"node_modules",
"bower_components",
"test",
"tests"
],
"dependencies": {
"Skeleton-Sass": "skeleton-scss#*"
}
}

58
build.js Normal file
View File

@ -0,0 +1,58 @@
var Metalsmith = require('metalsmith');
var markdown = require('metalsmith-markdown');
var collections = require('metalsmith-collections');
var layouts = require('metalsmith-layouts');
var branch = require('metalsmith-branch');
var sass = require('metalsmith-sass');
var elevate = require('metalsmith-elevate');
var ignore = require('metalsmith-ignore');
var collectionGrouping = require('metalsmith-collection-grouping');
var fingerprint = require('metalsmith-fingerprint-ignore');
var metalsmith = Metalsmith(__dirname);
metalsmith
.source('contents')
.destination('build')
.use(collections({
pages: {
pattern: '*.md'
},
codes: {
pattern: 'codes/*.md',
sortBy: 'code'
}
}))
.use(collectionGrouping({
codes: {
groupBy: 'set', // set instead of class, because class is a reserved word...
meta: 'codes/classes.json'
}
}))
.use(branch('*.scss')
.use(sass())
)
.use(fingerprint({
pattern: ['style.css', 'favicon.ico']
}))
.use(branch('**/*.md')
.use(markdown())
.use(layouts({
engine: 'jade',
directory: 'templates',
default: 'code.jade',
pretty: true
}))
)
.use(elevate('codes/*.html'))
.use(ignore('**/*.json'))
.build(function (err) {
if (err) throw err;
console.log('Build successful!');
});

14
circle.yml Normal file
View File

@ -0,0 +1,14 @@
machine:
node:
version: 4.1.0
dependencies:
post:
- bower install
- node build
deployment:
production:
branch: master
commands:
- ./deploy.sh

89
codes/1.json
View File

@ -1,89 +0,0 @@
{
"class":{
"title":"Informational",
"class":"1"
},
"codes":{
"100":{
"code":"100",
"title":"Continue",
"summary":"Client should continue with request",
"descriptions":{
"wikipedia":{
"body":"This means that the server has received the request headers, and that the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). If the request body is large, sending it to a server when a request has already been rejected based upon inappropriate headers is inefficient. To have a server check if the request could be accepted based on the request's headers alone, a client must send Expect: 100-continue as a header in its initial request and check if a 100 Continue status code is received in response before continuing (or receive 417 Expectation Failed and not continue).",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#100"
},
"ietf":{
"body":"The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":continue"
}
}
},
"101":{
"code":"101",
"title":"Switching Protocols",
"summary":"Server is switching protocols",
"descriptions":{
"wikipedia":{
"body":"This means the requester has asked the server to switch protocols and the server is acknowledging that it will do so.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#101"
},
"ietf":{
"body":"The server understands and is willing to comply with the client's request, via the Upgrade message header field, for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response. \r\nThe protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":switching_protocols"
}
}
},
"102":{
"code":"102",
"title":"Processing (WebDAV) (RFC 2518)",
"summary":"Server has received and is processing the request",
"descriptions":{
"wikipedia":{
"body":"As a WebDAV request may contain many sub-requests involving file operations, it may take a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet. This prevents the client from timing out and assuming the request was lost.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#102"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":processing"
}
}
},
"103":{
"code":"103",
"title":"Checkpoint",
"summary":"resume aborted PUT or POST requests",
"descriptions":{
"wikipedia":{
"body":"This code is used in the Resumable HTTP Requests Proposal to resume aborted PUT or POST requests.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#103"
}
}
},
"122":{
"code":"122",
"title":"Request-URI too long",
"summary":"URI is longer than a maximum of 2083 characters",
"descriptions":{
"wikipedia":{
"body":"This is a non-standard IE7-only code which means the URI is longer than a maximum of 2083 characters.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#122"
}
}
}
}
}

200
codes/2.json
View File

@ -1,200 +0,0 @@
{
"class":{
"title":"Success",
"class":"2"
},
"codes":{
"200":{
"code":"200",
"title":"OK",
"summary":"standard response for successful HTTP requests",
"descriptions":{
"wikipedia":{
"body":"Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#200"
},
"ietf":{
"body":"The request has succeeded. The information returned with the response is dependent on the method used in the request, for example: GET an entity corresponding to the requested resource is sent in the response; HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body; POST an entity describing or containing the result of the action;",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":ok"
}
}
},
"201":{
"code":"201",
"title":"Created",
"summary":"request has been fulfilled; new resource created",
"descriptions":{
"wikipedia":{
"body":"The request has been fulfilled and resulted in a new resource being created.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#201"
},
"ietf":{
"body":"The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.\r\n A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":created"
}
}
},
"202":{
"code":"202",
"title":"Accepted",
"summary":"request accepted, processing pending",
"descriptions":{
"wikipedia":{
"body":"The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.[2]",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#202"
},
"ietf":{
"body":"The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this. \r\nThe 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":accepted"
}
}
},
"203":{
"code":"203",
"title":"Non-Authoritative Information (since HTTP\/1.1)",
"summary":"request processed, information may be from another source",
"descriptions":{
"wikipedia":{
"body":"The server successfully processed the request, but is returning information that may be from another source.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#203"
},
"ietf":{
"body":"The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK).",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":non_authoritative_information"
}
}
},
"204":{
"code":"204",
"title":"No Content",
"summary":"request processed, no content returned",
"descriptions":{
"wikipedia":{
"body":"The server successfully processed the request, but is not returning any content.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#204"
},
"ietf":{
"body":"The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.\r\nIf the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.\r\nThe 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":no_content"
}
}
},
"205":{
"code":"205",
"title":"Reset Content",
"summary":"request processed, no content returned, reset document view",
"descriptions":{
"wikipedia":{
"body":"The server successfully processed the request, but is not returning any content. Unlike a 204 response, this response requires that the requester reset the document view.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#205"
},
"ietf":{
"body":"The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":reset_content"
}
}
},
"206":{
"code":"206",
"title":"Partial Content",
"summary":"partial resource return due to request header",
"descriptions":{
"wikipedia":{
"body":"The server is delivering only part of the resource due to a range header sent by the client. The range header is used by tools like wget to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#206"
},
"ietf":{
"body":"The server has fulfilled the partial GET request for the resource. The request MUST have included a Range header field indicating the desired range, and MAY have included an If-Range header field to make the request conditional.\r\nThe response MUST include the following header fields:\r\nEither a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart\/byteranges Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body.\r\nDate\r\nETag and\/or Content-Location, if the header would have been sent in a 200 response to the same request\r\nExpires, Cache-Control, and\/or Vary, if the field-value might differ from that sent in any previous response for the same variant\r\nIf the 206 response is the result of an If-Range request that used a strong cache validator, the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.\r\nA cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly.\r\nA cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":partial_content"
}
}
},
"207":{
"code":"207",
"title":"Multi-Status (WebDAV) (RFC 4918)",
"summary":"XML, can contain multiple separate responses",
"descriptions":{
"wikipedia":{
"body":"The message body that follows is an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#207"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":multi_status"
}
}
},
"208":{
"code":"208",
"title":"Already Reported (WebDAV) (RFC 5842)",
"summary":"results previously returned ",
"descriptions":{
"wikipedia":{
"body":"The members of a DAV binding have already been enumerated in a previous reply to this request, and are not being included again.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#208"
}
}
},
"226":{
"code":"226",
"title":"IM Used (RFC 3229)",
"summary":"request fulfilled, reponse is instance-manipulations",
"descriptions":{
"wikipedia":{
"body":"The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#226"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":im_used"
}
}
}
}
}

187
codes/3.json
View File

@ -1,187 +0,0 @@
{
"class":{
"title":"Redirection",
"class":"3"
},
"codes":{
"300":{
"code":"300",
"title":"Multiple Choices",
"summary":"multiple options for the resource delivered",
"descriptions":{
"wikipedia":{
"body":"Indicates multiple options for the resource that the client may follow. It, for instance, could be used to present different format options for video, list files with different extensions, or word sense disambiguation.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#300"
},
"ietf":{
"body":"The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.\r\nUnless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.\r\nIf the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":multiple_choices"
}
}
},
"301":{
"code":"301",
"title":"Moved Permanently",
"summary":"this and all future requests directed to the given URI",
"descriptions":{
"wikipedia":{
"body":"This and all future requests should be directed to the given URI.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#301"
},
"ietf":{
"body":"The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.\r\nThe new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).\r\nIf the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.\r\nNote: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP\/1.0 user agents will erroneously change it into a GET request.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":moved_permanently"
}
}
},
"302":{
"code":"302",
"title":"Found",
"summary":"temporary response to request found via alternative URI",
"descriptions":{
"wikipedia":{
"body":"This is an example of industrial practice contradicting the standard. HTTP\/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was \"Moved Temporarily\"), but popular browsers implemented 302 with the functionality of a 303 See Other. Therefore, HTTP\/1.1 added status codes 303 and 307 to distinguish between the two behaviours. However, some Web applications and frameworks use the 302 status code as if it were the 303.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#302"
},
"ietf":{
"body":"The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.\r\nThe temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).\r\nIf the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.\r\nNote: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":found"
}
}
},
"303":{
"code":"303",
"title":"See Other",
"summary":"permanent response to request found via alternative URI",
"descriptions":{
"wikipedia":{
"body":"The response to the request can be found under another URI using a GET method. When received in response to a POST (or PUT\/DELETE), it should be assumed that the server has received the data and the redirect should be issued with a separate GET message.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#303"
},
"ietf":{
"body":"The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.\r\nThe different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).\r\nNote: Many pre-HTTP\/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":see_other"
}
}
},
"304":{
"code":"304",
"title":"Not Modified",
"summary":"resource has not been modified since last requested",
"descriptions":{
"wikipedia":{
"body":"Indicates the resource has not been modified since last requested. Typically, the HTTP client provides a header like the If-Modified-Since header to provide a time against which to compare. Using this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then sent again using more bandwidth of the server and client.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#304"
},
"ietf":{
"body":"If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.\r\nThe response MUST include the following header fields:\r\nDate, unless its omission is required\r\nIf a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by RFC 2068), caches will operate correctly.\r\nETag and\/or Content-Location, if the header would have been sent in a 200 response to the same request\r\nExpires, Cache-Control, and\/or Vary, if the field-value might differ from that sent in any previous response for the same variant\r\nIf the conditional GET used a strong cache validator, the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.\r\nIf a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.\r\nIf a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":not_modified"
}
}
},
"305":{
"code":"305",
"title":"Use Proxy (since HTTP\/1.1)",
"summary":"content located elsewhere, retrieve from there",
"descriptions":{
"wikipedia":{
"body":"Many HTTP clients (such as Mozilla and Internet Explorer) do not correctly handle responses with this status code, primarily for security reasons.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#305"
},
"ietf":{
"body":"The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.\r\nNote: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing these limitations has significant security consequences.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":use_proxy"
}
}
},
"306":{
"code":"306",
"title":"Switch Proxy",
"summary":"subsequent requests should use the specified proxy",
"descriptions":{
"wikipedia":{
"body":"No longer used. Originally meant \"Subsequent requests should use the specified proxy.\"",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#306"
},
"ietf":{
"body":"The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
}
},
"307":{
"code":"307",
"title":"Temporary Redirect (since HTTP\/1.1)",
"summary":"connect again to different URI as provided",
"descriptions":{
"wikipedia":{
"body":"In this occasion, the request should be repeated with another URI, but future requests can still use the original URI. In contrast to 303, the request method should not be changed when reissuing the original request. For instance, a POST request must be repeated using another POST request.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#307"
},
"ietf":{
"body":"The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.\r\nThe temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP\/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.\r\nIf the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":temporary_redirect"
}
}
},
"308":{
"code":"308",
"title":"Permanent Redirect",
"summary":"connect again to a different URI using the same method",
"descriptions":{
"wikipedia":{
"body":"The request, and all future requests should be repeated using another URI. 307 and 308 (as proposed) parallel the behaviours of 302 and 301, but do not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#308"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":no_content"
}
}
}
}
}

570
codes/4.json
View File

@ -1,570 +0,0 @@
{
"class":{
"title":"Client Error",
"class":"4"
},
"codes":{
"400":{
"code":"400",
"title":"Bad Request",
"summary":"request cannot be fulfilled due to bad syntax",
"descriptions":{
"wikipedia":{
"body":"The request cannot be fulfilled due to bad syntax.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#400"
},
"ietf":{
"body":"The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":bad_request"
}
}
},
"401":{
"code":"401",
"title":"Unauthorized",
"summary":"authentication is possible but has failed ",
"descriptions":{
"wikipedia":{
"body":"Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#401"
},
"ietf":{
"body":"The request requires user authentication. The response MUST include a WWW-Authenticate header field containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field. If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in \"HTTP Authentication: Basic and Digest Access Authentication\".",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":unauthorized"
}
}
},
"402":{
"code":"402",
"title":"Payment Required",
"summary":"payment required, reserved for future use",
"descriptions":{
"wikipedia":{
"body":"Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, but that has not happened, and this code is not usually used. As an example of its use, however, Apple's MobileMe service generates a 402 error (\"httpStatusCode:402\" in the Mac OS X Console log) if the MobileMe account is delinquent.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#402"
},
"ietf":{
"body":"This code is reserved for future use.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":payment_required"
}
}
},
"403":{
"code":"403",
"title":"Forbidden",
"summary":"server refuses to respond to request",
"descriptions":{
"wikipedia":{
"body":"The request was a legal request, but the server is refusing to respond to it. Unlike a 401 Unauthorized response, authenticating will make no difference.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#403"
},
"ietf":{
"body":"The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":forbidden"
}
}
},
"404":{
"code":"404",
"title":"Not Found",
"summary":"requested resource could not be found",
"descriptions":{
"wikipedia":{
"body":"The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#404"
},
"ietf":{
"body":"The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":not_found"
}
}
},
"405":{
"code":"405",
"title":"Method Not Allowed",
"summary":"request method not supported by that resource",
"descriptions":{
"wikipedia":{
"body":"A request was made of a resource using a request method not supported by that resource; for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#405"
},
"ietf":{
"body":"The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":method_not_allowed"
}
}
},
"406":{
"code":"406",
"title":"Not Acceptable",
"summary":"content not acceptable according to the Accept headers",
"descriptions":{
"wikipedia":{
"body":"The requested resource is only capable of generating content not acceptable according to the Accept headers sent in the request.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#406"
},
"ietf":{
"body":"The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.\r\nUnless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.\r\nNote: HTTP\/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable.\r\nIf the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":not_acceptable"
}
}
},
"407":{
"code":"407",
"title":"Proxy Authentication Required",
"summary":"client must first authenticate itself with the proxy",
"descriptions":{
"wikipedia":{
"body":"The client must first authenticate itself with the proxy.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#407"
},
"ietf":{
"body":"This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field. HTTP access authentication is explained in \"HTTP Authentication: Basic and Digest Access Authentication\".",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":proxy_authentication_required"
}
}
},
"408":{
"code":"408",
"title":"Request Timeout",
"summary":"server timed out waiting for the request",
"descriptions":{
"wikipedia":{
"body":"The server timed out waiting for the request. According to W3 HTTP specifications: \"The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.\"",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#408"
},
"ietf":{
"body":"The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":request_timeout"
}
}
},
"409":{
"code":"409",
"title":"Conflict",
"summary":"request could not be processed because of conflict",
"descriptions":{
"wikipedia":{
"body":"Indicates that the request could not be processed because of conflict in the request, such as an edit conflict.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#409"
},
"ietf":{
"body":"The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.\r\nConflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":conflict"
}
}
},
"410":{
"code":"410",
"title":"Gone",
"summary":"resource is no longer available and will not be available again",
"descriptions":{
"wikipedia":{
"body":"Indicates that the resource requested is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource again in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a \"404 Not Found\" may be used instead.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#410"
},
"ietf":{
"body":"The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.\r\nThe 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as \"gone\" or to keep the mark for any length of time -- that is left to the discretion of the server owner.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":gone"
}
}
},
"411":{
"code":"411",
"title":"Length Required",
"summary":"request did not specify the length of its content",
"descriptions":{
"wikipedia":{
"body":"The request did not specify the length of its content, which is required by the requested resource.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#411"
},
"ietf":{
"body":"The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":length_required"
}
}
},
"412":{
"code":"412",
"title":"Precondition Failed",
"summary":"server does not meet request preconditions",
"descriptions":{
"wikipedia":{
"body":"The server does not meet one of the preconditions that the requester put on the request.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#412"
},
"ietf":{
"body":"The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":precondition_failed"
}
}
},
"413":{
"code":"413",
"title":"Request Entity Too Large",
"summary":"request is larger than the server is willing or able to process",
"descriptions":{
"wikipedia":{
"body":"The request is larger than the server is willing or able to process.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#413"
},
"ietf":{
"body":"The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.\r\nIf the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":request_entity_too_large"
}
}
},
"414":{
"code":"414",
"title":"Request-URI Too Long",
"summary":"URI provided was too long for the server to process",
"descriptions":{
"wikipedia":{
"body":"The URI provided was too long for the server to process.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#414"
},
"ietf":{
"body":"The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI \"black hole\" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":request_uri_too_long"
}
}
},
"415":{
"code":"415",
"title":"Unsupported Media Type",
"summary":"server does not support media type",
"descriptions":{
"wikipedia":{
"body":"The request entity has a media type which the server or resource does not support. For example, the client uploads an image as image\/svg+xml, but the server requires that images use a different format.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#415"
},
"ietf":{
"body":"The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":unsupported_media_type"
}
}
},
"416":{
"code":"416",
"title":"Requested Range Not Satisfiable",
"summary":"client has asked for unprovidable portion of the file",
"descriptions":{
"wikipedia":{
"body":"The client has asked for a portion of the file, but the server cannot supply that portion. For example, if the client asked for a part of the file that lies beyond the end of the file.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#416"
},
"ietf":{
"body":"A server SHOULD return a response with this status code if a request included a Range request-header field, and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)\r\nWhen this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource. This response MUST NOT use the multipart\/byteranges content- type.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":requested_range_not_satisfiable"
}
}
},
"417":{
"code":"417",
"title":"Expectation Failed",
"summary":"server cannot meet requirements of Expect request-header field",
"descriptions":{
"wikipedia":{
"body":"The server cannot meet the requirements of the Expect request-header field.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#417"
},
"ietf":{
"body":"The expectation given in an Expect request-header field could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":expectation_failed"
}
}
},
"418":{
"code":"418",
"title":"I'm a teapot (RFC 2324)",
"summary":"I'm a teapot",
"descriptions":{
"wikipedia":{
"body":"This code was defined in 1998 as one of the traditional IETF April Fools' jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. However, known implementations do exist. An Nginx HTTP server uses this code to simulate goto-like behaviour in its configuration.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#418"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":\"i'm_a_teapot\" <small>(<a href=\"https://gist.github.com/3134563\">explanation<\/a> <sup>gist.github.com<\/sup>)<\/small>"
}
}
},
"420":{
"code":"420",
"title":"Enhance Your Calm",
"summary":"Twitter rate limiting",
"descriptions":{
"wikipedia":{
"body":"Returned by the Twitter Search and Trends API when the client is being rate limited.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#420"
}
}
},
"422":{
"code":"422",
"title":"Unprocessable Entity (WebDAV) (RFC 4918)",
"summary":"request unable to be followed due to semantic errors",
"descriptions":{
"wikipedia":{
"body":"The request was well-formed but was unable to be followed due to semantic errors.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#422"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":unprocessable_entity"
}
}
},
"423":{
"code":"423",
"title":"Locked (WebDAV) (RFC 4918)",
"summary":"resource that is being accessed is locked",
"descriptions":{
"wikipedia":{
"body":"The resource that is being accessed is locked.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#423"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":locked"
}
}
},
"424":{
"code":"424",
"title":"Failed Dependency (WebDAV) (RFC 4918)",
"summary":"request failed due to failure of a previous request",
"descriptions":{
"wikipedia":{
"body":"The request failed due to failure of a previous request (e.g. a PROPPATCH).",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#424"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":failed_dependency"
}
}
},
"426":{
"code":"426",
"title":"Upgrade Required (RFC 2817)",
"summary":"client should switch to a different protocol",
"descriptions":{
"wikipedia":{
"body":"The client should switch to a different protocol such as TLS\/1.0.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#426"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":upgrade_required"
}
}
},
"428":{
"code":"428",
"title":"Precondition Required",
"summary":"origin server requires the request to be conditional",
"descriptions":{
"wikipedia":{
"body":"The origin server requires the request to be conditional. Intended to prevent \"the 'lost update' problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.\" Proposed in an Internet-Draft.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#428"
}
}
},
"429":{
"code":"429",
"title":"Too Many Requests",
"summary":"user has sent too many requests in a given amount of time",
"descriptions":{
"wikipedia":{
"body":"The user has sent too many requests in a given amount of time. Intended for use with rate limiting schemes. Proposed in an Internet-Draft.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#429"
}
}
},
"431":{
"code":"431",
"title":"Request Header Fields Too Large",
"summary":"server is unwilling to process the request",
"descriptions":{
"wikipedia":{
"body":"The server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large. Proposed in an Internet-Draft.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#431"
}
}
},
"444":{
"code":"444",
"title":"No Response",
"summary":"server returns no information and closes the connection",
"descriptions":{
"wikipedia":{
"body":"An nginx HTTP server extension. The server returns no information to the client and closes the connection (useful as a deterrent for malware).",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#444"
}
}
},
"449":{
"code":"449",
"title":"Retry With",
"summary":"request should be retried after performing action",
"descriptions":{
"wikipedia":{
"body":"A Microsoft extension. The request should be retried after performing the appropriate action.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#449"
}
}
},
"450":{
"code":"450",
"title":"Blocked by Windows Parental Controls",
"summary":"Windows Parental Controls blocking access to webpage",
"descriptions":{
"wikipedia":{
"body":"A Microsoft extension. This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#450"
}
}
},
"451":{
"code":"451",
"title":"Wrong Exchange server",
"summary":"the server cannot reach the client's mailbox",
"descriptions":{
"MS-ASHTTP":{
"body":"If the client is attempting to connect to the wrong server (that is, a server that cannot access the user's mailbox), or if there is a more efficient server to use to reach the user's mailbox, then a 451 Redirect error is returned.",
"link":"http://msdn.microsoft.com/en-us/library/gg651019"
}
}
},
"499":{
"code":"499",
"title":"Client Closed Request",
"summary":"connection closed by client while HTTP server is processing",
"descriptions":{
"wikipedia":{
"body":"An Nginx HTTP server extension. This code is introduced to log the case when the connection is closed by client while HTTP server is processing its request, making server unable to send the HTTP header back.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#499"
}
}
}
}
}

234
codes/5.json
View File

@ -1,234 +0,0 @@
{
"class":{
"title":"Server Error",
"class":"5"
},
"codes":{
"500":{
"code":"500",
"title":"Internal Server Error",
"summary":"generic error message",
"descriptions":{
"wikipedia":{
"body":"A generic error message, given when no more specific message is suitable.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#500"
},
"ietf":{
"body":"The server encountered an unexpected condition which prevented it from fulfilling the request.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":internal_server_error"
}
}
},
"501":{
"code":"501",
"title":"Not Implemented",
"summary":"server does not recognise method or lacks ability to fulfill",
"descriptions":{
"wikipedia":{
"body":"The server either does not recognise the request method, or it lacks the ability to fulfill the request.[2]",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#501"
},
"ietf":{
"body":"The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":not_implemented"
}
}
},
"502":{
"code":"502",
"title":"Bad Gateway",
"summary":"server received an invalid response from upstream server",
"descriptions":{
"wikipedia":{
"body":"The server was acting as a gateway or proxy and received an invalid response from the upstream server.[2]",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#502"
},
"ietf":{
"body":"The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":bad_gateway"
}
}
},
"503":{
"code":"503",
"title":"Service Unavailable",
"summary":"server is currently unavailable",
"descriptions":{
"wikipedia":{
"body":"The server is currently unavailable (because it is overloaded or down for maintenance).[2] Generally, this is a temporary state.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#503"
},
"ietf":{
"body":"The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.\r\nNote: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":service_unavailable"
}
}
},
"504":{
"code":"504",
"title":"Gateway Timeout",
"summary":"gateway did not receive response from upstream server",
"descriptions":{
"wikipedia":{
"body":"The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.[2]",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#504"
},
"ietf":{
"body":"The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.\r\nNote: Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":gateway_timeout"
}
}
},
"505":{
"code":"505",
"title":"HTTP Version Not Supported",
"summary":"server does not support the HTTP protocol version",
"descriptions":{
"wikipedia":{
"body":"The server does not support the HTTP protocol version used in the request.[2]",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#505"
},
"ietf":{
"body":"The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.",
"link":"http:\/\/www.ietf.org\/rfc\/rfc2616.txt"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":http_version_not_supported"
}
}
},
"506":{
"code":"506",
"title":"Variant Also Negotiates (RFC 2295)",
"summary":"content negotiation for the request results in a circular reference",
"descriptions":{
"wikipedia":{
"body":"Transparent content negotiation for the request results in a circular reference.[23]",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#506"
}
}
},
"507":{
"code":"507",
"title":"Insufficient Storage (WebDAV) (RFC 4918)",
"summary":"server is unable to store the representation",
"descriptions":{
"wikipedia":{
"body":"The server is unable to store the representation needed to complete the request.[7]",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#507"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":insufficient_storage"
}
}
},
"508":{
"code":"508",
"title":"Loop Detected (WebDAV) (RFC 5842)",
"summary":"server detected an infinite loop while processing the request",
"descriptions":{
"wikipedia":{
"body":"The server detected an infinite loop while processing the request (sent in lieu of 208).",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#508"
}
}
},
"509":{
"code":"509",
"title":"Bandwidth Limit Exceeded (Apache bw\/limited extension)",
"summary":"bandwidth limit exceeded",
"descriptions":{
"wikipedia":{
"body":"This status code, while used by many servers, is not specified in any RFCs.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#509"
}
}
},
"510":{
"code":"510",
"title":"Not Extended (RFC 2774)",
"summary":"further extensions to the request are required",
"descriptions":{
"wikipedia":{
"body":"Further extensions to the request are required for the server to fulfill it.[24]",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#510"
}
},
"references":{
"rails":{
"title":"Rails HTTP Status Symbol",
"value":":not_extended"
}
}
},
"511":{
"code":"511",
"title":"Network Authentication Required",
"summary":"client needs to authenticate to gain network access",
"descriptions":{
"wikipedia":{
"body":"The client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g. \"captive portals\" used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot). Proposed in an Internet-Draft.[19]",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#511"
}
}
},
"598":{
"code":"598",
"title":"Network read timeout error",
"summary":"network read timeout behind the proxy ",
"descriptions":{
"wikipedia":{
"body":"This status code is not specified in any RFCs, but is used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#598"
}
}
},
"599":{
"code":"599",
"title":"Network connect timeout error",
"summary":"network connect timeout behind the proxy",
"descriptions":{
"wikipedia":{
"body":"This status code is not specified in any RFCs, but is used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.",
"link":"http:\/\/en.wikipedia.org\/wiki\/List_of_HTTP_status_codes#599"
}
}
}
}
}

6
composer.json
View File

@ -1,6 +0,0 @@
{
"require": {
"klein/klein": "*"
},
"minimum-stability": "dev"
}

25
contents/codes/100.md Normal file
View File

@ -0,0 +1,25 @@
---
set: 1
code: 100
title: Continue
references:
"Rails HTTP Status Symbol": ":continue"
---
The 100 Continue status code indicates that the initial part of a request has
been received and has not yet been rejected by the server. The server intends to
send a final response after the request has been fully received and acted upon.
When the request contains an Expect header field that includes a 100-continue
expectation, the 100 response indicates that the server wishes to receive the
request payload body, as described in
[RFC7231 Section 5.1.1][2]. The
client ought to continue sending the request and discard the 100 response.
If the request did not contain an Expect header field containing the
100-continue expectation, the client can simply discard this interim response.
Source: [RFC7231 Section 6.1.1][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.2.1>
[2]: <http://tools.ietf.org/html/rfc7231#section-5.1.1>

26
contents/codes/101.md Normal file
View File

@ -0,0 +1,26 @@
---
set: 1
code: 101
title: Switching Protocols
references:
"Rails HTTP Status Symbol": ":switching_protocols"
---
The 101 Switching Protocols status code indicates that the server understands
and is willing to comply with the client's request, via the Upgrade header field
([Section 6.7 of RFC7230][2]), for a change in the application protocol being
used on this connection.
The server MUST generate an Upgrade header field in the
response that indicates which protocol(s) will be switched to immediately after
the empty line that terminates the 101 response.
It is assumed that the server will only agree to switch protocols when it is
advantageous to do so. For example, switching to a newer version of HTTP might
be advantageous over older versions, and switching to a real-time, synchronous
protocol might be advantageous when delivering resources that use such features.
Source: [RFC7231 Section 6.2.2][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.2.2>
[2]: <http://tools.ietf.org/html/rfc7230#section-6.7>

28
contents/codes/102.md Normal file
View File

@ -0,0 +1,28 @@
---
set: 1
code: 102
title: Processing
references:
"Rails HTTP Status Symbol": ":processing"
---
The 102 Processing status code is an interim response used to inform the
client that the server has accepted the complete request, but has not yet
completed it.
This status code SHOULD only be sent when the server has a
reasonable expectation that the request will take significant time to complete.
As guidance, if a method is taking longer than 20 seconds (a reasonable, but
arbitrary value) to process the server SHOULD return a 102 (Processing)
response. The server MUST send a final response after the request has been
completed.
Methods can potentially take a long period of time to process, especially
methods that support the Depth header. In such cases the client may time-out the
connection while waiting for a response. To prevent this the server may return a
102 (Processing) status code to indicate to the client that the server is still
processing the method.
Source: [RFC2518 Section 10.1][1]
[1]: <http://tools.ietf.org/html/rfc2518#section-10.1>

40
contents/codes/200.md Normal file
View File

@ -0,0 +1,40 @@
---
set: 2
code: 200
title: OK
references:
"Rails HTTP Status Symbol": ":not_found"
---
The 200 OK status code indicates that the request has succeeded. The payload
sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning of the
payload can be summarized as:
GET a representation of the target resource
HEAD the same representation as GET, but without the representation data
POST a representation of the status of, or results obtained from, the action;
PUT, DELETE a representation of the status of the action;
OPTIONS a representation of the communications options;
TRACE a representation of the request message as received by the end server.
Aside from responses to CONNECT, a 200 response always has a payload, though an
origin server MAY generate a payload body of zero length. If no payload is
desired, an origin server ought to send [204 (No Content)](/204) instead. For
CONNECT, no payload is allowed because the successful result is a tunnel, which
begins immediately after the 200 response header section.
A 200 response is cacheable by default; i.e., unless otherwise indicated by the
method definition or explicit cache controls
(see [Section 4.2.2 of RFC7234][2]).
Source: [RFC7231 Section 6.3.1][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.1>
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

24
contents/codes/201.md Normal file
View File

@ -0,0 +1,24 @@
---
set: 2
code: 201
title: Created
references:
"Rails HTTP Status Symbol": ":created"
---
The 201 Created status code indicates that the request has been fulfilled and
has resulted in one or more new resources being created.
The primary resource
created by the request is identified by either a Location header field in the
response or, if no Location field is received, by the effective request URI.
The 201 response payload typically describes and links to the resource(s)
created. See [Section 7.2 of RFC7231][2] for a discussion of the meaning and
purpose of validator header fields, such as ETag and Last-Modified, in a 201
response.
Source: [RFC7231 Section 6.3.2][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.2>
[2]: <http://tools.ietf.org/html/rfc7231#section-7.2

27
contents/codes/202.md Normal file
View File

@ -0,0 +1,27 @@
---
set: 2
code: 202
title: Accepted
references:
"Rails HTTP Status Symbol": ":accepted"
---
The 202 Accepted status code indicates that the request has been accepted for
processing, but the processing has not been completed. The request might or
might not eventually be acted upon, as it might be disallowed when processing
actually takes place.
There is no facility in HTTP for re-sending a status code
from an asynchronous operation.
The 202 response is intentionally noncommittal. Its purpose is to allow a server
to accept a request for some other process (perhaps a batch-oriented process
that is only run once per day) without requiring that the user agent's
connection to the server persist until the process is completed. The
representation sent with this response ought to describe the request's current
status and point to (or embed) a status monitor that can provide the user with
an estimate of when the request will be fulfilled.
Source: [RFC7231 Section 6.3.3][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.3>

32
contents/codes/203.md Normal file
View File

@ -0,0 +1,32 @@
---
set: 2
code: 203
title: Non-authoritative Information
references:
"Rails HTTP Status Symbol": ":non_authoritative_information"
---
The 203 Non-Authoritative Information status code indicates that the request
was successful but the enclosed payload has been modified from that of the
origin server's [200 (OK)](/200) response by a transforming proxy
([Section 5.7.2 of RFC7230][2]).
This status code allows the proxy to notify recipients when a transformation has
been applied, since that knowledge might impact later decisions regarding the
content. For example, future cache validation requests for the content might
only be applicable along the same request path (through the same proxies).
The 203 response is similar to the Warning code of 214 Transformation Applied
([Section 5.5 of RFC7234][3]), which has the advantage of being applicable to
responses with any status code.
A 203 response is cacheable by default; i.e., unless otherwise indicated by the
method definition or explicit cache controls
(see [Section 4.2.2 of RFC7234][4]).
Source: [RFC7231 Section 6.3.4][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.4>
[2]: <http://tools.ietf.org/html/rfc7230#section-5.7.2>
[3]: <http://tools.ietf.org/html/rfc7234#section-5.5>
[4]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

44
contents/codes/204.md Normal file
View File

@ -0,0 +1,44 @@
---
set: 2
code: 204
title: No Content
references:
"Rails HTTP Status Symbol": ":no_content"
---
The 204 No Content status code indicates that the server has successfully
fulfilled the request and that there is no additional content to send in the
response payload body.
Metadata in the response header fields refer to the target resource and its
selected representation after the requested action was applied.
For example, if a 204 status code is received in response to a PUT request and
the response contains an ETag header field, then the PUT was successful and the
ETag field-value contains the entity-tag for the new representation of that
target resource.
The 204 response allows a server to indicate that the action has been
successfully applied to the target resource, while implying that the user agent
does not need to traverse away from its current "document view" (if any). The
server assumes that the user agent will provide some indication of the success
to its user, in accord with its own interface, and apply any new or updated
metadata in the response to its active representation.
For example, a 204 status code is commonly used with document editing interfaces
corresponding to a "save" action, such that the document being saved remains
available to the user for editing. It is also frequently used with interfaces
that expect automated data transfers to be prevalent, such as within distributed
version control systems.
A 204 response is terminated by the first empty line after the header fields
because it cannot contain a message body.
A 204 response is cacheable by default; i.e., unless otherwise indicated by the
method definition or explicit cache controls
(see [Section 4.2.2 of RFC7234][2]).
Source: [RFC7231 Section 6.3.5][1]
[2]: <http://tools.ietf.org/html/rfc7231#section-6.3.5>
[1]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

31
contents/codes/205.md Normal file
View File

@ -0,0 +1,31 @@
---
set: 2
code: 205
title: Reset Content
references:
"Rails HTTP Status Symbol": ":reset_content"
---
The 205 Reset Content status code indicates that the server has fulfilled the
request and desires that the user agent reset the "document view", which caused
the request to be sent, to its original state as received from the origin
server.
This response is intended to support a common data entry use case where the user
receives content that supports data entry (a form, notepad, canvas, etc.),
enters or manipulates data in that space, causes the entered data to be
submitted in a request, and then the data entry mechanism is reset for the next
entry so that the user can easily initiate another input action.
Since the 205 status code implies that no additional content will be provided, a
server MUST NOT generate a payload in a 205 response. In other words, a server
MUST do one of the following for a 205 response: a) indicate a zero-length body
for the response by including a Content-Length header field with a value of 0;
b) indicate a zero-length payload for the response by including a
Transfer-Encoding header field with a value of chunked and a message body
consisting of a single chunk of zero-length; or, c) close the connection
immediately after sending the blank line terminating the header section.
Source: [RFC7231 Section 6.3.6][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.6>

109
contents/codes/206.md Normal file
View File

@ -0,0 +1,109 @@
---
set: 2
code: 206
title: Partial Content
---
The 206 Partial Content status code indicates that the server is successfully
fulfilling a range request for the target resource by transferring one or more
parts of the selected representation that correspond to the satisfiable ranges
found in the request's Range header field (see [RFC7233 Section 3.1][2]).
If a single part is being transferred, the server generating the 206 response
MUST generate a Content-Range header field, describing what range of the
selected representation is enclosed, and a payload consisting of the range. For
example:
```
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
... 26012 bytes of partial image data ...
```
If multiple parts are being transferred, the server generating the 206 response
MUST generate a "multipart/byteranges" payload, as defined in
[RFC7233 Appendix A][3], and a Content-Type header field containing the
multipart/byteranges media type and its required boundary parameter. To avoid
confusion with single-part responses, a server MUST NOT generate a Content-Range
header field in the HTTP header section of a multiple part response (this field
will be sent in each part instead).
Within the header area of each body part in the multipart payload, the server
MUST generate a Content-Range header field corresponding to the range being
enclosed in that body part. If the selected representation would have had a
Content-Type header field in a [200 (OK)](/200) response, the server SHOULD
generate that same Content-Type field in the header area of each body part.
For example:
```
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000
...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000
...the second range
--THIS_STRING_SEPARATES--
```
When multiple ranges are requested, a server MAY coalesce any of the ranges that
overlap, or that are separated by a gap that is smaller than the overhead of
sending multiple parts, regardless of the order in which the corresponding
byte-range-spec appeared in the received Range header field. Since the typical
overhead between parts of a multipart/byteranges payload is around 80 bytes,
depending on the selected representation's media type and the chosen boundary
parameter length, it can be less efficient to transfer many small disjoint parts
than it is to transfer the entire selected representation.
A server MUST NOT generate a multipart response to a request for a single range,
since a client that does not request multiple parts might not support multipart
responses. However, a server MAY generate a multipart/byteranges payload with
only a single body part if multiple ranges were requested and only one range was
found to be satisfiable or only one range remained after coalescing. A client
that cannot process a multipart/byteranges response MUST NOT generate a request
that asks for multiple ranges.
When a multipart response payload is generated, the server SHOULD send the parts
in the same order that the corresponding byte-range-spec appeared in the
received Range header field, excluding those ranges that were deemed
unsatisfiable or that were coalesced into other ranges. A client that receives a
multipart response MUST inspect the Content-Range header field present in each
body part in order to determine which range is contained in that body part; a
client cannot rely on receiving the same ranges that it requested, nor the same
order that it requested.
When a 206 response is generated, the server MUST generate the following header
fields, in addition to those required above, if the field would have been sent
in a [200 (OK)](/200) response to the same request: Date, Cache-Control, ETag,
Expires, Content-Location, and Vary.
If a 206 is generated in response to a request with an If-Range header field,
the sender SHOULD NOT generate other representation header fields beyond those
required above, because the client is understood to already have a prior
response containing those header fields. Otherwise, the sender MUST generate all
of the representation header fields that would have been sent in a
[200 (OK)](/200) response to the same request.
A 206 response is cacheable by default; i.e., unless otherwise indicated by
explicit cache controls (see [Section 4.2.2 of RFC7234][4]).
Source: [RFC7233 Section 4.1][1]
[1]: <http://tools.ietf.org/html/rfc7233#section-4.1>
[2]: <http://tools.ietf.org/html/rfc7233#section-3.1>
[3]: <http://tools.ietf.org/html/rfc7233#appendix-A>
[4]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

47
contents/codes/207.md Normal file
View File

@ -0,0 +1,47 @@
---
set: 2
code: 207
title: Multi-Status
references:
"Rails HTTP Status Symbol": ":multi_status"
---
A Multi-Status response conveys information about multiple resources in
situations where multiple status codes might be appropriate.
The default Multi-Status response body is a text/xml or application/xml HTTP
entity with a 'multistatus' root element. Further elements contain 200, 300,
400, and 500 series status codes generated during the method invocation. 100
series status codes SHOULD NOT be recorded in a 'response' XML element.
Although '207' is used as the overall response status code, the recipient needs
to consult the contents of the multistatus response body for further information
about the success or failure of the method execution. The response MAY be used
in success, partial success and also in failure situations.
The 'multistatus' root element holds zero or more 'response' elements in any
order, each with information about an individual resource. Each 'response'
element MUST have an 'href' element to identify the resource.
A Multi-Status response uses one out of two distinct formats for representing
the status:
1\. A 'status' element as child of the 'response' element indicates the status
of the message execution for the identified resource as a whole (for instance,
see [RFC4918 Section 9.6.2][2]). Some method definitions provide information
about specific status codes clients should be prepared to see in a response.
However, clients MUST be able to handle other status codes, using the generic
rules defined in [Section 10 of RFC2616][3].
2\. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat'
element instead of 'status', providing information about individual properties
of a resource. This format is specific to PROPFIND and PROPPATCH, and is
described in detail in [RFC4918 Sections 9.1][4] and [RFC4918 9.2][5].
Source: [RFC4918 Section 13][1]
[1]: <http://tools.ietf.org/html/rfc4918#section-13>
[2]: <http://tools.ietf.org/html/rfc4918#section-9.6.2>
[3]: <http://tools.ietf.org/html/rfc2616#section-10>
[4]: <http://tools.ietf.org/html/rfc4918#section-9.1>
[5]: <http://tools.ietf.org/html/rfc4918#section-9.2>

37
contents/codes/208.md Normal file
View File

@ -0,0 +1,37 @@
---
set: 2
code: 208
title: Already Reported
---
The 208 Already Reported status code can be used inside a DAV: propstat
response element to avoid enumerating the internal members of multiple bindings
to the same collection repeatedly.
For each binding to a collection inside the request's scope, only one will be
reported with a 200 status, while subsequent DAV:response elements for all other
bindings will use the 208 status, and no DAV:response elements for their
descendants are included.
Note that the 208 status will only occur for "Depth: infinity" requests, and
that it is of particular importance when the multiple collection bindings cause
a bind loop as discussed in [RFC5842 Section 2.2][2].
A client can request the DAV:resource-id property in a PROPFIND request to
guarantee that they can accurately reconstruct the binding structure of a
collection with multiple bindings to a single resource.
For backward compatibility with clients not aware of the 208 status code
appearing in multistatus response bodies, it SHOULD NOT be used unless the
client has signaled support for this specification using the "DAV" request
header (see [RFC5842Section 8.2][3]). Instead, a 508 status should be
returned when a binding loop is discovered. This allows the server to return the
508 as the top-level return status, if it discovers it before it started the
response, or in the middle of a multistatus, if it discovers it in the middle of
streaming out a multistatus response.
Source: [RFC5842 Section 7.1][1]
[1]: <http://tools.ietf.org/html/rfc5842#section-7.1>
[2]: <http://tools.ietf.org/html/rfc5842#section-2.2>
[3]: <http://tools.ietf.org/html/rfc5842#section-8.2>

37
contents/codes/226.md Normal file
View File

@ -0,0 +1,37 @@
---
set: 2
code: 226
title: IM Used
references:
"Rails HTTP Status Symbol": ":im_used"
---
The server has fulfilled a GET request for the resource, and the response is a
representation of the result of one or more instance-manipulations applied to
the current instance.
The actual current instance might not be available except by combining this
response with other previous or future responses, as appropriate for the
specific instance-manipulation(s). If so, the headers of the resulting instance
are the result of combining the headers from the status-226 response and the
other instances, following the rules in [section 13.5.3][2] of the
HTTP/1.1 specification [10].
The request MUST have included an A-IM header field listing at least
one instance-manipulation. The response MUST include an Etag header
field giving the entity tag of the current instance.
A response received with a status code of 226 MAY be stored by a
cache and used in reply to a subsequent request, subject to the HTTP
expiration mechanism and any Cache-Control headers, and to the
requirements in [section 10.6][3].
A response received with a status code of 226 MAY be used by a cache,
in conjunction with a cache entry for the base instance, to create a
cache entry for the current instance.
Source: [RFC3229 Section 10.4.1][1]
[1]: <http://tools.ietf.org/html/rfc3229#section-10.4.1>
[2]: <http://tools.ietf.org/html/rfc3229#section-13.5.3>
[3]: <http://tools.ietf.org/html/rfc3229#section-10.6>

49
contents/codes/300.md Normal file
View File

@ -0,0 +1,49 @@
---
set: 3
code: 300
title: Multiple Choices
references:
"Rails HTTP Status Symbol": ":multiple_choices"
---
The 300 Multiple Choices status code indicates that the target resource has
more than one representation, each with its own more specific identifier, and
information about the alternatives is being provided so that the user (or user
agent) can select a preferred representation by redirecting its request to one
or more of those identifiers. In other words, the server desires that the user
agent engage in reactive negotiation to select the most appropriate
representation(s) for its needs ([RFC7231 Section 3.4][2]).
If the server has a preferred choice, the server SHOULD generate a Location
header field containing a preferred choice's URI reference. The user agent MAY
use the Location field value for automatic redirection.
For request methods other than HEAD, the server SHOULD generate a payload in the
300 response containing a list of representation metadata and URI reference(s)
from which the user or user agent can choose the one most preferred. The user
agent MAY make a selection from that list automatically if it understands the
provided media type. A specific format for automatic selection is not defined by
this specification because HTTP tries to remain orthogonal to the definition of
its payloads. In practice, the representation is provided in some easily parsed
format believed to be acceptable to the user agent, as determined by shared
design or content negotiation, or in some commonly accepted hypertext format.
A 300 response is cacheable by default; i.e., unless otherwise indicated by the
method definition or explicit cache controls (see
[Section 4.2.2 of RFC7234][3]).
Note: The original proposal for the 300 status code defined the URI header field
as providing a list of alternative representations, such that it would be usable
for 200, 300, and 406 responses and be transferred in responses to the HEAD
method. However, lack of deployment and disagreement over syntax led to both URI
and Alternates (a subsequent proposal) being dropped from this specification. It
is possible to communicate the list using a set of Link header fields
[[RFC5988][4]], each with a relationship of "alternate", though deployment is a
chicken-and-egg problem.
Source: [RFC7231 Section 6.4.1][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.4.1>
[2]: <http://tools.ietf.org/html/rfc7231#section-3.4>
[3]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
[4]: <http://tools.ietf.org/html/rfc5988>

33
contents/codes/301.md Normal file
View File

@ -0,0 +1,33 @@
---
set: 3
code: 301
title: Moved Permanently
references:
"Rails HTTP Status Symbol": ":moved_permanently"
---
The 301 Moved Permanently status code indicates that the target resource has
been assigned a new permanent URI and any future references to this resource
ought to use one of the enclosed URIs.
Clients with link-editing capabilities ought to automatically re-link references
to the effective request URI to one or more of the new references sent by the
server, where possible.
The server SHOULD generate a Location header field in the response containing a
preferred URI reference for the new permanent URI. The user agent MAY use the
Location field value for automatic redirection. The server's response payload
usually contains a short hypertext note with a hyperlink to the new URI(s).
Note: For historical reasons, a user agent MAY change the request method from
POST to GET for the subsequent request. If this behavior is undesired, the
[307 (Temporary Redirect)](/307) status code can be used instead.
A 301 response is cacheable by default; i.e., unless otherwise indicated by the
method definition or explicit cache controls
(see [Section 4.2.2 of [RFC7234]][2]).
Source: [RFC7231 Section 6.4.2][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.4.2>
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

25
contents/codes/302.md Normal file
View File

@ -0,0 +1,25 @@
---
set: 3
code: 302
title: Found
references:
"Rails HTTP Status Symbol": ":found"
---
The 302 Found status code indicates that the target resource resides temporarily
under a different URI. Since the redirection might be altered on
occasion, the client ought to continue to use the effective request URI for
future requests.
The server SHOULD generate a Location header field in the response containing a
URI reference for the different URI. The user agent MAY use the Location field
value for automatic redirection. The server's response payload usually contains
a short hypertext note with a hyperlink to the different URI(s).
Note: For historical reasons, a user agent MAY change the request method from
POST to GET for the subsequent request. If this behavior is undesired, the
[307 (Temporary Redirect)](/307) status code can be used instead.
Source: [RFC7231 Section 6.4.3][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.4.3>

41
contents/codes/303.md Normal file
View File

@ -0,0 +1,41 @@
---
set: 3
code: 303
title: See Other
references:
"Rails HTTP Status Symbol": ":see_other"
---
The 303 See Other status code indicates that the server is redirecting the
user agent to a different resource, as indicated by a URI in the Location header
field, which is intended to provide an indirect response to the original
request.
A user agent can perform a retrieval request targeting that URI (a GET
or HEAD request if using HTTP), which might also be redirected, and present the
eventual result as an answer to the original request. Note that the new URI in
the Location header field is not considered equivalent to the effective request
URI.
This status code is applicable to any HTTP method. It is primarily used to allow
the output of a POST action to redirect the user agent to a selected resource,
since doing so provides the information corresponding to the POST response in a
form that can be separately identified, bookmarked, and cached, independent of
the original request.
A 303 response to a GET request indicates that the origin server does not have a
representation of the target resource that can be transferred by the server over
HTTP. However, the Location field value refers to a resource that is descriptive
of the target resource, such that making a retrieval request on that other
resource might result in a representation that is useful to recipients without
implying that it represents the original target resource. Note that answers to
the questions of what can be represented, what representations are adequate, and
what might be a useful description are outside the scope of HTTP.
Except for responses to a HEAD request, the representation of a 303 response
ought to contain a short hypertext note with a hyperlink to the same URI
reference provided in the Location header field.
Source: [RFC7321 Section 6.4.4][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.4.4>

41
contents/codes/304.md Normal file
View File

@ -0,0 +1,41 @@
---
set: 3
code: 304
title: Not Modified
references:
"Rails HTTP Status Symbol": ":not_modified"
---
The 304 Not Modified status code indicates that a conditional GET or HEAD
request has been received and would have resulted in a [200 (OK)](/200) response
if it were not for the fact that the condition evaluated to false.
In other words, there is no need for the server to transfer a representation of
the target resource because the request indicates that the client, which made
the request conditional, already has a valid representation; the server is
therefore redirecting the client to make use of that stored representation as if
it were the payload of a [200 (OK)](/200) response.
The server generating a 304 response MUST generate any of the following header
fields that would have been sent in a [200 (OK)](/200) response to the same
request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.
Since the goal of a 304 response is to minimize information transfer when the
recipient already has one or more cached representations, a sender SHOULD NOT
generate representation metadata other than the above listed fields unless said
metadata exists for the purpose of guiding cache updates (e.g., Last-Modified
might be useful if the response does not have an ETag field).
Requirements on a cache that receives a 304 response are defined in
[Section 4.3.4 of RFC7234][2]. If the conditional request originated with an
outbound client, such as a user agent with its own cache sending a conditional
GET to a shared proxy, then the proxy SHOULD forward the 304 response to that
client.
A 304 response cannot contain a message-body; it is always terminated by the
first empty line after the header fields.
Source: [RFC7232 Section 4.1][1]
[1]: <http://tools.ietf.org/html/rfc7232#section-4.1>
[2]: <http://tools.ietf.org/html/rfc7234#section-4.3.4>

16
contents/codes/305.md Normal file
View File

@ -0,0 +1,16 @@
---
set: 3
code: 305
title: Use Proxy
#references:
# "Rails HTTP Status Symbol": "use_proxy"
# - Due to deprecation we won't show this... but should we?
---
The 305 Use Proxy status code was defined in a previous version of this
specification and is now deprecated, due to security concerns regarding in-band
configuration of a proxy.
Source: [RFC7231 Section 6.4.5][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.4.5>

29
contents/codes/307.md Normal file
View File

@ -0,0 +1,29 @@
---
set: 3
code: 307
title: Temporary Redirect
references:
"Rails HTTP Status Symbol": ":temporary_redirect"
---
The 307 Temporary Redirect status code indicates that the target resource
resides temporarily under a different URI and the user agent MUST NOT change the
request method if it performs an automatic redirection to that URI.
Since the redirection can change over time, the client ought to continue using
the original effective request URI for future requests.
The server SHOULD generate a Location header field in the response containing a
URI reference for the different URI. The user agent MAY use the Location field
value for automatic redirection. The server's response payload usually contains
a short hypertext note with a hyperlink to the different URI(s).
Note: This status code is similar to 302 (Found), except that it does not allow
changing the request method from POST to GET. This specification defines no
equivalent counterpart for [301 (Moved Permanently)](/301) ([RFC7238][2], however,
defines the status code [308 (Permanent Redirect)](/308) for this purpose).
Source: [RFC7231 Section 6.4.7][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.4.7>
[2]: <http://tools.ietf.org/html/rfc7238>

34
contents/codes/308.md Normal file
View File

@ -0,0 +1,34 @@
---
set: 3
code: 308
title: Permanent Redirect
---
The 308 Permanent Redirect status code indicates that the target resource has
been assigned a new permanent URI and any future references to this resource
ought to use one of the enclosed URIs.
Clients with link editing capabilities ought to automatically re-link references
to the effective request URI ([Section 5.5 of RFC7230][2]) to one or more of the
new references sent by the server, where possible.
The server SHOULD generate a Location header field
([[RFC7231], Section 7.1.2][3]) in the response containing a preferred URI
reference for the new permanent URI. The user agent MAY use the Location field
value for automatic redirection. The server's response payload usually contains
a short hypertext note with a hyperlink to the new URI(s).
A 308 response is cacheable by default; i.e., unless otherwise indicated by the
method definition or explicit cache controls ([see RFC7234, Section 4.2.2][4]).
Note: This status code is similar to 301 (Moved Permanently)
([RFC7231, Section 6.4.2][5]), except that it does not allow changing the
request method from POST to GET.
Source: [RFC738 Section 3][1]
[1]: <http://tools.ietf.org/html/rfc7538#section-3>
[2]: <http://tools.ietf.org/html/rfc7230#section-5.5>
[3]: <http://tools.ietf.org/html/rfc7231#section-7.1.2>
[4]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
[5]: <http://tools.ietf.org/html/rfc7231#section-6.4.2>

16
contents/codes/400.md Normal file
View File

@ -0,0 +1,16 @@
---
set: 4
code: 400
title: Bad Request
references:
"Rails HTTP Status Symbol": "bad_request"
---
The 400 Bad Request status code indicates that the server cannot or will not
process the request due to something that is perceived to be a client error
(e.g., malformed request syntax, invalid request message framing, or deceptive
request routing).
Source: [RFC7231 Section 6.5.1][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.1>

29
contents/codes/401.md Normal file
View File

@ -0,0 +1,29 @@
---
set: 4
code: 401
title: Unauthorized
references:
"Rails HTTP Status Symbol": ":unauthorized"
---
The 401 Unauthorized status code indicates that the request has not been
applied because it lacks valid authentication credentials for the target
resource.
The server generating a 401 response MUST send a WWW-Authenticate header field
([RFC7235 Section 4.1][2]) containing at least one challenge applicable to the
target resource.
If the request included authentication credentials, then the 401 response
indicates that authorization has been refused for those credentials. The user
agent MAY repeat the request with a new or replaced Authorization header field
([RFC7235 Section 4.2][3]). If the 401 response contains the same challenge as
the prior response, and the user agent has already attempted authentication at
least once, then the user agent SHOULD present the enclosed representation to
the user, since it usually contains relevant diagnostic information.
Source: [RFC7235 Section 3.1][1]
[1]: <http://tools.ietf.org/html/rfc7235#section-3.1>
[2]: <http://tools.ietf.org/html/rfc7235#section-4.1>
[3]: <http://tools.ietf.org/html/rfc7235#section-4.2>

13
contents/codes/402.md Normal file
View File

@ -0,0 +1,13 @@
---
set: 4
code: 402
title: Payment Required
references:
"Rails HTTP Status Symbol": ":payment_required"
---
The 402 (Payment Required) status code is reserved for future use.
Source: [RFC7231 Section 6.5.2][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.2>

25
contents/codes/403.md Normal file
View File

@ -0,0 +1,25 @@
---
set: 4
code: 403
title: Forbidden
references:
"Rails HTTP Status Symbol": ":forbidden"
---
The 403 Forbidden status code indicates that the server understood the request
but refuses to authorize it. A server that wishes to make public why the request
has been forbidden can describe that reason in the response payload (if any).
If authentication credentials were provided in the request, the server considers
them insufficient to grant access. The client SHOULD NOT automatically repeat
the request with the same credentials. The client MAY repeat the request with
new or different credentials. However, a request might be forbidden for reasons
unrelated to the credentials.
An origin server that wishes to "hide" the current existence of a forbidden
target resource MAY instead respond with a status code of
[404 (Not Found)](/404).
Source: [RFC7231 Section 6.5.3][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.3>

25
contents/codes/404.md Normal file
View File

@ -0,0 +1,25 @@
---
set: 4
code: 404
title: Not Found
references:
"Rails HTTP Status Symbol": ":not_found"
---
The 404 Not Found status code indicates that the origin server did not find a
current representation for the target resource or is not willing to disclose
that one exists.
A 404 status code does not indicate whether this lack of representation is
temporary or permanent; the [410 (Gone)](/410) status code is preferred over 404
if the origin server knows, presumably through some configurable means, that the
condition is likely to be permanent.
A 404 response is cacheable by default; i.e., unless otherwise indicated by the
method definition or explicit cache controls
(see [Section 4.2.2 of RFC7234][2]).
Source: [RFC7231 6.5.4][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.4>
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

22
contents/codes/405.md Normal file
View File

@ -0,0 +1,22 @@
---
set: 4
code: 405
title: Method Not Allowed
references:
"Rails HTTP Status Symbol": ":method_not_allowed"
---
The 405 Method Not Allowed status code indicates that the method received in
the request-line is known by the origin server but not supported by the target
resource.
The origin server MUST generate an Allow header field in a 405 response
containing a list of the target resource's currently supported methods.
A 405 response is cacheable by default; i.e., unless otherwise indicated by the
method definition or explicit cache controls (see [Section 4.2.2 of RFC7234][2]).
Source: [RFC7231 Section 6.5.5][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.5>
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

26
contents/codes/406.md Normal file
View File

@ -0,0 +1,26 @@
---
set: 4
code: 406
title: Not Acceptable
references:
"Rails HTTP Status Symbol": ":not_acceptable"
---
The 406 Not Acceptable status code indicates that the target resource does not
have a current representation that would be acceptable to the user agent,
according to the proactive negotiation header fields received in the request
([RFC7231 Section 5.3][2]), and the server is unwilling to supply a default
representation.
The server SHOULD generate a payload containing a list of available
representation characteristics and corresponding resource identifiers from which
the user or user agent can choose the one most appropriate. A user agent MAY
automatically select the most appropriate choice from that list. However, this
specification does not define any standard for such automatic selection, as
described in [RFC7231 Section 6.4.1][3].
Source: [RFC7231 Section 6.5.6][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.6>
[2]: <http://tools.ietf.org/html/rfc7231#section-5.3>
[3]: <http://tools.ietf.org/html/rfc7231#section-6.4.1>

22
contents/codes/407.md Normal file
View File

@ -0,0 +1,22 @@
---
set: 4
code: 407
title: Proxy Authentication Required
references:
"Rails HTTP Status Symbol": ":proxy_authentication_required"
---
The 407 Proxy Authentication Required status code is similar to
[401 (Unauthorized)](/401), but it indicates that the client needs to
authenticate itself in order to use a proxy.
The proxy MUST send a Proxy-Authenticate header field ([Section 4.3][2])
containing a challenge applicable to that proxy for the target resource.
The client MAY repeat the request with a new or replaced Proxy-Authorization
header field ([Section 4.4][3]).
Source: [RFC7235 Section 3.2][1]
[1]: <http://tools.ietf.org/html/rfc7235#section-3.2>
[2]: <http://tools.ietf.org/html/rfc7235#section-4.3>
[3]: <http://tools.ietf.org/html/rfc7235#section-4.4>

20
contents/codes/408.md Normal file
View File

@ -0,0 +1,20 @@
---
set: 4
code: 408
title: Request Timeout
references:
"Rails HTTP Status Symbol": ":request_timeout"
---
The 408 Request Timeout status code indicates that the server did not receive
a complete request message within the time that it was prepared to wait.
A server SHOULD send the "close" connection option ([Section 6.1 of RFC7230][2])
in the response, since 408 implies that the server has decided to close the
connection rather than continue waiting. If the client has an outstanding
request in transit, the client MAY repeat that request on a new connection.
Source: [RFC7231 Section 6.5.7][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.7>
[2]: <http://tools.ietf.org/html/rfc7230#section-6.1>

26
contents/codes/409.md Normal file
View File

@ -0,0 +1,26 @@
---
set: 4
code: 409
title: Conflict
references:
"Rails HTTP Status Symbol": ":conflict"
---
The 409 Conflict status code indicates that the request could not be completed
due to a conflict with the current state of the target resource. This code is
used in situations where the user might be able to resolve the conflict and
resubmit the request.
The server SHOULD generate a payload that includes enough information for a user
to recognize the source of the conflict.
Conflicts are most likely to occur in response to a PUT request. For example, if
versioning were being used and the representation being PUT included changes to
a resource that conflict with those made by an earlier (third-party) request,
the origin server might use a 409 response to indicate that it can't complete
the request. In this case, the response representation would likely contain
information useful for merging the differences based on the revision history.
Source: [RFC7231 Section 6.5.8][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.8>

33
contents/codes/410.md Normal file
View File

@ -0,0 +1,33 @@
---
set: 4
code: 410
title: Gone
references:
"Rails HTTP Status Symbol": ":gone"
---
The 410 Gone status code indicates that access to the target resource is no
longer available at the origin server and that this condition is likely to be
permanent.
If the origin server does not know, or has no facility to determine, whether or
not the condition is permanent, the status code [404 (Not Found)](/404) ought to
be used instead.
The 410 response is primarily intended to assist the task of web maintenance by
notifying the recipient that the resource is intentionally unavailable and that
the server owners desire that remote links to that resource be removed. Such an
event is common for limited-time, promotional services and for resources
belonging to individuals no longer associated with the origin server's site. It
is not necessary to mark all permanently unavailable resources as "gone" or to
keep the mark for any length of time -- that is left to the discretion of the
server owner.
A 410 response is cacheable by default; i.e., unless otherwise indicated by the
method definition or explicit cache controls
(see [Section 4.2.2 of RFC7234][2]).
Source: [RFC7231 Section 6.5.9][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.9>
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

19
contents/codes/411.md Normal file
View File

@ -0,0 +1,19 @@
---
set: 4
code: 411
title: Length Required
references:
"Rails HTTP Status Symbol": ":length_required"
---
The 411 Length Required status code indicates that the server refuses to
accept the request without a defined Content-Length
([Section 3.3.2 of RFC7230][2]).
The client MAY repeat the request if it adds a valid Content-Length header field
containing the length of the message body in the request message.
Source: [RFC7231 Section 6.5.10][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.10>
[2]: <http://tools.ietf.org/html/rfc7230#section-3.3.2>

19
contents/codes/412.md Normal file
View File

@ -0,0 +1,19 @@
---
set: 4
code: 412
title: Precondition Failed
references:
"Rails HTTP Status Symbol": ":precondition_failed"
---
The 412 Precondition Failed status code indicates that one or more conditions
given in the request header fields evaluated to false when tested on the server.
This response code allows the client to place preconditions on the current
resource state (its current representations and metadata) and, thus, prevent the
request method from being applied if the target resource is in an unexpected
state.
Source: [RFC7232 Section 4.2][1]
[1]: <http://tools.ietf.org/html/rfc7232#section-4.2>

22
contents/codes/413.md Normal file
View File

@ -0,0 +1,22 @@
---
set: 4
code: 413
title: Payload Too Large
references:
"Rails HTTP Status Symbol": ":request_entity_too_large"
---
The 413 Payload Too Large status code indicates that the server is refusing
to process a request because the request payload is larger than the server is
willing or able to process.
The server MAY close the connection to prevent the
client from continuing the request.
If the condition is temporary, the server SHOULD generate a Retry-After header
field to indicate that it is temporary and after what time the client MAY try
again.
Source: [RFC7231 Section 6.5.11][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.11>

27
contents/codes/414.md Normal file
View File

@ -0,0 +1,27 @@
---
set: 4
code: 414
title: Request-URI Too Long
references:
"Rails HTTP Status Symbol": ":request_uri_too_long"
---
The 414 URI Too Long status code indicates that the server is refusing to
service the request because the request-target ([Section 5.3 of RFC7230][2]) is
longer than the server is willing to interpret.
This rare condition is only likely to occur when a client has improperly
converted a POST request to a GET request with long query information, when the
client has descended into a "black hole" of redirection (e.g., a redirected URI
prefix that points to a suffix of itself) or when the server is under attack by
a client attempting to exploit potential security holes.
A 414 response is cacheable by default; i.e., unless otherwise indicated by the
method definition or explicit cache controls
(see [Section 4.2.2 of RFC7234][3]).
Source: [RFC7231 Section 6.5.12][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.12>
[2]: <http://tools.ietf.org/html/rfc7231#section-5.3>
[3]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

18
contents/codes/415.md Normal file
View File

@ -0,0 +1,18 @@
---
set: 4
code: 415
title: Unsupported Media Type
references:
"Rails HTTP Status Symbol": ":unsupported_media_type"
---
The 415 Unsupported Media Type status code indicates that the origin server is
refusing to service the request because the payload is in a format not supported
by this method on the target resource.
The format problem might be due to the request's indicated Content-Type or
Content-Encoding, or as a result of inspecting the data directly.
Source: [RFC7231 Section 6.5.13][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.13>

42
contents/codes/416.md Normal file
View File

@ -0,0 +1,42 @@
---
set: 4
code: 416
title: Requested Range Not Satisfiable
references:
"Rails HTTP Status Symbol": ":requested_range_not_satisfiable"
---
The 416 Range Not Satisfiable status code indicates that none of the ranges in
the request's Range header field ([RFC7233 Section 3.1][2]) overlap the current
extent of the selected resource or that the set of ranges requested has been
rejected due to invalid ranges or an excessive request of small or overlapping
ranges.
For byte ranges, failing to overlap the current extent means that the
first-byte-pos of all of the byte-range-spec values were greater than the
current length of the selected representation. When this status code is
generated in response to a byte-range request, the sender SHOULD generate a
Content-Range header field specifying the current length of the selected
representation ([RFC7233 Section 4.2][3]).
For example:
```
HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022
```
Note: Because servers are free to ignore Range, many implementations will simply
respond with the entire selected representation in a [200 (OK)](/200) response.
That is partly because most clients are prepared to receive a [200 (OK)](/200)
to complete the task (albeit less efficiently) and partly because clients might
not stop making an invalid partial request until they have received a complete
representation. Thus, clients cannot depend on receiving a
416 (Range Not Satisfiable) response even when it is most appropriate.
Source: [RFC7233 Section 4.4][1]
[1]: <http://tools.ietf.org/html/rfc7233#section-4.4>
[2]: <http://tools.ietf.org/html/rfc7233#section-3.1>
[3]: <http://tools.ietf.org/html/rfc7233#section-4.2>

16
contents/codes/417.md Normal file
View File

@ -0,0 +1,16 @@
---
set: 4
code: 417
title: Expectation Failed
references:
"Rails HTTP Status Symbol": ":expectation_failed"
---
The 417 Expectation Failed status code indicates that the expectation given in
the request's Expect header field ([RFC7231 Section 5.1.1][2]) could not be met
by at least one of the inbound servers.
Source: [RFC7231 Section 6.5.14][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.14>
[2]: <http://tools.ietf.org/html/rfc7231#section-5.1.1>

14
contents/codes/418.md Normal file
View File

@ -0,0 +1,14 @@
---
set: 4
code: 418
title: I'm a teapot
references:
"Rails HTTP Status Symbol": ":i'm_a_teapot"
---
Any attempt to brew coffee with a teapot should result in the error code
"418 I'm a teapot". The resulting entity body MAY be short and stout.
Source: [RFC2324 Section 2.3.2][1]
[1]: <https://tools.ietf.org/html/rfc2324#section-2.3.2>

31
contents/codes/421.md Normal file
View File

@ -0,0 +1,31 @@
---
set: 4
code: 421
title: Misdirected Request
references:
"Rails HTTP Status Symbol": ":misdirected_request"
---
The 421 Misdirected Request status code indicates that the request was
directed at a server that is not able to produce a response. This can be sent by
a server that is not configured to produce responses for the combination of
scheme and authority that are included in the request URI.
Clients receiving a 421 (Misdirected Request) response from a server MAY retry
the request -- whether the request method is idempotent or not -- over a
different connection. This is possible if a connection is reused
([RFC7540 Section 9.1.1][2]) or if an alternative service is selected
[ALT-SVC][3].
This status code MUST NOT be generated by proxies.
A 421 response is cacheable by default, i.e., unless otherwise indicated by the
method definition or explicit cache controls
(see [Section 4.2.2 of RFC7234][4]).
Source: [RFC7540 Section 9.1.2][1]
[1]: <http://tools.ietf.org/html/rfc7540#section-9.1.2>
[2]: <http://tools.ietf.org/html/rfc7540#section-9.1.1>
[3]: <http://tools.ietf.org/html/rfc7540#ref-ALT-SVC>
[4]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

21
contents/codes/422.md Normal file
View File

@ -0,0 +1,21 @@
---
set: 4
code: 422
title: Unprocessable Entity
references:
"Rails HTTP Status Symbol": ":unprocessable_entity"
---
The 422 Unprocessable Entity status code means the server understands the
content type of the request entity (hence a [415 (Unsupported Media Type)](/415)
status code is inappropriate), and the syntax of the request entity is correct
(thus a [400 (Bad Request)](/400) status code is inappropriate) but was unable
to process the contained instructions.
For example, this error condition may occur if an XML request body contains
well-formed (i.e., syntactically correct), but semantically erroneous, XML
instructions.
Source: [RFC4918 Section 11.2][1]
[1]: <http://tools.ietf.org/html/rfc4918#section-11.2>

17
contents/codes/423.md Normal file
View File

@ -0,0 +1,17 @@
---
set: 4
code: 423
title: Locked
references:
"Rails HTTP Status Symbol": ":locked"
---
The 423 Locked status code means the source or destination resource of a
method is locked.
This response SHOULD contain an appropriate precondition or
postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.
Source: [RFC4918 Section 11.3][1]
[1]: <http://tools.ietf.org/html/rfc4918#section-11.3>

18
contents/codes/424.md Normal file
View File

@ -0,0 +1,18 @@
---
set: 4
code: 424
title: Failed Dependency
references:
"Rails HTTP Status Symbol": "failed_dependency"
---
The 424 Failed Dependency status code means that the method could not be
performed on the resource because the requested action depended on another
action and that action failed.
For example, if a command in a PROPPATCH method fails, then, at minimum, the
rest of the commands will also fail with 424 Failed Dependency.
Source: [RFC4918 Section 11.4][1]
[1]: <http://tools.ietf.org/html/rfc4918#section-11.4>

31
contents/codes/426.md Normal file
View File

@ -0,0 +1,31 @@
---
set: 4
code: 426
title: Upgrade Required
references:
"Rails HTTP Status Symbol": ":upgrade_required"
---
The 426 Upgrade Required status code indicates that the server refuses to
perform the request using the current protocol but might be willing to do so
after the client upgrades to a different protocol.
The server MUST send an Upgrade header field in a 426 response to indicate the
required protocol(s) (Section 6.7 of RFC7230][2]).
Example:
```
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain
This service requires use of the HTTP/3.0 protocol.
```
Source: [RFC7231 Section 6.5.15][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.15>
[2]: <http://tools.ietf.org/html/rfc7230#section-6.7>

36
contents/codes/428.md Normal file
View File

@ -0,0 +1,36 @@
---
set: 4
code: 428
title: Precondition Required
---
The 428 status code indicates that the origin server requires the request to be
conditional.
Its typical use is to avoid the "lost update" problem, where a client GETs a
resource's state, modifies it, and PUTs it back to the server, when meanwhile a
third party has modified the state on the server, leading to a conflict. By
requiring requests to be conditional, the server can assure that clients are
working with the correct copies.
Responses using this status code SHOULD explain how to resubmit the request
successfully. For example:
```
HTTP/1.1 428 Precondition Required
Content-Type: text/html
<html>
<head>
<title>Precondition Required</title>
</head>
<body>
<h1>Precondition Required</h1>
<p>This request is required to be conditional; try using "If-Match".</p>
</body>
</html>
```
Responses with the 428 status code MUST NOT be stored by a cache.
[1]: <http://tools.ietf.org/html/rfc6585#section-3>

43
contents/codes/429.md Normal file
View File

@ -0,0 +1,43 @@
---
set: 4
code: 429
title: Too Many Requests
---
The 429 status code indicates that the user has sent too many requests in a
given amount of time ("rate limiting").
The response representations SHOULD include details explaining the condition,
and MAY include a Retry-After header indicating how long to wait before making a
new request.
For example:
```
HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600
<html>
<head>
<title>Too Many Requests</title>
</head>
<body>
<h1>Too Many Requests</h1>
<p>I only allow 50 requests per hour to this Web site per
logged in user. Try again soon.</p>
</body>
</html>
```
Note that this specification does not define how the origin server identifies
the user, nor how it counts requests. For example, an origin server that is
limiting request rates can do so based upon counts of requests on a per-resource
basis, across the entire server, or even among a set of servers. Likewise, it
might identify the user by its authentication credentials, or a stateful cookie.
Responses with the 429 status code MUST NOT be stored by a cache.
Source: [RFC6585 Section 4][1]
[1]: <http://tools.ietf.org/html/rfc6585#section-4>

36
contents/codes/431.md Normal file
View File

@ -0,0 +1,36 @@
---
set: 4
code: 431
title: Request Header Fields Too Large
---
The 431 status code indicates that the server is unwilling to process the
request because its header fields are too large. The request MAY be resubmitted
after reducing the size of the request header fields.
It can be used both when the set of request header fields in total is too large,
and when a single header field is at fault. In the latter case, the response
representation SHOULD specify which header field was too large.
For example:
```
HTTP/1.1 431 Request Header Fields Too Large
Content-Type: text/html
<html>
<head>
<title>Request Header Fields Too Large</title>
</head>
<body>
<h1>Request Header Fields Too Large</h1>
<p>The "Example" header was too large.</p>
</body>
</html>
```
Responses with the 431 status code MUST NOT be stored by a cache.
Source: [RFC6585 Section 5][1]
[1]: <http://tools.ietf.org/html/rfc6585#section-5>

16
contents/codes/499.md Normal file
View File

@ -0,0 +1,16 @@
---
# This is not a status code available in the standard, but it exists
# with significant prominence in the wild
set: 4
code: 499
title: Client Closed Request
---
The 499 Client Closed Request status is a non-standard status code introduced by
[nginx][2] for the case when a client closes the connection while nginx is
processing the request.
Source: [nginx][1]
[1]: <http://lxr.nginx.org/source/src/http/ngx_http_request.h#0120>
[2]: <http://nginx.org>

15
contents/codes/500.md Normal file
View File

@ -0,0 +1,15 @@
---
set: 5
code: 500
title: Internal Server Error
references:
"Rails HTTP Status Symbol": ":internal_server_error"
---
The 500 Internal Server Error status code indicates that the server
encountered an unexpected condition that prevented it from fulfilling the
request.
Source: [RFC7231 Section 6.6.1][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.6.1>

22
contents/codes/501.md Normal file
View File

@ -0,0 +1,22 @@
---
set: 5
code: 501
title: Not Implemented
references:
"Rails HTTP Status Symbol": ":not_implemented"
---
The 501 Not Implemented status code indicates that the server does not support
the functionality required to fulfill the request.
This is the appropriate response when the server does not recognize the request
method and is not capable of supporting it for any resource.
A 501 response is cacheable by default; i.e., unless otherwise indicated by the
method definition or explicit cache controls
(see [Section 4.2.2 of RFC7234][1]).
Source: [RFC7231 Section 6.6.2][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.6.2>
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

15
contents/codes/502.md Normal file
View File

@ -0,0 +1,15 @@
---
set: 5
code: 502
title: Bad Gateway
references:
"Rails HTTP Status Symbol": ":bad_gateway"
---
The 502 Bad Gateway status code indicates that the server, while acting as a
gateway or proxy, received an invalid response from an inbound server it
accessed while attempting to fulfill the request.
Source: [RFC7231 Section 6.6.3][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.6.3>

24
contents/codes/503.md Normal file
View File

@ -0,0 +1,24 @@
---
set: 5
code: 503
title: Service Unavailable
references:
"Rails HTTP Status Symbol": ":service_unavailable"
---
The 503 Service Unavailable status code indicates that the server is currently
unable to handle the request due to a temporary overload or scheduled
maintenance, which will likely be alleviated after some delay.
The server MAY send a Retry-After header field ([RFC7231 Section 7.1.3][2]) to
suggest an appropriate amount of time for the client to wait before retrying the
request.
Note: The existence of the 503 status code does not imply that a server has to
use it when becoming overloaded. Some servers might simply refuse the
connection.
Source: [RFC7231 Section 6.6.4][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.6.4>
[2]: <http://tools.ietf.org/html/rfc7231#section-7.1.3>

15
contents/codes/504.md Normal file
View File

@ -0,0 +1,15 @@
---
set: 5
code: 504
title: Gateway Timeout
references:
"Rails HTTP Status Symbol": ":gateway_timeout"
---
The 504 Gateway Timeout status code indicates that the server, while acting as
a gateway or proxy, did not receive a timely response from an upstream server it
needed to access in order to complete the request.
Source: [RFC7231 Section 6.6.5][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.6.5>

22
contents/codes/505.md Normal file
View File

@ -0,0 +1,22 @@
---
set: 5
code: 505
title: HTTP Version Not Supported
references:
"Rails HTTP Status Symbol": ":http_version_not_supported"
---
The 505 HTTP Version Not Supported status code indicates that the server does
not support, or refuses to support, the major version of HTTP that was used in
the request message.
The server is indicating that it is unable or unwilling to complete the request
using the same major version as the client, as described in
[Section 2.6 of RFC7230][2], other than with this error message. The server
SHOULD generate a representation for the 505 response that describes why that
version is not supported and what other protocols are supported by that server.
Source: [RFC7231 Section 6.6.6][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.6.6>
[2]: <http://tools.ietf.org/html/rfc7230#section-2.6>

14
contents/codes/506.md Normal file
View File

@ -0,0 +1,14 @@
---
set: 5
code: 506
title: Variant Also Negotiates
---
The 506 status code indicates that the server has an internal configuration
error: the chosen variant resource is configured to engage in transparent
content negotiation itself, and is therefore not a proper end point in the
negotiation process.
Source: [RFC2295 Section 8.1][1]
[1]: <http://tools.ietf.org/html/rfc2295#section-8.1>

17
contents/codes/507.md Normal file
View File

@ -0,0 +1,17 @@
---
set: 5
code: 507
title: Insufficient Storage
references:
"Rails HTTP Status Symbol": ":insufficient_storage"
---
The 507 Insufficient Storage status code means the method could not be
performed on the resource because the server is unable to store the
representation needed to successfully complete the request.
This condition is considered to be temporary. If the request that received this
status code was the result of a user action, the request MUST NOT be repeated
until it is requested by a separate user action.
[1]: <http://tools.ietf.org/html/rfc4918#section-11.5>

13
contents/codes/508.md Normal file
View File

@ -0,0 +1,13 @@
---
set: 5
code: 508
title: Loop Detected
---
The 508 Loop Detected status code indicates that the server terminated an
operation because it encountered an infinite loop while processing a request
with "Depth: infinity". This status indicates that the entire operation failed.
Source: [RFC5842 Section 7.2][1]
[1]: <http://tools.ietf.org/html/rfc5842#section-7.2>

25
contents/codes/510.md Normal file
View File

@ -0,0 +1,25 @@
---
set: 5
code: 510
title: Not Extended
references:
"Rails HTTP Status Symbol": ":not_extended"
---
The policy for accessing the resource has not been met in the request. The
server should send back all the information necessary for the client to issue an
extended request.
It is outside the scope of this specification to specify how
the extensions inform the client.
If the 510 response contains information about extensions that were not present
in the initial request then the client MAY repeat the request if it has reason
to believe it can fulfill the extension policy by modifying the request
according to the information provided in the 510 response. Otherwise the client
MAY present any entity included in the 510 response to the user, since that
entity may include relevant diagnostic information.
Source: [RFC2774 Section 7][1]
[1]: <http://tools.ietf.org/html/rfc2774#section-7>

72
contents/codes/511.md Normal file
View File

@ -0,0 +1,72 @@
---
set: 5
code: 511
title: Network Authentication Required
---
The 511 status code indicates that the client needs to authenticate to gain
network access.
The response representation SHOULD contain a link to a resource that allows the
user to submit credentials (e.g., with an HTML form).
Note that the 511 response SHOULD NOT contain a challenge or the login interface
itself, because browsers would show the login interface as being associated with
the originally requested URL, which may cause confusion.
The 511 status SHOULD NOT be generated by origin servers; it is intended for use
by intercepting proxies that are interposed as a means of controlling access to
the network.
Responses with the 511 status code MUST NOT be stored by a cache.
The 511 status code is designed to mitigate problems caused by "captive portals"
to software (especially non-browser agents) that is expecting a response from
the server that a request was made to, not the intervening network infrastructure.
It is not intended to encourage deployment of captive portals -- only to limit
the damage caused by them.
A network operator wishing to require some authentication, acceptance of terms,
or other user interaction before granting access usually does so by identifying
clients who have not done so ("unknown clients") using their Media Access
Control (MAC) addresses.
Unknown clients then have all traffic blocked, except for that on TCP port 80,
which is sent to an HTTP server (the "login server") dedicated to "logging in"
unknown clients, and of course traffic to the login server itself.
For example, a user agent might connect to a network and make the following HTTP
request on TCP port 80:
```
GET /index.htm HTTP/1.1
Host: www.example.com
```
Upon receiving such a request, the login server would generate a 511 response:
```
HTTP/1.1 511 Network Authentication Required
Content-Type: text/html
<html>
<head>
<title>Network Authentication Required</title>
<meta http-equiv="refresh"
content="0; url=https://login.example.net/">
</head>
<body>
<p>You need to <a href="https://login.example.net/">
authenticate with the local network</a> in order to gain
access.</p>
</body>
</html>
```
Here, the 511 status code assures that non-browser clients will not interpret
the response as being from the origin server, and the META HTML element
redirects the user agent to the login server.
Source: [RFC6585 Section 6][1]
[1]: <http://tools.ietf.org/html/rfc6585#section-6>

15
contents/codes/599.md Normal file
View File

@ -0,0 +1,15 @@
---
# This is not a status code available in the standard, but it exists
# with significant prominence in the wild
set: 5
code: 599
title: Network Connect Timeout Error
---
This status code is not specified in any RFCs, but is used by some HTTP proxies
to signal a network connect timeout behind the proxy to a client in front of the
proxy.
Source: [unknown?][1]
[1]: <https://github.com/citricsquid/httpstatus.es/issues/22>

17
contents/codes/classes.json Normal file
View File

@ -0,0 +1,17 @@
{
"1": {
"title": "1&times;&times; Informational"
},
"2": {
"title": "2&times;&times; Success"
},
"3": {
"title": "3&times;&times; Redirection"
},
"4": {
"title": "4&times;&times; Client Error"
},
"5": {
"title": "5&times;&times; Server Error"
}
}

15
contents/error-404.md Normal file
View File

@ -0,0 +1,15 @@
---
title: Page Not Found
layout: page.jade
---
# 404 Page Note Found
This isn't a page to explain a status code, it's an actual 404.
The page you have requested can't be found. If you didn't expect to see
this error please
[create an issue via GitHub](https://github.com/citricsquid/httpstatus.es/issues).
If you want to learn more about what a 404 is, visit [/404](/404)!
[&larr; Return to httpstatus.es](/)

15
contents/error-500.md Normal file
View File

@ -0,0 +1,15 @@
---
title: Internal Server Error
layout: page.jade
---
# Internal Server Error
This isn't a page to explain a status code, it's an actual 500, an Internal Server
Error. The page you have requested couldn't be delivered for an unknown reason.
If you didn't expect to see this error please
[create an issue via GitHub](https://github.com/citricsquid/httpstatus.es/issues).
If you want to learn more about what a 500 is, visit [/500](/500)!
[&larr; Return to httpstatus.es](/)

0
assets/img/favicon.ico → contents/favicon.ico
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 411 B

After

Width:  |  Height:  |  Size: 411 B

14
contents/index.md Normal file
View File

@ -0,0 +1,14 @@
---
title: HTTP Status Codes
layout: index.jade
---
# HTTP Status Codes
httpstatus.es is an easy to reference database of HTTP Status Codes with their
definitions and helpful code references all in one place. Visit an individual
status code via `httpstatus.es/code` or browse the list below.
Hosting sponsored by [Runscope](https://www.runscope.com/t/httpstatuses),
source code available on
[GitHub](https://github.com/citricsquid/httpstatus.es).

2
robots.txt → contents/robots.txt
View File

@ -1,2 +1,2 @@
User-agent: *
Disallow:
Disallow:

121
contents/style.scss Normal file
View File

@ -0,0 +1,121 @@
$container-width: 528px;
@import "../bower_components/Skeleton-Sass/scss/skeleton.scss";
.container {
margin: auto;
max-width: $container-width;
}
@media (max-width: 400px) {
.container {
width: 80%;
}
}
body {
color: #556270;
font-family: 'Open Sans', sans-serif;
font-weight: normal;
margin: 0px;
}
a {
color: #d6156d;
font-weight: bold;
text-decoration: none;
}
a[href^='https://www.runscope.com'] {
color: #1b70e0;
font-weight: bold;
}
h1, h2, h3, h4, h5, h6 {
color: #333;
font-family: 'Montserrat', sans-serif;
font-size: 20px;
margin-bottom: 8px;
}
p {
font-size: 14px;
margin-bottom: 10px;
}
code {
background-color: #fff;
word-wrap: break-word;
}
.hero {
@extend .u-full-width;
padding: 25px 0px 10px 0px;
}
.codes {
margin-bottom: 40px;
ul {
font-family: 'Open Sans', sans-serif;
font-size: 14px;
letter-spacing: 0.5px;
list-style-type: none;
margin-bottom: 10px;
h2 {
font-family: 'Open Sans', sans-serif;
font-size: 14px;
font-weight: bold;
letter-spacing: 0.5px;
margin-bottom: 0px;
}
li {
margin-bottom: 0px;
a {
color: #556270;
font-weight: normal;
&:hover {
color: #d6156d;
}
span {
color: #d6156d;
font-family: 'Source Code Pro';
font-weight: bold;
width: 34px;
}
}
}
}
}
.code {
margin: 25px auto;
p:first-of-type {
font-size: 18px;
padding-bottom: 10px;
border-bottom: 2px solid #eee;
}
h1 {
font-family: 'Source Code Pro';
letter-spacing: 0.5px;
text-transform: uppercase;
span {
color: #d6156d;
}
}
h2 {
color: #bbb;
font-family: 'Source Code Pro';
letter-spacing: 0.5px;
text-transform: uppercase;
}
}

7
deploy.sh Executable file
View File

@ -0,0 +1,7 @@
build="build-${CIRCLE_BUILD_NUM}"
sudo mkdir ~/${build}
sudo cp -R ~/httpstatus.es/build/. ~/${build}
echo "Deploying ${build} to ${DEPLOY_TARGET}"
rsync -r -l ~/${build} ${DEPLOY_TARGET}:/srv/www/httpstatus.es
ssh ${DEPLOY_TARGET} "ln -sfn /srv/www/httpstatus.es/${build} /srv/www/httpstatus.es/live"
echo "Build deployed and pushed live"

13
humans.txt
View File

@ -1,13 +0,0 @@
/* TEAM */
Captain: Samuel Ryan
Site: sam@samryan.co.uk
Twitter: citricsquid
Location: Brighton, England
/* SITE */
Last update: 2013-03-19
Doctype: HTML5
Languages: PHP5
Frameworks: Klein.php
IDE: Netbeans
Repository: https://github.com/citricsquid/httpstatus.es

28
index.php
View File

@ -1,28 +0,0 @@
<?php
require 'vendor/autoload.php';
require 'lib/Httpstatuses/Httpstatuses.php';
$klein = new \Klein\Klein();
$httpstatuses = new \Httpstatuses\httpstatuses();
$klein->respond('GET', '/', function ($request, $response, $service) use ($httpstatuses) {
$class_list = $httpstatuses->statuses();
$service->render('views/index.php', array("class_list" => $class_list));
});
$klein->respond('GET', '/[i:id]', function ($request, $response, $service) use ($httpstatuses) {
$status_code = $request->param('id');
$code = $httpstatuses->status($status_code);
if (!$code)
$service->render('views/404.php');
$service->render('views/status_code.php', $code);
});
$klein->respond('GET', '404', function ($request, $response, $service) {
$service->render('views/404.php');
});
$klein->dispatch();

32
lib/Httpstatuses/Httpstatuses.php
View File

@ -1,32 +0,0 @@
<?php
namespace Httpstatuses;
class Httpstatuses
{
public function statuses($class = "*")
{
$class_files = glob("codes/$class.json");
foreach($class_files as $class_file)
{
$class = json_decode(file_get_contents($class_file), true);
$classes[$class["class"]["class"]] = $class;
}
return $classes;
}
public function status($code)
{
$class = substr($code, 0, 1);
$class_file = file_get_contents("codes/$class.json");
if(!$class_file)
return false;
$code_list = json_decode($class_file, true);
return isset($code_list["codes"][$code]) ? $code_list["codes"][$code] : false;
}
}

36
package.json Normal file
View File

@ -0,0 +1,36 @@
{
"name": "httpstatus.es",
"version": "0.1.0",
"description": "An easy to reference directory of HTTP Status Codes",
"main": "build.js",
"scripts": {
"start": "node build.js",
"test": "node build.js"
},
"repository": {
"type": "git",
"url": "git+https://github.com/citricsquid/httpstatus.es.git"
},
"author": "Samuel Ryan <sam@samryan.co.uk>",
"license": "MIT",
"bugs": {
"url": "https://github.com/citricsquid/httpstatus.es/issues"
},
"homepage": "https://github.com/citricsquid/httpstatus.es#readme",
"dependencies": {
"bower": "^1.6.5",
"jade": "^1.11.0",
"lodash.groupby": "^3.1.1",
"metalsmith": "^2.1.0",
"metalsmith-branch": "0.0.4",
"metalsmith-collection-grouping": "^0.1.0",
"metalsmith-collections": "^0.7.0",
"metalsmith-elevate": "0.0.0",
"metalsmith-fingerprint-ignore": "^1.1.2",
"metalsmith-ignore": "^0.1.2",
"metalsmith-layouts": "^1.4.2",
"metalsmith-markdown": "^0.2.1",
"metalsmith-sass": "^1.3.0",
"metalsmith-writemetadata": "^0.4.5"
}
}

16
templates/code.jade Normal file
View File

@ -0,0 +1,16 @@
extends layout.jade
block title
title !{code} !{title} &mdash; httpstatus.es
block contents
.code
article.container.code: .row: .twelve.columns
h2 !{groups.codes[set].title}
h1 #[span !{code}] !{title}
!= contents
if references
h1 #[span !{code}] Code References
each value, key in references
p !{key} #[code !{value}]
a(href='/') &larr; Return to httpstatus.es

11
templates/index.jade Normal file
View File

@ -0,0 +1,11 @@
extends layout.jade
block contents
.hero.introduction: .container: .row: .twelve.columns !{contents}
.container.codes: .row: .twelve.columns
each group in groups.codes
ul
h2 !{group.title}
each code in group.items
li #[a(href='/#{code.code}') #[span !{code.code}] #{code.title}]

18
templates/layout.jade Normal file
View File

@ -0,0 +1,18 @@
doctype html
html(lang="en")
head
block title
title #{title} &mdash; httpstatus.es
link(rel='shortcut icon', href='/' + fingerprint['favicon.ico'], type='image/x-icon')
link(rel='stylesheet', href='/' + fingerprint['style.css'])
link(rel='stylesheet', href='https://fonts.googleapis.com/css?family=Montserrat|Open+Sans|Source+Code+Pro:700', type='text/css')
meta(name='viewport', content='width=device-width, initial-scale=1.0')
body
block contents
script.
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q || []).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-29439846-1', 'auto');
ga('send', 'pageview');

4
templates/page.jade Normal file
View File

@ -0,0 +1,4 @@
extends layout.jade
block contents
.hero.introduction: .container: .row: .twelve.columns !{contents}

46
views/404.php
View File

@ -1,46 +0,0 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>404real &mdash; httpstatus.es</title>
<link rel="author" href="humans.txt" />
<link rel="stylesheet" href="assets/css/style.css" type="text/css" />
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-29439846-1']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
<meta name="description" content="HTTP Status code list / directory with wikipedia and ietf descriptions"/>
</head>
<body>
<div id="wrapper">
<div class="header">
404 / <span class="status_title">Page not found</span>
</div>
<div id="desc">
<p>
No really, this is a 404. The page can't be found! There's
no education here, just a barren wasteland.
</p>
<p>
If there should
be something here you can submit a new status code via the
<a href="https://github.com/citricsquid/httpstatus.es">
httpstatus.es repository
</a> on github.
</p>
</div>
<div id="return">
<a href="http://httpstatus.es">&larr; return</a>
</div>
</div>
</body>
</html>

75
views/index.php
View File

@ -1,75 +0,0 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>HTTP Status Codes &mdash; httpstatus.es</title>
<link rel="author" href="humans.txt" />
<link rel="stylesheet" href="assets/css/style.css" type="text/css" />
<link rel="shortcut icon" href="assets/img/favicon.ico">
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-29439846-1']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
<meta name="description" content="HTTP Status code list / directory with wikipedia and ietf descriptions"/>
</head>
<body>
<div id="advert">
<div class="ad">
Check out pure DNS domain redirects with <a href="http://cnamer.com">CNAMER</a>.
</div>
</div>
<div id="wrapper">
<div class="header">
httpstatus.es
<div class="share_buttons">
<div class="share_button" id="twitter">
<a href="https://twitter.com/share" class="twitter-share-button" data-via="citricsquid" data-url="http://httpstatus.es">Tweet</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>
</div>
<div class="share_button" id="facebook">
<iframe src="//www.facebook.com/plugins/like.php?href=http%3A%2F%2Fhttpstatus.es&amp;send=false&amp;layout=button_count&amp;width=250&amp;show_faces=false&amp;action=like&amp;colorscheme=light&amp;font=arial&amp;height=21" scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:80px; height:21px; text-align:right;" allowTransparency="true"></iframe>
</div>
</div>
<div class="clear"></div>
</div>
<div id="intro">
<p>
Database of HTTP status codes with their IETF + Wikipedia
descriptions and helpful code references.
Maintained by
<a href="http://twitter.com/citricsquid">@citricsquid</a>.
New codes and improvements can be commited via the
<a href="https://github.com/citricsquid/httpstatus.es">GitHub repository</a>.
</p>
</div>
<div id="statuses">
<?php foreach($this->class_list as $id => $class) { ?>
<div class="status_list" id="<?php echo $id; ?>">
<div class="head">
<div class="title"><?php echo $id; ?>xx <?php echo $class["class"]["title"]; ?></div>
<div class="clear"></div>
</div>
<div class="statuses">
<?php foreach($class["codes"] as $code => $info) { ?>
<div class="status">
<div class="st"><a title="<?php echo $info["title"]; ?>" href="/<?php echo $code; ?>"><?php echo $code; ?></a></div>
<div class="description"><?php echo $info["summary"]; ?></div>
</div>
<?php } ?>
<div class="clear"></div>
</div>
</div>
<?php } ?>
</div>
</div>
</body>
</html>

62
views/status_code.php
View File

@ -1,62 +0,0 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title><?php echo $this->code; ?> &mdash; httpstatus.es</title>
<link rel="author" href="humans.txt" />
<link rel="stylesheet" href="assets/css/style.css" type="text/css" />
<link rel="shortcut icon" href="assets/img/favicon.ico">
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-29439846-1']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
<meta name="description" content="HTTP Status code list / directory with wikipedia and ietf descriptions"/>
</head>
<body>
<div id="wrapper">
<div class="header">
<?php echo $this->code; ?> / <span class="status_title"><?php echo $this->title; ?></span>
</div>
<div id="desc">
<?php foreach($this->descriptions as $type => $description) { ?>
<p id="<?php echo $type; ?>">
&#8220;<?php echo nl2br($description["body"]); ?>&#8220; &mdash; <a class="reference" href="<?php echo $description["link"]; ?>"><?php echo $type; ?></a>
</p>
<?php } ?>
</div>
<?php if(isset($this->references)) { ?>
<div id="code_references">
<div class="header">
<?php echo $this->code; ?> / <span class="status_title">code reference(s)</span>
</div>
<div class="info_list">
<?php foreach($this->references as $reference) { ?>
<div class="info_item">
<div class="title">
<?php echo $reference["title"]; ?>
</div>
<div class="value">
<?php echo $reference["value"]; ?>
</div>
<div class="clear"></div>
</div>
<?php } ?>
<div class="clear"></div>
</div>
</div>
<?php } ?>
<div id="return">
<a href="http://httpstatus.es">&larr; return</a>
</div>
</div>
</body>
</html>