Hypertext Transfer Protocol

Published on December 2016 | Categories: Documents | Downloads: 101 | Comments: 0 | Views: 278
of 20
Download PDF   Embed   Report

HTTP totul despre protocolul hhtp

Comments

Content

Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed,
collaborative, hypermedia information systems.[1] Its use for retrieving inter-linked
resources, called hypertext documents, led to the establishment of the World Wide Web in
1990 by English physicist Tim Berners-Lee. There are two major versions, HTTP/1.0 that uses
a separate connection for every document and HTTP/1.1 that can reuse the same
connection to download, for instance, images for the just served page. Hence HTTP/1.1 may
be faster as it takes time to set up such connections.
The standards development of HTTP has been coordinated by the World Wide Web
Consortium and the Internet Engineering Task Force (IETF), culminating in the publication of
a series of Requests for Comments (RFCs), most notably RFC 2616 (June 1999), which defines
HTTP/1.1, the version of HTTP in common use.
Support for pre-standard HTTP/1.1 based on the then developing RFC 2068 was rapidly
adopted by the major browser developers in early 1996. By March 1996, pre-standard
HTTP/1.1 was supported in Netscape 2.0, Netscape Navigator Gold 2.01, Mosaic 2.7, Lynx
2.5, and in Internet Explorer 3.0. End user adoption of the new browsers was rapid. In March
1996, one web hosting company reported that over 40% of browsers in use on the Internet
were HTTP 1.1 compliant. That same web hosting company reported that by June 1996, 65%
of all browsers accessing their servers were HTTP/1.1 compliant.[2] The HTTP/1.1 standard as
defined in RFC 2068 was officially released in January 1997. Improvements and updates to
the HTTP/1.1 standard were released under RFC 2616 in June 1999.
HTTP is a request/response standard as is typical in client-server computing. The client is an
application (e.g. web browser, spider etc) on the computer used by an end-user, the server is
an application running a computer hosting the web site. The client—which submits HTTP
requests—is also referred to as the user agent. The responding server—which stores or
creates resources such as HTML files and images—may be called the origin server. In
between the user agent and origin server may be several intermediaries, such as proxies,
gateways, and tunnels.
HTTP is not constrained in principle to using TCP/IP, although this is its most popular
application via the Internet. Indeed HTTP can be "implemented on top of any other protocol
on the Internet, or on other networks." HTTP only presumes a reliable transport; any
protocol that provides such guarantees can be used."[3]
Resources to be accessed by HTTP are identified using Uniform Resource Identifiers (URIs)—
or, more specifically, Uniform Resource Locators (URLs)—using the http: or https: URI
schemes.

The Internet Protocol Suite
Application Layer
BGP · DHCP · DNS · FTP · GTP · HTTP · IMAP · IRC ·
Megaco · MGCP · NNTP · NTP · POP · RIP · RPC ·
RTP · RTSP · SDP · SIP · SMTP · SNMP · SOAP · SSH ·

Telnet · TLS/SSL · XMPP · (more)
Transport Layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
Internet Layer
IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec ·
(more)
Link Layer
ARP/InARP · NDP · OSPF · Tunnels (L2TP) · PPP ·
Media Access Control (Ethernet, DSL, ISDN, FDDI) ·
(more)
This box: view • talk • edit

HTTP session
An HTTP session is a sequence of network request-response transactions. An HTTP client
initiates a request. It establishes a Transmission Control Protocol (TCP) connection to a
particular port on a host (typically port 80; see List of TCP and UDP port numbers). An HTTP
server listening on that port waits for a client's request message. Upon receiving the request,
the server sends back a status line, such as "HTTP/1.1 200 OK", and a message of its own, the
body of which is perhaps the requested resource, an error message, or some other
information.

Request message
The request message consists of the following:





Request line, such as GET /images/logo.gif HTTP/1.1, which requests a resource called
/images/logo.gif from server
Headers, such as Accept-Language: en
An empty line
An optional message body

The request line and headers must all end with <CR><LF> (that is, a carriage return followed
by a line feed). The empty line must consist of only <CR><LF> and no other whitespace. In
the HTTP/1.1 protocol, all headers except Host are optional.
A request line containing only the path name is accepted by servers to maintain
compatibility with HTTP clients before the HTTP/1.0 specification in RFC1945[4].

Request methods

An HTTP request made using telnet. The request, response headers and response body are
highlighted.
HTTP defines eight methods (sometimes referred to as "verbs") indicating the desired action
to be performed on the identified resource. What this resource represents, whether preexisting data or data that is generated dynamically, depends on the implementation of the
server. Often, the resource corresponds to a file or the output of an executable residing on
the server.
HEAD
Asks for the response identical to the one that would correspond to a GET request,
but without the response body. This is useful for retrieving meta-information written
in response headers, without having to transport the entire content.
GET
Requests a representation of the specified resource. Note that GET should not be
used for operations that cause side-effects, such as using it for taking actions in web
applications. One reason for this is that GET may be used arbitrarily by robots or
crawlers, which should not need to consider the side effects that a request should
cause. See safe methods below.
POST
Submits data to be processed (e.g., from an HTML form) to the identified resource.
The data is included in the body of the request. This may result in the creation of a
new resource or the updates of existing resources or both.
PUT
Uploads a representation of the specified resource.
DELETE
Deletes the specified resource.
TRACE
Echoes back the received request, so that a client can see what intermediate servers
are adding or changing in the request.
OPTIONS
Returns the HTTP methods that the server supports for specified URL. This can be
used to check the functionality of a web server by requesting '*' instead of a specific
resource.
CONNECT
Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate
SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.[5]

HTTP servers are required to implement at least the GET and HEAD methods [6] and,
whenever possible, also the OPTIONS method.[citation needed]

Safe methods
Some methods (for example, HEAD, GET, OPTIONS and TRACE) are defined as safe, which
means they are intended only for information retrieval and should not change the state of
the server. In other words, they should not have side effects, beyond relatively harmless
effects such as logging, caching, the serving of banner advertisements or incrementing a web
counter. Making arbitrary GET requests without regard to the context of the application's
state should therefore be considered safe.
By contrast, methods such as POST, PUT and DELETE are intended for actions which may
cause side effects either on the server, or external side effects such as financial transactions
or transmission of email. Such methods are therefore not usually used by conforming web
robots or web crawlers, which tend to make requests without regard to context or
consequences.
Despite the prescribed safety of GET requests, in practice their handling by the server is not
technically limited in any way, and careless or deliberate programming can just as easily (or
more easily, due to lack of user agent precautions) cause non-trivial changes on the server.
This is discouraged, because it can cause problems for Web caching, search engines and
other automated agents, which can make unintended changes on the server.

Idempotent methods and web applications
Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical
requests should have the same effect as a single request. Methods GET, HEAD, OPTIONS and
TRACE, being prescribed as safe, should also be idempotent, as HTTP is a stateless protocol.
By contrast, the POST method is not necessarily idempotent, and therefore sending an
identical POST request multiple times may further affect state or cause further side effects
(such as financial transactions). In some cases this may be desirable, but in other cases this
could be due to an accident, such as when a user does not realize that their action will result
in sending another request, or they did not receive adequate feedback that their first
request was successful. While web browsers may show alert dialog boxes to warn users in
some cases where reloading a page may re-submit a POST request, it is generally up to the
web application to handle cases where a POST request should not be submitted more than
once.
Note that whether a method is idempotent is not enforced by the protocol or web server. It
is perfectly possible to write a web application in which (for example) a database insert or
other non-idempotent action is triggered by a GET or other request. Ignoring this
recommendation, however, may result in undesirable consequences if a user agent assumes
that repeating the same request is safe when it isn't.

Status codes
See also: List of HTTP status codes
In HTTP/1.0 and since, the first line of the HTTP response is called the status line and
includes a numeric status code (such as "404") and a textual reason phrase (such as "Not
Found"). The way the user agent handles the response primarily depends on the code and
secondarily on the response headers. Custom status codes can be used since, if the user
agent encounters a code it does not recognize, it can use the first digit of the code to
determine the general class of the response.[7]
Also, the standard reason phrases are only recommendations and can be replaced with
"local equivalents" at the web developer's discretion. If the status code indicated a problem,
the user agent might display the reason phrase to the user to provide further information
about the nature of the problem. The standard also allows the user agent to attempt to
interpret the reason phrase, though this might be unwise since the standard explicitly
specifies that status codes are machine-readable and reason phrases are human-readable.

Persistent connections
Main article: HTTP persistent connections
In HTTP/0.9 and 1.0, the connection is closed after a single request/response pair. In
HTTP/1.1 a keep-alive-mechanism was introduced, where a connection could be reused for
more than one request.
Such persistent connections reduce lag perceptibly, because the client does not need to renegotiate the TCP connection after the first request has been sent.
Version 1.1 of the protocol made bandwidth optimization improvements to HTTP/1.0. For
example, HTTP/1.1 introduced chunked transfer encoding to allow content on persistent
connections to be streamed, rather than buffered. HTTP pipelining further reduces lag time,
allowing clients to send multiple requests before a previous response has been received to
the first one. Another improvement to the protocol was byte serving, which is when a server
transmits just the portion of a resource explicitly requested by a client.

HTTP session state
HTTP is a stateless protocol. The advantage of a stateless protocol is that hosts do not need
to retain information about users between requests, but this forces web developers to use
alternative methods for maintaining users' states. For example, when a host needs to
customize the content of a website for a user, the web application must be written to track
the user's progress from page to page. A common method for solving this problem involves
sending and receiving cookies. Other methods include server side sessions, hidden variables
(when the current page is a form), and URL encoded parameters (such as
/index.php?session_id=some_unique_session_code).

Secure HTTP
There are currently two methods of establishing a secure HTTP connection: the HTTPS URI
scheme and the HTTP 1.1 Upgrade header, introduced by RFC 2817. Browser support for the
Upgrade header is, however, nearly non-existent, hence the HTTPS URI scheme is still the
dominant method of establishing a secure HTTP connection. Secure HTTP is notated by the
prefix HTTPS:// instead of HTTP://

HTTPS URI scheme
Main article: HTTPS
HTTPS: is a URI scheme syntactically identical to the http: scheme used for normal HTTP

connections, but which signals the browser to use an added encryption layer of SSL/TLS to
protect the traffic. SSL is especially suited for HTTP since it can provide some protection even
if only one side of the communication is authenticated. This is the case with HTTP
transactions over the Internet, where typically only the server is authenticated (by the client
examining the server's certificate).

HTTP 1.1 Upgrade header
HTTP 1.1 introduced support for the Upgrade header. In the exchange, the client begins by
making a clear-text request, which is later upgraded to TLS. Either the client or the server
may request (or demand) that the connection be upgraded. The most common usage is a
clear-text request by the client followed by a server demand to upgrade the connection,
which looks like this:
Client:
GET /encrypted-area HTTP/1.1
Host: www.example.com

Server:
HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

The server returns a 426 status-code because 400 level codes indicate a client failure (see
List of HTTP status codes), which correctly alerts legacy clients that the failure was clientrelated.
The benefits of using this method for establishing a secure connection are:


that it removes messy and problematic redirection and URL rewriting on the server
side,




it allows virtual hosting of secured websites (although HTTPS also allows this using
Server Name Indication), and
it reduces user confusion by providing a single way to access a particular resource.

A weakness with this method is that the requirement for a secure HTTP cannot be specified
in the URI. In practice, the (untrusted) server will thus be responsible for enabling secure
HTTP, not the (trusted) client.

Example session
Below is a sample conversation between an HTTP client and an HTTP server running on
www.example.com, port 80.
Client request (followed by a blank line, so that request ends with a double newline, each in
the form of a carriage return followed by a line feed):
GET /index.html HTTP/1.1
Host: www.example.com

The "Host" header distinguishes between various DNS names sharing a single IP address,
allowing name-based virtual hosting. While optional in HTTP/1.0, it is mandatory in
HTTP/1.1.
Server response (followed by a blank line and text of the requested page):
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8

The ETag (entity tag) header is used to determine if a cached version of the requested
resource is identical to the current version of the resource on the server. Content-Type
specifies the Internet media type of the data conveyed by the http message, while ContentLength indicates its length in bytes. The HTTP/1.1 webserver publishes its ability to respond
to requests for certain byte ranges of the document by setting the header Accept-Ranges:
bytes. This is useful if the client needs to have only certain portions[8] of a resource sent by
the server, which is called byte serving. When Connection: close is sent in a header, it means
that the web server will close the TCP connection immediately after the transfer of this
package.

List of HTTP headers
HTTP Headers form the core of an HTTP request, and are very important in an HTTP
response. They define various characteristics of the data that is requested or the data that
has been provided. The headers are separated from the request or response body by a blank
line. HTTP headers can be near-arbitrary strings, but only some are commonly understood.

Requests
Header

Description

Example

Accept

Content-Types that are acceptable

Accept: text/plain

Accept-Charset

Character sets that are acceptable

Accept-Charset: iso-8859-5

Accept-Encoding Acceptable encodings

Accept-Encoding: compress, gzip

Accept-Language Acceptable languages for response

Accept-Language: da

Accept-Ranges

Allows the server to indicate its acceptance
Accept-Ranges: bytes
of range requests for a resource

Authorization

Authentication credentials for HTTP
authentication

Authorization: Basic
QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Cache-Control

Used to specify directives that MUST be
obeyed by all caching mechanisms along
the request/response chain

Cache-Control: no-cache

Connection

What type of connection the user-agent
would prefer

Connection: close

Cookie

an HTTP cookie previously sent by the
server with Set-Cookie (below)

Cookie: $Version=1; UserId=JohnDoe

Content-Length

The length of the request body in octets (8Content-Length: 348
bit bytes)

Content-Type

The mime type of the body of the request
(used with POST and PUT requests)

Content-Type: application/x-www-formurlencoded

Date

The date and time that the message was

Date: Tue, 15 Nov 1994 08:12:31 GMT

sent
Expect

Indicates that particular server behaviors
are required by the client

Expect: 100-continue

From

The email address of the user making the
request

From: [email protected]

Host

The domain name of the server (for virtual
Host: en.wikipedia.org
hosting), mandatory since HTTP/1.1

If-Match

Only perform the action if the client
supplied entity matches the same entity on
the server. This is mainly for methods like If-Match:
PUT to only update a resource if it has not "737060cd8c284d8af7ad3082f209582d"
been modified since the user last updated
it.

If-Modified-Since

Allows a 304 Not Modified to be returned if If-Modified-Since: Sat, 29 Oct 1994
19:43:31 GMT
content is unchanged

If-None-Match

Allows a 304 Not Modified to be returned if If-None-Match:
"737060cd8c284d8af7ad3082f209582d"
content is unchanged, see HTTP ETag

If-Range

If the entity is unchanged, send me the
part(s) that I am missing; otherwise, send
me the entire new entity

If-UnmodifiedSince

Only send the response if the entity has not If-Unmodified-Since: Sat, 29 Oct 1994
19:43:31 GMT
been modified since a specific time.

Max-Forwards

Limit the number of times the message can
Max-Forwards: 10
be forwarded through proxies or gateways.

Pragma

Implementation-specific headers that may
have various effects anywhere along the
Pragma: no-cache
request-response chain.

ProxyAuthorization

Authorization credentials for connecting to Proxy-Authorization: Basic
QWxhZGRpbjpvcGVuIHNlc2FtZQ==
a proxy.

Range

Request only part of an entity.

Range: bytes=500-999

Referer

This is the address of the previous web
page from which a link to the currently
requested page was followed.

Referer:
http://en.wikipedia.org/wiki/Main_Page

If-Range:
"737060cd8c284d8af7ad3082f209582d"

TE

The transfer encodings the user agent is
willing to accept: the same values as for the
response header Transfer-Encoding can be
used, plus the "trailers" value (related to
TE: trailers, deflate;q=0.5
the "chunked" transfer method) to notify
the server it accepts to receive additional
headers (the trailers) after the last, zerosized, chunk.

Upgrade

Ask the server to upgrade to another
protocol.

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9,
RTA/x11

User-Agent

The user agent string of the user agent

User-Agent: Mozilla/5.0 (Linux; X11)

Via

Informs the server of proxies through which Via: 1.0 fred, 1.1 nowhere.com
(Apache/1.1)
the request was sent.

Warn

A general warning about possible problems
Warn: 199 Miscellaneous warning
with the entity body.

Responses
Header

Description

Example

Accept-Ranges

What partial content range types
this server supports

Accept-Ranges: bytes

Age

The age the object has been in a
proxy cache in seconds

Age: 12

Allow

Valid actions for a specified
resource. To be used for a 405
Method not allowed

Allow: GET, HEAD

Cache-Control

Tells all caching mechanisms from
server to client whether they may
cache this object

Cache-Control: no-cache

ContentEncoding

The type of encoding used on the
data

Content-Encoding: gzip

ContentLanguage

The language the content is in

Content-Language: da

Content-Length

The length of the response body in
octets (8-bit bytes)

Content-Length: 348

Content-Location

An alternate location for the
returned data

Content-Location: /index.htm

ContentDisposition

An opportunity to raise a "File
Download" dialogue box for a
known MIME type

Content-Disposition: attachment;
filename=fname.ext

Content-MD5

A Base64-encoded binary MD5 sum
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
of the content of the response

Content-Range

Where in a full body message this
partial message belongs

Content-Range: bytes 21010-47021/47022

Content-Type

The mime type of this content

Content-Type: text/html; charset=utf-8

Date

The date and time that the message
Date: Tue, 15 Nov 1994 08:12:31 GMT
was sent

ETag

An identifier for a specific version of
a resource, often a Message Digest, ETag: "737060cd8c284d8af7ad3082f209582d"
see ETag

Expires

Gives the date/time after which the
Expires: Thu, 01 Dec 1994 16:00:00 GMT
response is considered stale

Last-Modified

The last modified date for the
requested object, in RFC 2822
format

Location

Used in redirection, or when a new Location:
http://www.w3.org/pub/WWW/People.html
resource has been created.

Pragma

Implementation-specific headers
that may have various effects
anywhere along the requestresponse chain.

Pragma: no-cache

ProxyAuthenticate

Request authentication to access
the proxy.

Proxy-Authenticate: Basic

Refresh

Used in redirection, or when a new
Refresh: 5;
resource has been created. This
url=http://www.w3.org/pub/WWW/People.html
refresh redirects after 5 seconds.

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

Retry-After

If an entity is temporarily
unavailable, this instructs the client
Retry-After: 120
to try again after a specified period
of time.

Server

A name for the server

Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)

Set-Cookie

an HTTP cookie

Set-Cookie: UserID=JohnDoe; Max-Age=3600;
Version=1

Trailer

The Trailer general field value
indicates that the given set of
header fields is present in the trailer Trailer: Max-Forwards
of a message encoded with chunked
transfer-coding.

TransferEncoding

The form of encoding used to safely
transfer the entity to the user.
Currently defined methods are:
Transfer-Encoding: chunked
chunked, compress, deflate, gzip,
identity.

Vary

Tells downstream proxies how to
match future request headers to
decide whether the cached
response can be used rather than
requesting a fresh one from the
origin server.

Via

Informs the client of proxies through
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
which the response was sent.

Warning

A general warning about possible
problems with the entity body.

WWWAuthenticate

Indicates the authentication scheme
that should be used to access the
WWW-Authenticate: Basic
requested entity.

Vary: *

Warning: 199 Miscellaneous warning

Effects of selected HTTP headers
Avoiding caching
If the server responds with Cache-Control: no-cache then a web browser or other caching system
must not use the response to satisfy subsequent responses without first checking with the

originating server. This header is part of HTTP/1.1, and is ignored by some caches and
browsers. To make sure that an object is not cached, it is therefore sensible to also set the
Expires HTTP 1.0 header to a value earlier than the response date (e.g. -1). This is interpreted
as an instruction not to cache by HTTP/1.0 caches and browsers.
The fact that a resource is not to be cached is no guarantee that it will not be written to disk.
In particular, the HTTP/1.1 definition draws a distinction between history stores and caches.
If you use navigation buttons to go back to a previous page a browser may still show you a
page that has been stored on disk in the history store, even if it has been instructed not to
cache that page. This is correct behaviour according to the specification. Many user agents
(including both Firefox and IE) will show different behaviour with regards to loading
something from history store and loading something from its cache depending on whether
the protocol is http or https.
In the rare event that you specifically do not want a resource to be stored to disk anywhere perhaps the resource is highly sensitive and you don't want it to appear in backups or to be
written to insecure permanent storage - you can use the header Cache-Control: no-store. This
does not guarantee that the resource will not be written, but instructs the browser to make
a best effort not to write it, or in the worst case, that it does not remain on disk.
The Pragma: no-cache header is an HTTP/1.0 header intended for use in requests. It is a means
for the browser to tell the server and any intermediate caches that it wants a fresh version
of the resource, not for the server to tell the browser not to cache the resource. Some user
agents do pay attention to this header in responses (e.g. some versions of IE, but only when
using https), but the HTTP/1.1 RFC specifically warns against relying on this behaviour.

List of HTTP status codes
The following is a list of HyperText Transfer Protocol (HTTP) response status codes. This
includes codes from IETF internet standards as well as unstandardised RFCs, other
specifications and some additional commonly used codes. The first digit of the status code
specifies one of five classes of response; the bare minimum for an HTTP client is that it
recognises these five classes. Microsoft IIS may use additional decimal sub-codes to provide
more specific information,[1] but these are not listed here. The phrases used are the standard
examples, but any human-readable alternative can be provided. Unless otherwise stated,
the status code is part of the HTTP/1.1 standard.


1xx Informational
Request received, continuing process.[2]
This class of status code indicates a provisional response, consisting only of the Status-Line
and optional headers, and is terminated by an empty line. Since HTTP/1.0 did not define any

1xx status codes, servers must not send a 1xx response to an HTTP/1.0 client except under
experimental conditions.
100 Continue
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[2] and check if a 100 Continue
status code is received in response before continuing (or receive 417 Expectation Failed and
not continue).[2]
101 Switching Protocols
This means the requester has asked the server to switch protocols and the server is
acknowledging that it will do so.[2]
102 Processing (WebDAV) (RFC 2518)
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.[3] This prevents the client from
timing out and assuming the request was lost.

2xx Success
The action was successfully received, understood, and accepted.[2]
This class of status code indicates that the client's request was successfully received,
understood, and accepted.
200 OK
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.[2]
201 Created
The request has been fulfilled and resulted in a new resource being created.[2]
202 Accepted
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]

203 Non-Authoritative Information (since HTTP/1.1)
The server successfully processed the request, but is returning information that may be from
another source.[2]
204 No Content
The server successfully processed the request, but is not returning any content.[2]
205 Reset Content
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.[2]
206 Partial Content
The server is delivering only part of the resource due to a range header sent by the client.
This is used by tools like wget to enable resuming of interrupted downloads, or split a
download into multiple simultaneous streams.[2]
207 Multi-Status (WebDAV) (RFC 2518)
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.[3]

3xx Redirection
The client must take additional action to complete the request.[2]
This class of status code indicates that further action needs to be taken by the user agent in
order to fulfil the request. The action required may be carried out by the user agent without
interaction with the user if and only if the method used in the second request is GET or
HEAD. A user agent should not automatically redirect a request more than five times, since
such redirections usually indicate an infinite loop.
300 Multiple Choices
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.[2]
301 Moved Permanently
This and all future requests should be directed to the given URI.[2]
302 Found
This is the most popular redirect code[citation needed], but also an example of industrial practice
contradicting the standard.[2] HTTP/1.0 specification (RFC 1945) required the client to
perform a temporary redirect (the original describing phrase was "Moved Temporarily"),[4]

but popular browsers implemented it as a 303 See Other.[4] Therefore, HTTP/1.1 added
status codes 303 and 307 to distinguish between the two behaviours. However, the majority
of Web applications and frameworks still use the 302 status code as if it were the 303.
303 See Other (since HTTP/1.1)
The response to the request can be found under another URI using a GET method. When
received in response to a PUT, it should be assumed that the server has received the data
and the redirect should be issued with a separate GET message.[2]
304 Not Modified
Indicates the resource has not been modified since last requested.[2] Typically, the HTTP
client provides a header like the If-Modified-Since header to provide a time against which to
compare. Utilizing 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 resent using more bandwidth of the server and client.
305 Use Proxy (since HTTP/1.1)
Many HTTP clients (such as Mozilla[5] and Internet Explorer) do not correctly handle
responses with this status code, primarily for security reasons.[2]
306 Switch Proxy
No longer used.[2]
307 Temporary Redirect (since HTTP/1.1)
In this occasion, the request should be repeated with another URI, but future requests can
still use the original URI.[2] 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.

4xx Client Error
The request contains bad syntax or cannot be fulfilled.[2]
The 4xx class of status code is intended for cases in which the client seems to have erred.
Except when responding to a HEAD request, the server should include an entity containing
an explanation of the error situation, and whether it is a temporary or permanent condition.
These status codes are applicable to any request method. User agents should display any
included entity to the user. These are typically the most common error codes encountered
while online.
400 Bad Request
The request contains bad syntax or cannot be fulfilled.[2]
401 Unauthorized

Similar to 403 Forbidden, but specifically for use when authentication is possible but has
failed or not yet been provided.[2] 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.
402 Payment Required
Reserved for future use.[2] 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 has never been used.
403 Forbidden
The request was a legal request, but the server is refusing to respond to it.[2] Unlike a 401
Unauthorized response, authenticating will make no difference.[2]
404 Not Found
The requested resource could not be found but may be available again in the future.[2]
Subsequent requests by the client are permissible.
405 Method Not Allowed
A request was made of a resource using a request method not supported by that resource;[2]
for example, using GET on a form which requires data to be presented via POST, or using PUT
on a read-only resource.
406 Not Acceptable
The requested resource is only capable of generating content not acceptable according to
the Accept headers sent in the request.[2]
407 Proxy Authentication Required[2]
408 Request Timeout
The server timed out waiting for the request.[2] 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."
409 Conflict
Indicates that the request could not be processed because of conflict in the request, such as
an edit conflict.[2]
410 Gone
Indicates that the resource requested is no longer available and will not be available again.[2]
This should be used when a resource has been intentionally removed; however, it is not
necessary to return this code and a 404 Not Found can be issued instead. 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 indexes.
411 Length Required
The request did not specify the length of its content, which is required by the requested
resource.[2]
412 Precondition Failed
The server does not meet one of the preconditions that the requester put on the request.[2]
413 Request Entity Too Large
The request is larger than the server is willing or able to process.[2]
414 Request-URI Too Long
The URI provided was too long for the server to process.[2]
415 Unsupported Media Type
The request did not specify any media types that the server or resource supports.[2] For
example the client specified that an image resource should be served as image/svg+xml, but
the server cannot find a matching version of the image.
416 Requested Range Not Satisfiable
The client has asked for a portion of the file, but the server cannot supply that portion.[2] For
example, if the client asked for a part of the file that lies beyond the end of the file.
417 Expectation Failed
The server cannot meet the requirements of the Expect request-header field.[2]
418 I'm a teapot
The HTCPCP server is a teapot.[6] The responding entity MAY be short and stout.[6] This code
was defined 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.
422 Unprocessable Entity (WebDAV) (RFC 4918)
The request was well-formed but was unable to be followed due to semantic errors.[7]
423 Locked (WebDAV) (RFC 4918)
The resource that is being accessed is locked[7]
424 Failed Dependency (WebDAV) (RFC 4918)
The request failed due to failure of a previous request (e.g. a PROPPATCH).[7]

425 Unordered Collection (RFC 3648)
Defined in drafts of "WebDAV Advanced Collections Protocol",[8] but not present in "Web
Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol".[9]
426 Upgrade Required (RFC 2817)
The client should switch to TLS/1.0.[10]
449 Retry With
A Microsoft extension. The request should be retried after doing the appropriate action.[11]
450 Blocked by Windows Parental Controls
A Microsoft extension. This error is given when Windows Parental Controls are turned on and
are blocking access to the given webpage.[12]

5xx Server Error
The server failed to fulfil an apparently valid request.[2]
Response status codes beginning with the digit "5" indicate cases in which the server is
aware that it has encountered an error or is otherwise incapable of performing the request.
Except when responding to a HEAD request, the server should include an entity containing
an explanation of the error situation, and indicate whether it is a temporary or permanent
condition. Likewise, user agents should display any included entity to the user. These
response codes are applicable to any request method.
500 Internal Server Error
A generic error message, given when no more specific message is suitable.[2]
501 Not Implemented
The server either does not recognise the request method, or it lacks the ability to fulfil the
request.[2]
502 Bad Gateway
The server was acting as a gateway or proxy and received an invalid response from the
downstream server.[2]
503 Service Unavailable
The server is currently unavailable (because it is overloaded or down for maintenance).[2]
Generally, this is a temporary state.
504 Gateway Timeout

The server was acting as a gateway or proxy and did not receive a timely request from the
downstream server.[2]
505 HTTP Version Not Supported
The server does not support the HTTP protocol version used in the request.[2]
506 Variant Also Negotiates (RFC 2295)
Transparent content negotiation for the request, results in a circular reference.[13]
507 Insufficient Storage (WebDAV) (RFC 4918)[7]
509 Bandwidth Limit Exceeded (Apache bw/limited extension)
This status code, while used by many servers, is not specified in any RFCs.
510 Not Extended (RFC 2774)
Further extensions to the request are required for the server to fulfil it.[14]

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close