RFC 1945
Hypertext Transfer Protocol -- HTTP/1.0
Hypertext Transfer Protocol -- HTTP/1.0 🎀
okay bestie, this is RFC 1945 💖 It came out in May 1996 from the Network Working Group, and it's marked Informational 🦋 Three people wrote it: T. Berners-Lee (MIT/LCS), R. Fielding (UC Irvine), and H. Frystyk (MIT/LCS) 🫶 The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨
Status of This Memo ✨
This memo gives information to the Internet community 📚 It does not specify an Internet standard of any kind 🙈 Distribution of this memo is unlimited 🌈
IESG Note 🙈
The IESG has concerns about this protocol 😭 and they expect this document to get replaced pretty soon by a standards track document 💀
Abstract 🌸
HTTP is an application-level protocol with the lightness and speed needed for distributed, collaborative, hypermedia information systems 🔥 It's a generic, stateless, object-oriented protocol, and you can use it for lots of stuff, like name servers and distributed object management systems, by extending its request methods (commands) 🧚 One thing HTTP is iconic for is typing its data representation, so systems can be built independently of the data being transferred 💅
HTTP has been used by the World-Wide Web global information initiative since 1990 🌍 This specification reflects common usage of the protocol referred to as "HTTP/1.0" ✨
Table of Contents 📚
1. Introduction .............................................. 4
1.1 Purpose .............................................. 4
1.2 Terminology .......................................... 4
1.3 Overall Operation .................................... 6
1.4 HTTP and MIME ........................................ 8
2. Notational Conventions and Generic Grammar ................ 8
2.1 Augmented BNF ........................................ 8
2.2 Basic Rules .......................................... 10
3. Protocol Parameters ....................................... 12
3.1 HTTP Version ......................................... 12
3.2 Uniform Resource Identifiers ......................... 14
3.2.1 General Syntax ................................ 14
3.2.2 http URL ...................................... 15
3.3 Date/Time Formats .................................... 15
3.4 Character Sets ....................................... 17
3.5 Content Codings ...................................... 18
3.6 Media Types .......................................... 19
3.6.1 Canonicalization and Text Defaults ............ 19
3.6.2 Multipart Types ............................... 20
3.7 Product Tokens ....................................... 20
4. HTTP Message .............................................. 21
4.1 Message Types ........................................ 21
4.2 Message Headers ...................................... 22
4.3 General Header Fields ................................ 23
5. Request ................................................... 23
5.1 Request-Line ......................................... 23
5.1.1 Method ........................................ 24
5.1.2 Request-URI ................................... 24
5.2 Request Header Fields ................................ 25
6. Response .................................................. 25
6.1 Status-Line .......................................... 26
6.1.1 Status Code and Reason Phrase ................. 26
6.2 Response Header Fields ............................... 28
7. Entity .................................................... 28
7.1 Entity Header Fields ................................. 29
7.2 Entity Body .......................................... 29
7.2.1 Type .......................................... 29
7.2.2 Length ........................................ 30
8. Method Definitions ........................................ 30
8.1 GET .................................................. 31
8.2 HEAD ................................................. 31
8.3 POST ................................................. 31
9. Status Code Definitions ................................... 32
9.1 Informational 1xx .................................... 32
9.2 Successful 2xx ....................................... 32
9.3 Redirection 3xx ...................................... 34
9.4 Client Error 4xx ..................................... 35
9.5 Server Error 5xx ..................................... 37
10. Header Field Definitions .................................. 37
10.1 Allow ............................................... 38
10.2 Authorization ....................................... 38
10.3 Content-Encoding .................................... 39
10.4 Content-Length ...................................... 39
10.5 Content-Type ........................................ 40
10.6 Date ................................................ 40
10.7 Expires ............................................. 41
10.8 From ................................................ 42
10.9 If-Modified-Since ................................... 42
10.10 Last-Modified ....................................... 43
10.11 Location ............................................ 44
10.12 Pragma .............................................. 44
10.13 Referer ............................................. 44
10.14 Server .............................................. 45
10.15 User-Agent .......................................... 46
10.16 WWW-Authenticate .................................... 46
11. Access Authentication ..................................... 47
11.1 Basic Authentication Scheme ......................... 48
12. Security Considerations ................................... 49
12.1 Authentication of Clients ........................... 49
12.2 Safe Methods ........................................ 49
12.3 Abuse of Server Log Information ..................... 50
12.4 Transfer of Sensitive Information ................... 50
12.5 Attacks Based On File and Path Names ................ 51
13. Acknowledgments ........................................... 51
14. References ................................................ 52
15. Authors' Addresses ........................................ 54
Appendix A. Internet Media Type message/http ................ 55
Appendix B. Tolerant Applications ........................... 55
Appendix C. Relationship to MIME ............................ 56
C.1 Conversion to Canonical Form ......................... 56
C.2 Conversion of Date Formats ........................... 57
C.3 Introduction of Content-Encoding ..................... 57
C.4 No Content-Transfer-Encoding ......................... 57
C.5 HTTP Header Fields in Multipart Body-Parts ........... 57
Appendix D. Additional Features ............................. 57
D.1 Additional Request Methods ........................... 58
D.1.1 PUT ........................................... 58
D.1.2 DELETE ........................................ 58
D.1.3 LINK .......................................... 58
D.1.4 UNLINK ........................................ 58
D.2 Additional Header Field Definitions .................. 58
D.2.1 Accept ........................................ 58
D.2.2 Accept-Charset ................................ 59
D.2.3 Accept-Encoding ............................... 59
D.2.4 Accept-Language ............................... 59
D.2.5 Content-Language .............................. 59
D.2.6 Link .......................................... 59
D.2.7 MIME-Version .................................. 59
D.2.8 Retry-After ................................... 60
D.2.9 Title ......................................... 60
D.2.10 URI ........................................... 601. Introduction ✨
1.1. Purpose 💅
HTTP is an application-level protocol with the lightness and speed needed for distributed, collaborative, hypermedia information systems 🔥 It's been in use by the World-Wide Web global information initiative since 1990 🌍 This specification reflects common usage of the protocol referred to as "HTTP/1.0" 💖 It describes the features that seem to be consistently implemented in most HTTP/1.0 clients and servers 🫶 The spec is split into two sections: the features that implementations usually agree on are in the main body, and the features with few or inconsistent implementations are listed in Appendix D 🎀
Real information systems need more than simple retrieval, like search, front-end update, and annotation ✨ HTTP lets you use an open-ended set of methods to show the purpose of a request 🧚 It builds on the reference discipline of the Uniform Resource Identifier (URI) [2], as a location (URL) [4] or name (URN) [16], to point at the resource a method gets applied to 🦋 Messages are passed in a format similar to Internet Mail [7] and the Multipurpose Internet Mail Extensions (MIME) [5] 💜
HTTP is also used as a generic protocol for talking between user agents and proxies/gateways to other Internet protocols, like SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8] 🌈 That gives you basic hypermedia access to resources from all kinds of different applications, and it makes user agents way easier to build 😭🍓
1.2. Terminology ✨
Okay bestie, this spec uses a bunch of terms for the roles everyone plays in an HTTP conversation, so let's get them straight 💅
- connection: a transport layer virtual circuit set up between two application programs so they can communicate 🔌
- message: the basic unit of HTTP communication 💬. It's a structured sequence of octets that matches the syntax in Section 4 and gets sent over the connection.
- request: an HTTP request message (as defined in Section 5) 📨
- response: an HTTP response message (as defined in Section 6) 📬
- resource: a network data object or service that you can identify with a URI (Section 3.2) 🌐
- entity: a particular representation or rendition of a data resource, or a reply from a service resource, that can be wrapped up inside a request or response message 🎀. An entity is made of metainformation (entity headers) plus content (the entity body).
- client: an application program that sets up connections so it can send requests 📱
- user agent: the client that starts a request. These are usually browsers, editors, spiders (web-traversing robots) or other end-user tools 🕷️
- server: an application program that accepts connections so it can service requests by sending back responses 🖥️
- origin server: the server where a given resource lives, or where it's going to be created 🏠
- proxy: an intermediary program that acts as both a server and a client so it can make requests on behalf of other clients 🧚. It either services requests internally or passes them along to other servers, with possible translation. A proxy must interpret and, if necessary, rewrite a request message before forwarding it. Proxies are often used as client-side portals through network firewalls, and as helper apps for handling requests over protocols the user agent doesn't implement.
- gateway: a server that acts as an intermediary for some other server 🚪. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource, so the requesting client might not even realize it's talking to a gateway 🕵️. Gateways are often used as server-side portals through network firewalls, and as protocol translators for accessing resources stored on non-HTTP systems.
- tunnel: an intermediary program acting as a blind relay between two connections 🚇. Once it's active, a tunnel isn't considered a party to the HTTP communication, even though an HTTP request may have kicked it off. The tunnel stops existing when both ends of the relayed connections are closed. Tunnels get used when a portal is necessary and the intermediary cannot, or should not, interpret the relayed communication.
- cache: a program's local store of response messages, plus the subsystem that controls storing, retrieving and deleting them 💾. A cache stores cachable responses so future, equivalent requests get a faster response time and use less network bandwidth. Any client or server may include a cache, though a cache cannot be used by a server while it's acting as a tunnel.
Any given program may be capable of being both a client and a server, and these terms only describe the role the program is playing for a particular connection, not everything it can do in general 🌸. Likewise, any server may act as an origin server, proxy, gateway or tunnel, switching behavior based on the nature of each request.
1.3. Overall Operation ✨
HTTP is all about the request/response paradigm 🔁. A client sets up a connection with a server and sends it a request, which is a request method, a URI and a protocol version, followed by a MIME-like message with request modifiers, client information and possible body content. The server answers with a status line that includes the message's protocol version and a success or error code, followed by a MIME-like message with server information, entity metainformation and possible body content.
Most HTTP communication is started by a user agent and is a request to act on a resource on some origin server 💖. In the simplest case, that happens over a single connection (v) between the user agent (UA) and the origin server (O).
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chainIt gets more complicated when one or more intermediaries are in the request/response chain 🌀. There are three common kinds of intermediary: proxy, gateway and tunnel. A proxy is a forwarding agent 📤. It receives requests for a URI in its absolute form, rewrites all or part of the message, and forwards the reformatted request toward the server identified by the URI. A gateway is a receiving agent that acts as a layer above some other server(s) and, if necessary, translates requests into the underlying server's protocol 🧩. A tunnel is a relay point between two connections that doesn't change the messages at all 🫶. Tunnels are used when communication has to get through an intermediary, like a firewall, even when that intermediary can't understand what the messages say.
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chainThe figure above shows three intermediaries (A, B and C) between the user agent and the origin server 👀. A request or response message that travels the whole chain has to go through four separate connections. This matters because some HTTP communication options might only apply to the connection with the nearest non-tunnel neighbor, only to the endpoints of the chain, or to every connection along the chain. Even though the diagram looks linear, each participant can be in multiple simultaneous conversations 🔥. For example, B might be getting requests from lots of clients other than A, and/or forwarding requests to servers other than C, at the same time that it's handling A's request.
Any party to the communication that isn't acting as a tunnel may use an internal cache when handling requests 💾. The whole point of a cache is that the request/response chain gets shorter if any participant along the chain already has a cached response that applies to the request. The next figure shows what the chain looks like if B has a cached copy of an earlier response from O (coming via C) for a request that UA or A hasn't cached.
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chainNot all responses are cachable, and some requests can include modifiers that put special requirements on cache behavior 🙈. Some HTTP/1.0 applications use heuristics to decide what is or isn't a "cachable" response, but those rules aren't standardized.
On the Internet, HTTP communication usually happens over TCP/IP connections 🌍. The default port is TCP 80 [15], but other ports can be used too. That doesn't stop HTTP from running on top of any other Internet protocol, or on other networks. HTTP only assumes a reliable transport, so any protocol that gives those guarantees can be used. How the HTTP/1.0 request and response structures get mapped onto that protocol's transport data units is outside the scope of this specification.
Except for experimental applications, current practice requires that the client sets up the connection before each request, and that the server closes it after sending the response 🔒. Both clients and servers should be aware that either party might close the connection early, because of user action, an automated time-out or a program failure, and should handle that closing in a predictable way. Either way, closing the connection by one or both parties always ends the current request, no matter what its status is 💀.
1.4. HTTP and MIME 🦋
HTTP/1.0 uses a lot of the constructs defined for MIME, as defined in RFC 1521 [5] 📚. Appendix C explains how the context of HTTP allows for different uses of Internet Media Types than you'd typically see in Internet mail, and gives the reasoning behind those differences ✨.
2. Notational Conventions and Generic Grammar 🌈
2.1. Augmented BNF ✨
okay so every mechanism in this spec gets explained twice, once in regular prose and once in a special grammar called augmented BNF 🤓. it's a cousin of the one RFC 822 [7] uses, so you have to be fluent in it to get what's going on. let's go through the bits 🎀
name = definition: the rule name is just the name itself (no<or>around it), and it's separated from its definition by the equals sign=. whitespace only matters for one thing: indenting continuation lines is how you show a rule that runs onto more than one line. some basic rules are uppercase, likeSP,LWS,HT,CRLF,DIGIT,ALPHA, etc. angle brackets show up inside definitions whenever they make it easier to spot which rule names are which 💅"literal": quotation marks wrap literal text. unless it says otherwise, the text is case-insensitive 🌸rule1 | rule2: a bar means alternatives. so"yes | no"will accept yes or no ✨(rule1 rule2): parentheses bundle things into one single element. so"(elem (foo | bar) elem)"allows the token sequences"elem foo elem"and"elem bar elem"🧚*rule: the asterisk means repetition. the full form is<n>*<m>element, which means at least<n>and at most<m>occurrences of element. the defaults are 0 and infinity, so*(element)allows any number, zero included.1*elementneeds at least one, and1*2elementallows one or two 🦋[rule]: square brackets enclose optional elements.[foo bar]is the same as*1(foo bar)🍓N rule: specific repetition.<n>(element)is the same as<n>*<n>(element), so exactly<n>occurrences of (element). that means2DIGITis a 2-digit number and3ALPHAis a string of three alphabetic characters 💜#rule: the#works like*but is built for lists. the full form is<n>#<m>element, meaning at least<n>and at most<m>elements, each separated by one or more commas (",") plus optional linear whitespace (LWS). a rule like( *LWS element *( *LWS "," *LWS element ))can be written as1#element, which is so much easier to read 😭 null elements are allowed wherever this shows up, but they don't count toward the total. so(element), , (element)is allowed but only counts as two elements. that means that wherever at least one element is required, at least one non-null element MUST be present 🔥 the defaults are 0 and infinity, so#(element)allows any number including zero,1#elementneeds at least one, and1#2elementallows one or two 👑; comment: a semicolon set off a bit to the right of the rule text starts a comment that runs to the end of the line. it's a cute way to drop useful notes right next to the spec 🎀implied *LWS: this grammar is word-based. unless noted otherwise, LWS can go between any two adjacent words (token or quoted-string), and between adjacent tokens and delimiters (tspecials), without changing how a field gets read. at least one delimiter (tspecials) MUST exist between any two tokens, because otherwise they'd just be read as one token 🫶 still, applications SHOULD try to stick to "common form" when generating HTTP constructs, since some implementations fail to accept anything beyond the common forms 🙈
2.2. Basic Rules ✨
these rules get used all over the spec to describe the basic parsing stuff. the US-ASCII coded character set is defined by [17] 💖
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>in HTTP/1.0, the end-of-line marker for every protocol element is the octet sequence CR LF, except for the Entity-Body (see Appendix B if you want the tolerant-applications version). the end-of-line marker inside an Entity-Body is set by its media type, as described in Section 3.6 🌈
CRLF = CR LFHTTP/1.0 headers MAY get folded onto multiple lines, as long as every continuation line starts with a space or a horizontal tab 🦋 all linear whitespace, folding included, means the same thing as SP 💅
LWS = [CRLF] 1*( SP | HT )not every application expects folded header lines though, so HTTP/1.0 applications SHOULD NOT generate them 😬
the TEXT rule is only for descriptive field contents and values that the message parser isn't supposed to interpret. words of *TEXT MAY contain octets from character sets other than US-ASCII ✨
TEXT = <any OCTET except CTLs,
but including LWS>if a recipient gets header field TEXT with octets outside the US-ASCII set, it MAY assume those octets are ISO-8859-1 characters 🌸
hex numeric characters show up in several protocol elements 🧚
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGITlots of HTTP/1.0 header field values are just words separated by LWS or special characters. if you want to use these special characters inside a parameter value, they MUST be inside a quoted string 🔥
word = token | quoted-string
token = 1*<any CHAR except CTLs or tspecials>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HTcomments MAY be added to some HTTP header fields by wrapping the comment text in parentheses 💜 comments are only allowed in fields whose field value definition includes "comment". in every other field, parentheses are just part of the field value 🙈
comment = "(" *( ctext | comment ) ")"
ctext = <any TEXT excluding "(" and ")">any string of text gets parsed as one single word if you wrap it in double-quote marks 🎀
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <any CHAR except <"> and CTLs,
but including LWS>single-character quoting with the backslash ("\") character is NOT permitted in HTTP/1.0. no escape-hatch vibes 😭
3. Protocol Parameters ✨
3.1. HTTP Version 🦋
HTTP numbers its versions as "<major>.<minor>". the versioning policy is meant to tell the sender's message format and how much it can understand from further HTTP communication, not which features it's gotten through that communication 💖 adding message components that don't affect communication behaviour, or that only add to extensible field values, does NOT change the version number. the <minor> number goes up when the protocol changes add features that don't change the general message parsing algorithm, but that MAY add to the message semantics and imply extra sender capabilities 🌸 the <major> number goes up when the format of a message in the protocol changes 👑
the HTTP-Version field in the first line of a message tells you that message's version. if the protocol version isn't specified, the recipient MUST assume the message is in the simple HTTP/0.9 format 😬
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGITmajor and minor numbers SHOULD be treated as separate integers, and each one MAY go higher than a single digit. so HTTP/2.4 is a lower version than HTTP/2.13, which is lower than HTTP/12.3 🧚 recipients SHOULD ignore leading zeros, and senders should never generate them 🍓
this document defines both the 0.9 and 1.0 versions of HTTP. applications sending Full-Request or Full-Response messages (as this spec defines them) MUST include an HTTP-Version of "HTTP/1.0" ✨
HTTP/1.0 servers MUST:
- recognize the format of the Request-Line for HTTP/0.9 and HTTP/1.0 requests;
- understand any valid request in the format of HTTP/0.9 or HTTP/1.0;
- respond appropriately with a message in the same protocol version used by the client.
HTTP/1.0 clients MUST:
- recognize the format of the Status-Line for HTTP/1.0 responses;
- understand any valid response in the format of HTTP/0.9 or HTTP/1.0.
proxy and gateway apps MUST be careful when forwarding requests that come in a format different from the app's native HTTP version 🔥 the protocol version tells you what the sender is capable of, so a proxy/gateway MUST never send a message with a version indicator higher than its native version. if it gets a higher-version request, the proxy/gateway MUST either downgrade the request version or respond with an error 💀 requests with a lower version than the app's native format MAY be upgraded before they get forwarded. and the proxy/gateway's response to that request MUST follow the server requirements listed above 🫶
3.2. Uniform Resource Identifiers 🌈
URIs have had so many names over the years: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers [2], and finally the combo of Uniform Resource Locators (URL) [4] and Names (URN) [16] 🦋 as far as HTTP is concerned, Uniform Resource Identifiers are just formatted strings that identify a network resource, whether that's by name, location, or any other characteristic 💖 periodt
3.2.1. General Syntax ✨
okay bestie, URIs in HTTP can show up in absolute form OR relative to some known base URI [9], depending on the context they're used in. 🦋 You can tell them apart because absolute URIs always start with a scheme name followed by a colon. No cap, that's the giveaway. 💅
Here's the whole grammar, periodt:
URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
absoluteURI = scheme ":" *( uchar | reserved )
relativeURI = net_path | abs_path | rel_path
net_path = "//" net_loc [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]
path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar
params = param *( ";" param )
param = *( pchar | "/" )
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = <any OCTET excluding ALPHA, DIGIT,
reserved, extra, safe, and unsafe>For the official word on URL syntax and semantics, check out RFC 1738 [4] and RFC 1808 [9]. ✨ The grammar above includes national characters that RFC 1738 says aren't allowed in valid URLs. That's because HTTP servers aren't restricted in which unreserved characters can show up in the rel_path part of addresses, and HTTP proxies may receive requests for URIs that RFC 1738 never defined. Wild, but valid. 🌈
3.2.2. http URL 🦋
The "http" scheme is used to locate network resources via the HTTP protocol, and this section defines its scheme-specific syntax and semantics. 💜
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
host = <A legal Internet host domain name
or IP address (in dotted-decimal form),
as defined by Section 2.1 of RFC 1123>
port = *DIGITSo if the port is empty or not given, port 80 is assumed (classic default, iconic 🌸). The identified resource lives at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path. If the abs_path isn't in the URL, it MUST be given as "/" when used as a Request-URI (Section 5.1.2). Not optional, bestie. 🫶
Note: Although the HTTP protocol is independent of the transport layer protocol, the http URL only identifies resources by their TCP location, and thus non-TCP resources MUST be identified by some other URI scheme. 🙈
The canonical form for "http" URLs is obtained by converting any UPALPHA characters in host to their LOALPHA equivalent (hostnames are case-insensitive), eliding the [ ":" port ] if the port is 80, and replacing an empty abs_path with "/". So basically, tidy it up and make it consistent. 🧚
3.3. Date/Time Formats ⏰
HTTP/1.0 apps have historically allowed three different formats for date/time stamps, and yes, all three are still a whole thing. 😭
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() formatThe first format is the preferred Internet standard, and it's a fixed-length subset of what RFC 1123 [6] defines (an update to RFC 822 [7]). The second format is in common use, but it's based on the obsolete RFC 850 [10] date format and doesn't have a four-digit year, which is very much a vibe check. 🥀 HTTP/1.0 clients and servers that parse the date value SHOULD accept all three formats, though they MUST NOT generate the third (asctime) format. Read that twice, bestie. 👑
Note: Recipients of date values are encouraged to be robust in accepting date values that may have been generated by non-HTTP applications, as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 📬
All HTTP/1.0 date/time stamps MUST be represented in Universal Time (UT), also known as Greenwich Mean Time (GMT), without exception. ⭐ The first two formats show this with "GMT" as the three-letter time zone abbreviation, and the asctime format SHOULD be assumed to be GMT when you're reading it. 🌍
Here's the grammar for the whole date situation:
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"Note: HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers are NOT REQUIRED to use these formats for user presentation, request logging, etc. 📝
3.4. Character Sets 🔤
HTTP uses the same definition of "character set" as MIME, so the whole ecosystem stays on the same page. 🫶
The term "character set" is used in this document to refer to a method used with one or more tables to convert a sequence of octets into a sequence of characters. Note that unconditional conversion in the other direction is not required, in that not all characters may be available in a given character set and a character set may provide more than one sequence of octets to represent a particular character. This definition is intended to allow various kinds of character encodings, from simple single-table mappings such as US-ASCII to complex table switching methods such as those that use ISO 2022's techniques. However, the definition associated with a MIME character set name must fully specify the mapping to be performed from octets to characters. In particular, use of external profiling information to determine the exact mapping is not permitted.
Note: This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME share the same registry, it is important that the terminology also be shared. 🤓
HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character Set registry [15]. However, that registry doesn't define a single, consistent token for each character set, so we define the preferred names here for the character sets most likely to be used with HTTP entities. These include the ones registered by RFC 1521 [5] (the US-ASCII [17] and ISO-8859 [18] character sets) plus other names specifically recommended for use within MIME charset parameters. 🌸
charset = "US-ASCII"
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
| tokenAlthough HTTP lets an arbitrary token be used as a charset value, any token that has a predefined value in the IANA Character Set registry [15] MUST represent the character set defined by that registry. Applications SHOULD limit their use of character sets to the ones defined by the IANA registry. Stay in your lane, babes. 💅
The character set of an entity body SHOULD be labelled as the lowest common denominator of the character codes used within that body, with the exception that no label is preferred over the labels US-ASCII or ISO-8859-1. 🎀
3.5. Content Codings 🎁
Content coding values indicate an encoding transformation that has been applied to a resource. They're mainly used to let a document be compressed or encrypted without losing the identity of its underlying media type. Typically the resource is stored in this encoding and only decoded right before rendering or similar usage. 🍓
content-coding = "x-gzip" | "x-compress" | tokenNote: For future compatibility, HTTP/1.0 applications SHOULD consider "gzip" and "compress" to be equivalent to "x-gzip" and "x-compress", respectively. 🔮
All content-coding values are case-insensitive. HTTP/1.0 uses content-coding values in the Content-Encoding (Section 10.3) header field. The value describes the content-coding, but what matters more is that it tells you what decoding mechanism will be required to remove the encoding. A single program may be capable of decoding multiple content-coding formats, which is very efficient of it. ✨ Two values are defined by this specification:
x-gzip: An encoding format produced by the file compression program "gzip" (GNU zip) developed by Jean-loup Gailly. This format is typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC. 🧃x-compress: The encoding format produced by the file compression program "compress". This format is an adaptive Lempel-Ziv-Welch coding (LZW). 🌀
Note: Use of program names for the identification of encoding formats is not desirable and SHOULD be discouraged for future encodings. Their use here is representative of historical practice, not good design. 🙃
3.6. Media Types 🎨
HTTP uses Internet Media Types [13] in the Content-Type header field (Section 10.5) to provide open and extensible data typing. Main character energy for data. 💖
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = tokenParameters can follow the type/subtype as attribute/value pairs:
parameter = attribute "=" value
attribute = token
value = token | quoted-stringThe type, subtype, and parameter attribute names are case-insensitive. Parameter values may or may not be case-sensitive, depending on the semantics of the parameter name. LWS MUST NOT be generated between the type and subtype, nor between an attribute and its value. 🚫 When a user agent gets a media type with a parameter it doesn't recognize, it SHOULD treat the media type as if that unrecognized parameter and its value were never there. 🫠
Some older HTTP applications don't recognize media type parameters at all. HTTP/1.0 applications SHOULD only use media type parameters when they're necessary to define the content of a message. Don't add extras just because you can, bestie. 🧹
Media-type values are registered with the Internet Assigned Number Authority (IANA [15]), and the registration process is outlined in RFC 1590 [13]. Use of non-registered media types is discouraged. 🙅♀️ Registered types only, the way it's meant to be. 🌈✨
3.6.1 Canonicalization and Text Defaults 🎀
okay so internet media types get registered with a canonical form 💅 In general, an Entity-Body sent over HTTP MUST be represented in the right canonical form before it gets sent. If the body has been run through a Content-Encoding, the underlying data SHOULD be in canonical form before it gets encoded. that's the order of operations, bestie 🧠
Media subtypes of the "text" type use CRLF as the line break when they're in canonical form. ngl HTTP is lowkey flexible here, though. It lets text media use plain CR or plain LF on its own as a line break, as long as it's consistent within the Entity-Body. And HTTP applications MUST accept CRLF, bare CR, and bare LF as line breaks in text media they receive via HTTP. the flexibility is giving main character energy 🦋
In addition, if the text media uses a character set that doesn't use octets 13 and 10 for CR and LF (like some multi-byte character sets), HTTP lets you use whatever octet sequences that character set defines as the equivalent of CR and LF for line breaks. this flexibility only applies to text media in the Entity-Body. A bare CR or LF SHOULD NOT be substituted for CRLF inside any of the HTTP control structures (like header fields and multipart boundaries) 🙅♀️
The charset parameter is used with some media types to define the character set (Section 3.4) of the data. When the sender doesn't give an explicit charset parameter, media subtypes of the text type are defined to have a default charset value of ISO-8859-1 when received via HTTP. Data in character sets other than ISO-8859-1 or its subsets MUST be labelled with an appropriate charset value so the recipient can interpret it consistently 🧾
Note: Many current HTTP servers provide data using charsets other thanISO-8859-1without proper labelling. This situation reduces interoperability and is NOT RECOMMENDED. To compensate for this, some HTTP user agents provide a configuration option to allow the user to change the default interpretation of the media type character set when nocharsetparameter is given. 🙈
3.6.2 Multipart Types 💜
MIME provides a bunch of "multipart" types, which are basically encapsulations of several entities packed into a single message's Entity-Body 📦 The multipart types IANA has registered [15] don't have any special meaning for HTTP/1.0. user agents may need to understand each type, though, so they can figure out what each body-part is for. An HTTP user agent SHOULD follow the same or similar behavior as a MIME user agent does when it receives a multipart type. HTTP servers SHOULD NOT assume that every HTTP client can handle multipart types 🤷♀️
All multipart types share a common syntax and MUST include a boundary parameter as part of the media type value. The message body is itself a protocol element, so it MUST use only CRLF to represent line breaks between body-parts. Multipart body-parts MAY contain HTTP header fields which are significant to the meaning of that part 🎀
3.7 Product Tokens 🏷️
Product tokens let communicating applications identify themselves with a simple product token, plus an optional slash and version designator ✨ Most fields that use product tokens also allow subproducts (the parts that make up a big chunk of the application) to be listed, separated by whitespace. By convention, the products are listed in order of how significant they are for identifying the application.
product = token ["/" product-version]
product-version = tokenExamples:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4Product tokens SHOULD be short and to the point. using them for advertizing or other non-essential information is explicitly forbidden, so don't even 🙅♀️ Although any token character MAY appear in a product-version, this token SHOULD only be used for a version identifier. (i.e., successive versions of the same product SHOULD only differ in the product-version portion of the product value.) it's all about keeping it clean 🧼
4. HTTP Message ✨
4.1 Message Types 💬
HTTP messages consist of requests from client to server and responses from server to client. Here's the big picture 👑
HTTP-message = Simple-Request ; HTTP/0.9 messages
| Simple-Response
| Full-Request ; HTTP/1.0 messages
| Full-ResponseFull-Request and Full-Response use the generic message format of RFC 822 [7] for transferring entities. Both messages MAY include optional header fields (also known as "headers") and an entity body. The entity body is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF) 🫶
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2Simple-Request and Simple-Response are the minimalist ones 🌸 they don't allow any header information, and Simple-Request is limited to a single request method (GET).
Simple-Request = "GET" SP Request-URI CRLF
Simple-Response = [ Entity-Body ]Use of the Simple-Request format is discouraged, because it stops the server from identifying the media type of the returned entity 🙈
4.2 Message Headers 🧾
HTTP header fields (General-Header (Section 4.3), Request-Header (Section 5.2), Response-Header (Section 6.2), and Entity-Header (Section 7.1) fields) follow the same generic format as the one given in Section 3.1 of RFC 822 [7]. Each header field is a name followed immediately by a colon (":"), a single space (SP) character, and the field value. Field names are case-insensitive. Header fields can be extended over multiple lines by starting each extra line with at least one SP or HT, though this is NOT RECOMMENDED 💅
HTTP-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>The order in which header fields are received doesn't matter ✨ However, it is "good practice" to send General-Header fields first, followed by Request-Header or Response-Header fields, and then the Entity-Header fields 🎀
Multiple HTTP-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. bestie that's the merge trick 🦋
4.3 General Header Fields 🌈
There are a few header fields with general applicability for both request and response messages, but they don't apply to the entity being transferred. These headers apply only to the message being transmitted 🫧
General-Header = Date ; Section 10.6
| Pragma ; Section 10.12General header field names can only be extended reliably together with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of general header fields if all parties in the communication recognize them as general header fields. Unrecognized header fields are treated as Entity-Header fields 👀
5. Request 🎀
A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use. For backwards compatibility with the more limited HTTP/0.9 protocol, there are two valid formats for an HTTP request 🔥
Request = Simple-Request | Full-Request
Simple-Request = "GET" SP Request-URI CRLF
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2If an HTTP/1.0 server receives a Simple-Request, it MUST respond with an HTTP/0.9 Simple-Response. An HTTP/1.0 client that's capable of receiving a Full-Response SHOULD never generate a Simple-Request 🙅♀️
5.1 Request-Line 🧚
The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and it ends with CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence 🍓
Request-Line = Method SP Request-URI SP HTTP-Version CRLFNote that the difference between a Simple-Request and the Request-Line of a Full-Request is the presence of the HTTP-Version field and the availability of methods other than GET 💖
5.1.1 Method 🦋
The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive 🌸
Method = "GET" ; Section 8.1
| "HEAD" ; Section 8.2
| "POST" ; Section 8.3
| extension-method
extension-method = tokenThe list of methods acceptable for a specific resource can change dynamically. The client is notified through the return code of the response if a method isn't allowed on a resource. Servers SHOULD return the status code 501 (not implemented) if the method is unrecognized or not implemented 💀
The methods commonly used by HTTP/1.0 applications are fully defined in Section 8 ✨
5.1.2. Request-URI ✨
okay so the Request-URI is a Uniform Resource Identifier (Section 3.2), and it tells the server exactly which resource the request is about 🎯 It's giving "this is the one, bestie" energy.
Request-URI = absoluteURI | abs_pathThere are two options for the Request-URI, and which one you get depends on what kind of request you're sending 🦋
The absoluteURI form is ONLY allowed when the request is being made to a proxy. The proxy is asked to forward the request and send back the response 💌 If the request is GET or HEAD and a prior response is cached, the proxy MAY use the cached message, as long as it passes any restrictions in the Expires header field. Note that the proxy MAY forward the request on to another proxy, or directly to the server named in the absoluteURI. To avoid request loops, a proxy MUST be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address 🔁 An example Request-Line would be:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0The most common form of Request-URI is the one used to identify a resource on an origin server or gateway 👑 In this case, only the absolute path of the URI is sent (see Section 3.2.1, abs_path). For example, a client that wants to grab the resource above straight from the origin server would open a TCP connection to port 80 of the host "www.w3.org" and send the line:
GET /pub/WWW/TheProject.html HTTP/1.0...followed by the rest of the Full-Request. Note that the absolute path cannot be empty. If there isn't one in the original URI, it MUST be given as "/" (the server root) 🌈
the absolute path can never be empty, so if the URI has no path, you still send "/" 🙈
The Request-URI is sent as an encoded string, where some characters MAY be escaped using the % HEX HEX encoding defined by RFC 1738 [4]. The origin server MUST decode the Request-URI in order to properly interpret the request 🧚
5.2. Request Header Fields
okay now the request header fields are how the client passes extra info about the request, and about itself, over to the server 💖 They act as request modifiers, kinda like the parameters you'd pass into a method (procedure) call in a programming language 💅
Request-Header = Authorization ; Section 10.2
| From ; Section 10.8
| If-Modified-Since ; Section 10.9
| Referer ; Section 10.13
| User-Agent ; Section 10.15Request-Header field names can only be extended reliably together with a change in the protocol version 🔒 However, new or experimental header fields MAY be given the semantics of request header fields, as long as all parties in the communication recognize them as request header fields 🫶 Unrecognized header fields are treated as Entity-Header fields.
6. Response 🌸
After receiving and interpreting a request message, a server responds with an HTTP response message 📬
Response = Simple-Response | Full-Response
Simple-Response = [ Entity-Body ]
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2A Simple-Response SHOULD only be sent in response to an HTTP/0.9 Simple-Request, or if the server only supports the more limited HTTP/0.9 protocol 🍓 If a client sends an HTTP/1.0 Full-Request and gets a response that does not begin with a Status-Line, it SHOULD assume that the response is a Simple-Response and parse it accordingly. Note that the Simple-Response is just the entity body, and it ends when the server closes the connection 🔚
6.1. Status-Line
The first line of a Full-Response message is the Status-Line 🚦 It has the protocol version, then a numeric status code and its textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLFA status line always starts with the protocol version and the status code, like this:
"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP(e.g., "HTTP/1.0 200 "), so spotting that pattern is enough to tell a Full-Response apart from a Simple-Response 🕵️♀️ Even though the Simple-Response format MAY allow such an expression at the start of an entity body, and that could cause a misinterpretation if it was sent in response to a Full-Request, most HTTP/0.9 servers are limited to responses of type "text/html", so they would never generate such a response 🙈
6.1.1. Status Code and Reason Phrase
The Status-Code is a 3-digit integer result code for how the attempt to understand and satisfy the request went 🎀 The Reason-Phrase is a short textual description of the Status-Code. The Status-Code is meant for automata, and the Reason-Phrase is meant for the human user. The client is not REQUIRED to examine or display the Reason-Phrase 💜
The first digit of the Status-Code defines the class of response. The last two digits don't have any categorization role. There are 5 values for the first digit:
1xx: Informational - Not used, but reserved for future use2xx: Success - The action was successfully received, understood, and accepted.3xx: Redirection - Further action must be taken in order to complete the request4xx: Client Error - The request contains bad syntax or cannot be fulfilled5xx: Server Error - The server failed to fulfill an apparently valid request
The individual values of the numeric status codes defined for HTTP/1.0, plus an example set of matching Reason-Phrases, are shown below. The reason phrases listed here are only RECOMMENDED. They MAY be replaced by local equivalents without affecting the protocol 🌷 These codes are fully defined in Section 9.
Status-Code = "200" ; OK
| "201" ; Created
| "202" ; Accepted
| "204" ; No Content
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "304" ; Not Modified
| "400" ; Bad Request
| "401" ; Unauthorized
| "403" ; Forbidden
| "404" ; Not Found
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>HTTP status codes are extensible, but the codes above are the only ones generally recognized in current practice ✨ HTTP applications are not REQUIRED to understand the meaning of every registered status code, though that understanding is obviously desirable 💅 However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as equivalent to the x00 status code of that class. The one exception is that an unrecognized response MUST NOT be cached 🚫
For example, if an unrecognized status code of 431 comes back to the client, it can safely assume there was something wrong with its request, and treat the response as if it had received a 400 status code 🍭 In cases like this, user agents SHOULD present the user with the entity returned with the response, since that entity is likely to include human-readable info explaining the unusual status 🧠
6.2. Response Header Fields
The response header fields let the server pass extra info about the response that can't fit in the Status-Line 🎁 These header fields tell you about the server, and about further access to the resource identified by the Request-URI.
Response-Header = Location ; Section 10.11
| Server ; Section 10.14
| WWW-Authenticate ; Section 10.16Response-Header field names can only be extended reliably together with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of response header fields, as long as all parties in the communication recognize them as response header fields 🦋 Unrecognized header fields are treated as Entity-Header fields.
7. Entity 🧁
Full-Request and Full-Response messages MAY transfer an entity within some requests and responses 📦 An entity is made up of Entity-Header fields and (usually) an Entity-Body. In this section, "sender" and "recipient" both refer to either the client or the server, depending on who's sending and who's receiving the entity.
7.1. Entity Header Fields
Entity-Header fields define optional metainformation about the Entity-Body or, if no body is present, about the resource identified by the request 🏷️
Entity-Header = Allow ; Section 10.1
| Content-Encoding ; Section 10.3
| Content-Length ; Section 10.4
| Content-Type ; Section 10.5
| Expires ; Section 10.7
| Last-Modified ; Section 10.10
| extension-header
extension-header = HTTP-headerThe extension-header mechanism lets you define extra Entity-Header fields without changing the protocol, but those fields can't be assumed to be recognizable by the recipient 🤷♀️ Unrecognized header fields SHOULD be ignored by the recipient and forwarded by proxies.
7.2. Entity Body
The entity body (if there is one) sent with an HTTP request or response is in a format and encoding defined by the Entity-Header fields 🍰
Entity-Body = *OCTETAn entity body is only included with a request message when the request method calls for one. The presence of an entity body in a request is signaled by including a Content-Length header field in the request message headers. HTTP/1.0 requests containing an entity body MUST include a valid Content-Length header field 📏
For response messages, whether or not an entity body is included depends on both the request method and the response code 🌈 All responses to the HEAD request method MUST NOT include a body, even though the presence of entity header fields might make you think they do 👀 All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a body. All other responses MUST include an entity body or a Content-Length header field defined with a value of zero (0) 💖
7.2.1. Type ✨
okay so when an Entity-Body rides along with a message, its data type is worked out from two header fields, Content-Type and Content-Encoding. Together they make a two-layer, ordered encoding model 🎀, kinda like a parfait 🍓:
entity-body := Content-Encoding( Content-Type( data ) )A Content-Type tells you the media type of the underlying data 💅. A Content-Encoding MAY be used to show any extra content coding applied to that type, usually for data compression, and it's a property of the resource being requested. The default for content encoding is none, aka the identity function (i.e., the identity function) 🙈.
Any HTTP/1.0 message containing an entity body SHOULD include a Content-Type header field that defines the media type of that body 🫶. If and only if the media type is not given by a Content-Type header, as is the case for Simple-Response messages, the recipient MAY attempt to guess it by looking at the content and/or the name extension(s) of the URL used to identify the resource 🔍. If the media type is still unknown, the recipient SHOULD treat it as type "application/octet-stream" 🌸.
7.2.2. Length 📏
When an Entity-Body shows up with a message, its length MAY be figured out in one of two ways ✨. If a Content-Length header field is present, its value in bytes is the length of the Entity-Body. Otherwise, the body length is determined by the server closing the connection 💀.
Closing the connection can't mark the end of a request body, because then the server has no way to send back a response 😭. So HTTP/1.0 requests containing an entity body MUST include a valid Content-Length header field 🎀. If a request has an entity body but no Content-Length, and the server doesn't recognize or can't calculate the length from other fields, then the server SHOULD send a 400 (bad request) response 🙅♀️.
Note: some older servers send an invalidContent-Lengthwhen they're serving a document with server-side includes that get dynamically inserted into the data stream. It MUST be emphasized that this will not be tolerated by future versions of HTTP 🚫. Unless the client knows it's getting a response from a compliant server, it SHOULD NOT depend on theContent-Lengthvalue being correct 🥲.
8. Method Definitions 💅
Here's the set of common methods for HTTP/1.0 🫶. The list can grow, BUT you can't just assume extra methods mean the same thing for clients and servers that were extended separately 🙃.
8.1. GET 🔍
The GET method means "retrieve whatever information (in the form of an entity) is identified by the Request-URI" 💖. If the Request-URI points at a data-producing process, the produced data is what SHALL be returned as the entity in the response, not the source text of the process 🧠, unless that text just happens to be the output of the process 💅.
The GET method turns into a "conditional GET" when the request message includes an If-Modified-Since header field 🦋. A conditional GET asks for the identified resource to be transferred only if it's been modified since the date in the If-Modified-Since header, as described in Section 10.9 ✨. It's a whole network-saver, bestie, because cached entities can get refreshed without a pile of requests or unnecessary data 🌈.
8.2. HEAD 🧚
The HEAD method is identical to GET, except that the server MUST NOT return any Entity-Body in the response 🚫. The metainformation in the HTTP headers of a HEAD response SHOULD be identical to what gets sent for a GET request 👑. It's used to get metainformation about the resource identified by the Request-URI without transferring the Entity-Body itself 🍓. It's super popular for checking hypertext links for validity, accessibility, and recent modification 💜.
There is no "conditional HEAD" request, since it's not analogous to the conditional GET 🙈. If an If-Modified-Since header field shows up with a HEAD request, it SHOULD be ignored 🫠.
8.3. POST 📮
The POST method asks the destination server to accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line 💌. POST is built to be a uniform method that covers these functions:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
- Providing a block of data, such as the result of submitting a form [3], to a data-handling process;
- Extending a database through an append operation.
The server decides what POST actually does, and it usually depends on the Request-URI 🧩. The posted entity is subordinate to that URI the same way a file is subordinate to the directory holding it, a news article is subordinate to the newsgroup it's posted to, or a record is subordinate to a database 🗂️.
A successful POST doesn't need the entity to be created as a resource on the origin server or made accessible for future reference 🤷♀️. So the action from a POST might not produce a resource that you can identify with a URI 🫠. In that case, either 200 (ok) or 204 (no content) is the appropriate response status, depending on whether the response includes an entity describing the result 🎀.
If a resource has been created on the origin server, the response SHOULD be 201 (created) and contain an entity (preferably of type "text/html") that describes the status of the request and refers to the new resource 🌸.
A valid Content-Length is REQUIRED on all HTTP/1.0 POST requests 📏. An HTTP/1.0 server SHOULD respond with a 400 (bad request) message if it can't determine the length of the request message's content 💀.
Applications MUST NOT cache responses to a POST request 🚫. The reason is that the application has no way of knowing whether the server would return an equivalent response on some future request 🤔.
9. Status Code Definitions 🌈
Each Status-Code gets described below, including which method(s) it can follow and any metainformation REQUIRED in the response 📋.
9.1. Informational 1xx 🌙
This class of status code is a provisional response. It's just the Status-Line plus optional headers, and it ends with an empty line ✨. HTTP/1.0 doesn't define any 1xx status codes, and they're not a valid response to an HTTP/1.0 request 🙅♀️. Still, they MAY be useful for experimental applications that are outside the scope of this specification 🧪.
9.2. Successful 2xx ✅
This class of status code means the client's request was successfully received, understood, and accepted 🥳.
200 OK 💖
The request has succeeded 🎉. What comes back depends on the method used in the request:
GETan entity corresponding to the requested resource is sent in the response;HEADthe response MUST only contain the header information and no Entity-Body;POSTan entity describing or containing the result of the action.
201 Created 🎀
The request was fulfilled and resulted in a brand-new resource being created 👶. The new resource can be referenced by the URI(s) returned in the entity of the response 🔗. The origin server SHOULD create the resource before using this Status-Code 🛠️. If the action can't be carried out right away, the server MUST include a description in the response body of when the resource will be available 📅. Otherwise, the server SHOULD respond with 202 (accepted) ⏳.
Of the methods defined by this specification, only POST can create a resource 👑.
202 Accepted 🦋
The request has been accepted for processing, but the processing isn't finished yet 🧁. The request MAY or MAY NOT eventually be acted upon, since it MAY be disallowed when processing actually happens 🌀. There's no facility for re-sending a status code from an asynchronous operation like this 🙈.
The 202 response is intentionally non-committal 🫶. Its whole purpose is to let a server accept a request for some other process (maybe a batch job that only runs once a day) without making the user agent's connection stay open until that process finishes 🌙. The entity returned with this response SHOULD include an indication of the request's current status, plus either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled ⏰.
204 No Content 🍃
The server has fulfilled the request, but there's no new information to send back 🫧. If the client is a user agent, it SHOULD NOT change its document view from the one that caused the request to be generated 🙅♀️. This response is mainly there so input for scripts or other actions can happen without changing the user agent's active document view 💅. The response MAY include new metainformation in the form of entity headers, which SHOULD apply to the document currently in the user agent's active view 💜.
9.3. Redirection 3xx 🦋
okay so the 3xx class is basically the server going "not here bestie, try over there" 💅 This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The user agent can do that step without bugging the user 🙈 if and only if the method used in the subsequent request is GET or HEAD. And a user agent should never automatically redirect a request more than 5 times, since that many bounces usually means it's stuck in an infinite loop 🌀
300 Multiple Choices 🌸
this one isn't directly used by HTTP/1.0 apps 🧚 but it's the default way to read the whole 3xx family.
The requested resource is available at one or more locations. Unless it was a HEAD request, the response should include an entity containing a list of resource characteristics and locations from which the user or user agent can choose the one most appropriate. If the server has a preferred choice, it should include the URL in a Location field; user agents may use this field value for automatic redirection.
301 Moved Permanently 🍓
the resource got a brand new permanent URL, so every future reference should use that URL instead 💖 Clients with link editing capabilities should automatically relink references to the Request-URI to the new reference returned by the server, where possible.
The new URL must be given by the Location field in the response. Unless it was a HEAD request, the Entity-Body of the response should contain a short note with a hyperlink to the new URL.
If the 301 status code is received in response to a request using the POST method, 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. 🙅♀️
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing user agents will erroneously change it into a GET request. 😭
302 Moved Temporarily 🦋
the resource is only living somewhere else for now ⭐ The requested resource resides temporarily under a different URL. Since the redirection may be altered on occasion, the client should continue to use the Request-URI for future requests.
The URL must be given by the Location field in the response. Unless it was a HEAD request, the Entity-Body of the response should contain a short note with a hyperlink to the new URI(s).
If the 302 status code is received in response to a request using the POST method, 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. 🙅♀️
Note: When automatically redirecting a POST request after receiving a 302 status code, some existing user agents will erroneously change it into a GET request. 😭
304 Not Modified 💜
this one is so iconic for caching ✨ If the client has performed a conditional GET request and access is allowed, but the document has not been modified since the date and time specified in the If-Modified-Since field, the server must respond with this status code and not send an Entity-Body to the client. Header fields contained in the response should only include information which is relevant to cache managers or which may have changed independently of the entity's Last-Modified date. Examples of relevant header fields include: Date, Server, and Expires. A cache should update its cached entity to reflect any new field values given in the 304 response. 🫶
9.4. Client Error 4xx 🙈
the 4xx class is for when the client seems to have erred, bestie 💅 If the client has not completed the request when a 4xx code is received, it should immediately cease sending data to the server. 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.
Note: If the client is sending data, server implementations on TCP should be careful to ensure that the client acknowledges receipt of the packet(s) containing the response prior to closing the input connection. If the client continues sending data to the server after the close, the server's controller will send a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted by the HTTP application. 😱
400 Bad Request 🙃
the server couldn't understand the request because the syntax is malformed. The client should not repeat the request without modifications.
401 Unauthorized 🔐
the request needs user authentication 🗝️ The request requires user authentication. The response must include a WWW-Authenticate header field (Section 10.16) containing a challenge applicable to the requested resource. The client may repeat the request with a suitable Authorization header field (Section 10.2). 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 may include relevant diagnostic information. HTTP access authentication is explained in Section 11.
403 Forbidden 🚫
the server totally understood the request, but it's refusing to do it 🙅♀️ 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 body. 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.
404 Not Found 🔍
the server hasn't found anything matching the Request-URI 🫥 No indication is given of whether the condition is temporary or permanent. If the server does not wish to make this information available to the client, the status code 403 (forbidden) can be used instead.
9.5. Server Error 5xx 💥
5xx is when the server knows it messed up or just can't do the request 😩 Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. If the client has not completed the request when a 5xx code is received, it should immediately cease sending data to the server. 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 response codes are applicable to any request method and there are no required header fields.
500 Internal Server Error 🔥
the server hit an unexpected condition that stopped it from fulfilling the request. The server encountered an unexpected condition which prevented it from fulfilling the request.
501 Not Implemented 🛠️
the server doesn't support the functionality the request needs. 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.
502 Bad Gateway 🌉
the proxy or gateway got a bad response from the upstream server it reached out to. 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.
503 Service Unavailable 🧯
the server can't handle the request right now because it's overloaded or under maintenance ⏳ 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.
Note: 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. 🙈
10. Header Field Definitions ✨
this section spells out the syntax and semantics of all the commonly used HTTP/1.0 header fields 📜 This section defines the syntax and semantics of all commonly used HTTP/1.0 header fields. For general and entity header fields, both sender and recipient refer to either the client or the server, depending on who sends and who receives the message.
10.1. Allow 🌈
the Allow entity-header field lists the methods the resource at the Request-URI supports 🦋 The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. The Allow header field is not permitted in a request using the POST method, and thus should be ignored if it is received as part of a POST entity.
Allow = "Allow" ":" 1#methodExample of use:
Allow: GET, HEADThis field cannot prevent a client from trying other methods. However, the indications given by the Allow header field value should be followed. The actual set of allowed methods is defined by the origin server at the time of each request.
A proxy must not modify the Allow header field even if it does not understand all the methods specified, since the user agent may have other means of communicating with the origin server. 🫶
The Allow header field does not indicate what methods are implemented by the server.
10.2. Authorization 🔑
a user agent that wants to prove who it is to a server can do that by adding an Authorization request-header field 🪪 A user agent that wishes to authenticate itself with a server--usually, but not necessarily, after receiving a 401 response--may do so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
Authorization = "Authorization" ":" credentialsHTTP access authentication is described in Section 11. If a request is authenticated and a realm specified, the same credentials should be valid for all other requests within this realm.
Responses to requests containing an Authorization field are not cachable. 🙊
10.3. Content-Encoding 🗜️
the Content-Encoding entity-header field is like a modifier on the media-type ✨ The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content coding has been applied to the resource, and thus what decoding mechanism must be applied in order to obtain the media-type referenced by the Content-Type header field. The Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type.
Content-Encoding = "Content-Encoding" ":" content-codingContent codings are defined in Section 3.5. An example of its use is
Content-Encoding: x-gzipThe Content-Encoding is a characteristic of the resource identified by the Request-URI. Typically, the resource is stored with this encoding and is only decoded before rendering or analogous usage. so the file stays compressed and gets decoded right before it's shown 🎀
10.4. Content-Length 📦
Okay bestie, so Content-Length is the entity-header that tells the recipient how big the Entity-Body is, counted in decimal number of octets 🔢. And if the request was a HEAD, it tells you the size the Entity-Body would've been if it had been a GET 🙈
Content-Length = "Content-Length" ":" 1*DIGITAn example is
Content-Length: 3495Applications SHOULD use this field to indicate the size of the Entity-Body to be transferred, regardless of the media type of the entity. 💖 A valid Content-Length field value is REQUIRED on all HTTP/1.0 request messages containing an entity body. Not optional, periodt 💅
Any Content-Length greater than or equal to zero is a valid value ✨ Section 7.2.2 explains how to figure out the length of a response entity body if a Content-Length isn't given.
Note: The meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional field used within the "message/external-body" content-type. In HTTP, it SHOULD be used whenever the entity's length can be determined prior to being transferred. 🫶
10.5. Content-Type 🎀
The Content-Type entity-header field tells the recipient the media type of the Entity-Body 🧾 or, for a HEAD, the media type that would've been sent had the request been a GET. Main character energy for metadata 👑
Content-Type = "Content-Type" ":" media-typeMedia types are defined in Section 3.6. An example of the field is
Content-Type: text/htmlIf you want more tea on ways to identify the media type of an entity, check Section 7.2.1 🦋
10.6. Date 🕰️
The Date general-header field is the date and time the message was originated 🍓 It has the same semantics as orig-date in RFC 822. The field value is an HTTP-date, as described in Section 3.3.
Date = "Date" ":" HTTP-dateAn example is
Date: Tue, 15 Nov 1994 08:12:31 GMTSo if a message comes straight from the user agent (for requests) or the origin server (for responses), the receiver can assume the date is basically "now" 🙌 But the date matters a lot for judging cached responses, so origin servers SHOULD always include a Date header 💜 Clients SHOULD only send a Date header field in messages that include an entity body, like a POST request, and even then it is OPTIONAL ✨ A received message with no Date header field SHOULD get one assigned by the recipient if that recipient is going to cache it or gateway it over a protocol that needs a Date.
In theory, the date SHOULD represent the moment just before the entity is generated ⏳ In practice, the date can be generated at any time during the message origination without messing up its semantic value 🌈
Note: An earlier version of this document incorrectly specified that this field should contain the creation date of the enclosed Entity-Body. This has been changed to reflect actual (and proper) usage. 🙈
10.7. Expires ⏰
The Expires entity-header field gives the date/time after which the entity should be considered stale 💀 It lets information providers hint how volatile a resource is, or a date after which the info might not be valid anymore. Applications MUST NOT cache this entity beyond the date given, no exceptions 🚫
Having an Expires field does not mean the original resource will change or disappear at, before, or after that time 🧚 But if an information provider knows, or even suspects, that a resource will change by a certain date, they SHOULD include an Expires header with that date. The format is an absolute date and time as defined by HTTP-date in Section 3.3.
Expires = "Expires" ":" HTTP-dateAn example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMTIf the date given is equal to or earlier than the value of the Date header, the recipient MUST NOT cache the enclosed entity 🛑 If a resource is dynamic by nature, like lots of data-producing processes, its entities SHOULD be given an appropriate Expires value that reflects that dynamism 🌸
The Expires field CANNOT be used to force a user agent to refresh its display or reload a resource, because its semantics only apply to caching mechanisms. Those mechanisms only need to check a resource's expiration status when a new request for that resource starts 🔄
User agents often have history mechanisms, like "Back" buttons and history lists, that can redisplay an entity retrieved earlier in a session 🔙 By default, the Expires field does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents ✨
Note: Applications are encouraged to be tolerant of bad or misinformed implementations of the Expires header. A value of zero (0) or an invalid date format SHOULD be considered equivalent to an "expires immediately." Although these values are not legitimate for HTTP/1.0, a robust implementation is always desirable. 💅
10.8. From 💌
The From request-header field, if given, SHOULD contain an Internet e-mail address for the human user who controls the requesting user agent 👩💻 The address SHOULD be machine-usable, as defined by mailbox in RFC 822 [7] (as updated by RFC 1123 [6]):
From = "From" ":" mailboxAn example is:
From: webmaster@w3.orgThis header field may be used for logging purposes and as a way to spot the source of invalid or unwanted requests 🕵️♀️ It SHOULD NOT be used as an insecure form of access protection, bestie, don't do that 🙅♀️ The interpretation is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. Robot agents SHOULD include this header so the person running the robot can be contacted if problems occur on the receiving end 🤖💖
The Internet e-mail address in this field may be separate from the Internet host that issued the request. For example, when a request goes through a proxy, the original issuer's address SHOULD be used 🦋
Note: The client SHOULD NOT send the From header field without the user's approval, as it may conflict with the user's privacy interests or their site's security policy. It is strongly RECOMMENDED that the user be able to disable, enable, and modify the value of this field at any time prior to a request. 🔐🫶
10.9. If-Modified-Since 🗓️
The If-Modified-Since request-header field is used with the GET method to make it conditional 🧠 If the requested resource hasn't been modified since the time in this field, a copy of the resource won't be sent back from the server. Instead, you get a 304 (not modified) response with no Entity-Body 😌
If-Modified-Since = "If-Modified-Since" ":" HTTP-dateAn example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMTA conditional GET asks for the identified resource only if it's been modified since the date in the If-Modified-Since header 🎯 The algorithm for deciding this has these cases:
- a) If the request would normally give anything other than a 200 (ok) status, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a normal GET. A date that is later than the server's current time is invalid. 🙃
- b) If the resource has been modified since the If-Modified-Since date, the response is exactly the same as for a normal GET. 🔁
- c) If the resource has not been modified since a valid If-Modified-Since date, the server SHALL return a 304 (not modified) response. ✅
The whole point of this feature is letting caches update efficiently with a minimum amount of transaction overhead 🚀
10.10. Last-Modified 🗂️
The Last-Modified entity-header field indicates the date and time the sender believes the resource was last modified 🕐 Its exact meaning is defined by how the recipient should interpret it: if the recipient has a copy of this resource that's older than the date in the Last-Modified field, that copy SHOULD be considered stale 🥀
Last-Modified = "Last-Modified" ":" HTTP-dateAn example of its use is
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMTThe exact meaning of this header depends on the sender's implementation and the nature of the original resource 🧩 For files, it may just be the file system last-modified time 📁 For entities with dynamically included parts, it may be the most recent of the last-modify times for its component parts 🧃 For database gateways, it may be the last-update timestamp of the record 🗃️ For virtual objects, it may be the last time the internal state changed 🌀
An origin server MUST NOT send a Last-Modified date that's later than the server's time of message origination 🚫 In cases where the resource's last modification would point to some time in the future, the server MUST replace that date with the message origination date 🔧
10.11. Location 📍
The Location response-header field defines the exact location of the resource that was identified by the Request-URI 🗺️ For 3xx responses, the location MUST indicate the server's preferred URL for automatic redirection to the resource. Only one absolute URL is allowed, so pick wisely ✨
Location = "Location" ":" absoluteURIAn example is
Location: http://www.w3.org/hypertext/WWW/NewLocation.html10.12. Pragma 🧁
The Pragma general-header field is used to include implementation-specific directives that may apply to any recipient along the request/response chain 🔗 All pragma directives specify optional behavior from the viewpoint of the protocol, but some systems may require that behavior be consistent with the directives 🎀
Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" word ]When the "no-cache" directive is present in a request message, an application SHOULD forward the request toward the origin server, even if it has a cached copy of what's being requested 🙋♀️ This lets a client insist on getting an authoritative response to its request. It also lets a client refresh a cached copy that's known to be corrupted or stale 🧼
Pragma directives MUST be passed through by a proxy or gateway application, regardless of their significance to that application 💗 since the directives may apply to all recipients along the request/response chain. You can't specify a pragma for one specific recipient, but any pragma directive that isn't relevant to a recipient SHOULD be ignored by that recipient 🌷
10.13. Referer 🔗✨
okay so the Referer request-header field lets the client spill the tea 🫖 to the server about the address (URI) of the resource the Request-URI was obtained from. this is giving server-side bookkeeping 📚: a server can build lists of back-links to resources for interest, logging, optimized caching, etc. 🔍 it also lets obsolete or mistyped links get traced for maintenance, which is honestly so iconic 💅. the Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard ⌨️. no URI, no Referer, periodt 🙅♀️
Referer = "Referer" ":" ( absoluteURI | relativeURI )example time 🎀:
Referer: http://www.w3.org/hypertext/DataSources/Overview.htmlif a partial URI is given, it SHOULD be interpreted relative to the Request-URI 🧭. the URI MUST NOT include a fragment 🙅♀️
Note: because the source of a link may be private information or may reveal an otherwise private information source, it is strongly RECOMMENDED that the user be able to select whether or not the Referer field is sent 🙈. for example, a browser client could have a toggle switch for browsing openly/anonymously 🕶️, which would respectively enable/disable the sending of Referer and From information. privacy main character energy 👑
10.14. Server 🖥️💜
the Server response-header field contains information about the software the origin server used to handle the request 🧚. the field can contain multiple product tokens (Section 3.7) and comments identifying the server and any significant subproducts. by convention, the product tokens are listed in order of their significance for identifying the application 📋
Server = "Server" ":" 1*( product | comment )example:
Server: CERN/3.0 libwww/2.17if the response is being forwarded through a proxy, the proxy application MUST NOT add its data to the product list 🚫
Note: revealing the specific software version of the server may allow the server machine to become more vulnerable to attacks against software that is known to contain security holes 😭. Server implementors are encouraged to make this field a configurable option 🎛️
Note: some existing servers fail to restrict themselves to the product token syntax within the Server field 💀
10.15. User-Agent 🕵️♀️🌸
the User-Agent request-header field contains information about the user agent originating the request 🛰️. it's for statistics 📊, tracing protocol violations, and automated recognition of user agents so responses can be tailored to avoid particular user agent limitations 💅. Although it is NOT REQUIRED, user agents SHOULD include this field with requests 🫶. the field can contain multiple product tokens (Section 3.7) and comments identifying the agent and any subproducts which form a significant part of the user agent. by convention, the product tokens are listed in order of their significance for identifying the application ✨
User-Agent = "User-Agent" ":" 1*( product | comment )example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3Note: some current proxy applications append their product information to the list in the User-Agent field. This is NOT RECOMMENDED, since it makes machine interpretation of these fields ambiguous 🤨
Note: some existing clients fail to restrict themselves to the product token syntax within the User-Agent field 🙈
10.16. WWW-Authenticate 🔑
the WWW-Authenticate response-header field MUST be included in 401 (unauthorized) response messages 🚪. the field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI 🪪
WWW-Authenticate = "WWW-Authenticate" ":" 1#challengethe HTTP access authentication process is described in Section 11 🔐. user agents MUST take special care in parsing the WWW-Authenticate field value if it contains more than one challenge, or if more than one WWW-Authenticate header field is provided 😵💫, since the contents of a challenge may itself contain a comma-separated list of authentication parameters.
11. Access Authentication 🔐🎀
HTTP provides a simple challenge-response authentication mechanism which may be used by a server to challenge a client request, and by a client to provide authentication information 🤝. it uses an extensible, case-insensitive token to identify the authentication scheme, followed by a comma-separated list of attribute-value pairs carrying the parameters needed for authentication via that scheme 🧩
auth-scheme = token
auth-param = token "=" quoted-stringthe 401 (unauthorized) response message is used by an origin server to challenge the authorization of a user agent 🚧. this response MUST include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource.
challenge = auth-scheme 1*SP realm *( "," auth-param )
realm = "realm" "=" realm-value
realm-value = quoted-stringthe realm attribute (case-insensitive) is REQUIRED for all authentication schemes which issue a challenge 🏰. the realm value (case-sensitive), together with the canonical root URL of the server being accessed, defines the protection space. these realms let the protected resources on a server be split into a set of protection spaces, each with its own authentication scheme and/or authorization database 🗂️. the realm value is a string, generally assigned by the origin server, and it may have additional semantics specific to the authentication scheme ✨
a user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--MAY do so by including an Authorization header field with the request 🙋♀️. the Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
credentials = basic-credentials
| ( auth-scheme #auth-param )the domain over which credentials can be automatically applied by a user agent is determined by the protection space 🗺️. if a prior request has been authorized, the same credentials MAY be reused for all other requests within that protection space, for a period of time determined by the authentication scheme, parameters, and/or user preference ⏳. unless otherwise defined by the authentication scheme, a single protection space cannot extend outside the scope of its server 🛑
if the server does not wish to accept the credentials sent with a request, it SHOULD return a 403 (forbidden) response 🙅♀️
the HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication 🌈. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information 🔒. however, these additional mechanisms are not defined by this specification 🫠
Proxies MUST be completely transparent regarding user agent authentication 🪞. that is, they MUST forward the WWW-Authenticate and Authorization headers untouched, and MUST NOT cache the response to a request containing Authorization. HTTP/1.0 does not provide a means for a client to be authenticated with a proxy 🙃
11.1. Basic Authentication Scheme 🧸
the "basic" authentication scheme is based on the model that the user agent MUST authenticate itself with a user-ID and a password for each realm 🔑. the realm value SHOULD be considered an opaque string which can only be compared for equality with other realms on that server 🫙. the server will authorize the request only if it can validate the user-ID and password for the protection space of the Request-URI. there are no optional authentication parameters 🤷♀️
upon receipt of an unauthorized request for a URI within the protection space, the server SHOULD respond with a challenge like the following 📣:
WWW-Authenticate: Basic realm="WallyWorld"where "WallyWorld" is the string assigned by the server to identify the protection space of the Request-URI 🏷️
to receive authorization, the client sends the user-ID and password, separated by a single colon (":") character, within a base64 [5] encoded string in the credentials 🧁.
basic-credentials = "Basic" SP basic-cookie
basic-cookie = <base64 [5] encoding of userid-password,
except not limited to 76 char/line>
userid-password = [ token ] ":" *TEXTif the user agent wants to send the user-ID "Aladdin" and password "open sesame", it would use the following header field 🪄:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==the basic authentication scheme is a non-secure method of filtering unauthorized access to resources on an HTTP server 🚨. it's based on the assumption that the connection between the client and the server can be regarded as a trusted carrier. as this is not generally true on an open network, the basic authentication scheme SHOULD be used accordingly 🫣. in spite of this, clients SHOULD implement the scheme in order to communicate with servers that use it 🤝
12. Security Considerations 🛡️💖
this section is meant to inform application developers, information providers, and users about the security limitations in HTTP/1.0 as described by this document 📖. the discussion does not include definitive solutions to the problems revealed, though it does make some suggestions for reducing security risks 🩹
12.1. Authentication of Clients 🙈
as mentioned in Section 11.1, the Basic authentication scheme is not a secure method of user authentication 😬, nor does it prevent the Entity-Body from being transmitted in clear text across the physical network used as the carrier. HTTP/1.0 does not prevent additional authentication schemes and encryption mechanisms from being employed to increase security 🔐
12.2. Safe Methods 🫧
the writers of client software SHOULD be aware that the software represents the user in their interactions over the Internet, and SHOULD be careful to allow the user to be aware of any actions they may take which may have an unexpected significance to themselves or others 🎭. this is a whole responsibility thing 🫶
in particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval 🙅♀️. these methods SHOULD be considered "safe." this lets user agents represent other methods, such as POST, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested 🚩
naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request 🤷♀️. in fact, some dynamic resources consider that a feature ✨. the important distinction here is that the user did not request the side-effects, so they cannot be held accountable for them 💅
12.3. Abuse of Server Log Information 🕵️
a server is in the position to save personal data about a user's requests, which may identify their reading patterns or subjects of interest 📚. this information is clearly confidential in nature, and its handling may be constrained by law in certain countries 🌍. people using the HTTP protocol to provide data are responsible for making sure such material is not distributed without the permission of any individuals who are identifiable by the published results 🥹💜
12.4. Transfer of Sensitive Information
Okay bestie, HTTP is a generic data transfer protocol 💅, which means it literally cannot tell what's inside the stuff it moves. There's no built-in way to know whether a piece of info in a request is secret or spicy 🙈. So applications should give the info's owner as much control over it as possible 🫶. Three header fields deserve a special shoutout here: Server, Referer and From ✨
First up, Server 🖥️. Revealing the exact software version can make the server machine easier to attack, because attackers can go hunting for security holes in that specific software. Implementors should make the Server header field a configurable option 🎀.
Next, Referer 🔗. It lets people study reading patterns and draw reverse links. It's super useful, but its power can be abused if user details aren't separated from the info in the Referer. Even after the personal stuff is removed, the Referer might still reveal the URI of a private document, and publishing that could be inappropriate 😬.
Then From 🕵️♀️. What's sent here might clash with the user's privacy interests or the site's security policy, so it should not be transmitted unless the user can disable, enable, and modify the contents of the field. The user must be able to set the contents of this field within a user preference or application defaults configuration 💜.
Last one: we suggest, though we don't require, a convenient toggle interface so the user can turn From and Referer sending on or off 🌸.
12.5. Attacks Based On File and Path Names
Implementations of HTTP origin servers should be careful to restrict the documents returned by HTTP requests to only the ones the server administrators intended 🔒. If an HTTP server translates HTTP URIs directly into file system calls, the server must take special care not to serve files that weren't meant for HTTP clients 📁.
Here's the sneaky part: Unix, Microsoft Windows, and other operating systems use .. as a path component to mean "one directory level up." On those systems, an HTTP server must disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside the ones meant to be reachable through the HTTP server 🙅♀️.
Similarly, files meant only for internal use on the server, like access control files, configuration files, and script code, must be protected from inappropriate retrieval, since they might contain sensitive information 🗝️.
🚨 Experience has shown that minor bugs in such HTTP server implementations have turned into security risks. Be careful out there, bestie!
13. Acknowledgments
This spec makes heavy use of the augmented BNF and generic constructs that David H. Crocker defined for RFC 822 [7] 🧠. It also reuses a bunch of definitions from Nathaniel Borenstein and Ned Freed for MIME [5]. The hope is that including them here will help clear up past confusion about how HTTP/1.0 and Internet mail message formats relate 💌.
HTTP has evolved a lot over the past four years 🌈. It got big thanks to a large, active developer community, the many people who joined the www-talk mailing list, and that community is honestly the reason HTTP and the World-Wide Web took off. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special recognition for defining aspects of the protocol in the early versions of this spec 👑.
Paul Hoffman contributed the sections about this document's informational status, plus Appendices C and D ✨.
This document has also benefited hugely from comments by everyone in the HTTP-WG 🫶. Along with the people already mentioned, these lovely individuals contributed to this spec:
Gary Adams Harald Tveit Alvestrand
Keith Ball Brian Behlendorf
Paul Burchard Maurizio Codogno
Mike Cowlishaw Roman Czyborra
Michael A. Dolan John Franks
Jim Gettys Marc Hedlund
Koen Holtman Alex Hopmann
Bob Jernigan Shel Kaphan
Martijn Koster Dave Kristol
Daniel LaLiberte Paul Leach
Albert Lunde John C. Mallery
Larry Masinter Mitra
Jeffrey Mogul Gavin Nicol
Bill Perry Jeffrey Perry
Owen Rees Luigi Rizzo
David Robinson Marc Salomon
Rich Salz Jim Seidman
Chuck Shotton Eric W. Sink
Simon E. Spero Robert S. Thau
Francois Yergeau Mary Ellen Zurko
Jean-Philippe Martin-Flatin14. References
- [1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D., and B. Alberti, "The Internet Gopher Protocol: A Distributed Document Search and Retrieval Protocol", RFC 1436, University of Minnesota, March 1993.
- [2] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, CERN, June 1994.
- [3] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, MIT/W3C, November 1995.
- [4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994.
- [5] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
- [6] Braden, R., "Requirements for Internet hosts - Application and Support", STD 3, RFC 1123, IETF, October 1989.
- [7] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.
- [8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype Functional Specification." (v1.5), Thinking Machines Corporation, April 1990.
- [9] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC Irvine, June 1995.
- [10] Horton, M., and R. Adams, "Standard for interchange of USENET Messages", RFC 1036 (Obsoletes RFC 850), AT&T Bell Laboratories, Center for Seismic Studies, December 1987.
- [11] Kantor, B., and P. Lapsley, "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News", RFC 977, UC San Diego, UC Berkeley, February 1986.
- [12] Postel, J., "Simple Mail Transfer Protocol." STD 10, RFC 821, USC/ISI, August 1982.
- [13] Postel, J., "Media Type Registration Procedure." RFC 1590, USC/ISI, March 1994.
- [14] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, USC/ISI, October 1985.
- [15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/ISI, October 1994.
- [16] Sollins, K., and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation, December 1994.
- [17] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
- [18] ISO-8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin alphabet No. 1, ISO 8859-1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
15. Authors' Addresses
🧚 Tim Berners-Lee Director, W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, U.S.A.
Fax: +1 (617) 258 8682 EMail: timbl@w3.org
🧚 Roy T. Fielding Department of Information and Computer Science University of California Irvine, CA 92717-3425, U.S.A.
Fax: +1 (714) 824-4056 EMail: fielding@ics.uci.edu
🧚 Henrik Frystyk Nielsen W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, U.S.A.
Fax: +1 (617) 258 8682 EMail: frystyk@w3.org
Appendices ✨
These appendices are provided for informational reasons only 🧚. They do not form a part of the HTTP/1.0 specification.
A. Internet Media Type message/http
In addition to defining the HTTP/1.0 protocol, this document is also the spec for the Internet media type "message/http" 📨. Here's the registration info that gets registered with IANA [13]:
Media Type name: message
Media subtype name: http
Required parameters: none
Optional parameters: version, msgtype
version: The HTTP-Version number of the enclosed message
(e.g., "1.0"). If not present, the version can be
determined from the first line of the body.
msgtype: The message type -- "request" or "response". If
not present, the type can be determined from the
first line of the body.
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: noneB. Tolerant Applications
Although this document specifies the requirements for generating HTTP/1.0 messages, not every application will be perfect in its implementation 🥹. So we recommend that operational applications be tolerant of deviations whenever those deviations can be interpreted unambiguously 💖.
Clients should be tolerant when parsing the Status-Line, and servers should be tolerant when parsing the Request-Line 🫧. In particular, they should accept any amount of SP or HT characters between fields, even though only a single SP is required.
The line terminator for HTTP header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR 🌸.
C. Relationship to MIME ✨
okay bestie, so HTTP/1.0 borrows a bunch of stuff from Internet Mail (RFC 822 [7]) and the Multipurpose Internet Mail Extensions (MIME [5]) so entities can be sent in a whole open variety of representations with extensible mechanisms 🦋. BUT ngl, RFC 1521 is all about mail, and HTTP has a few features that are different from what RFC 1521 describes 🙈. Those differences were carefully chosen to optimize performance over binary connections 🚀, give you greater freedom with new media types 🎀, make date comparisons easier 📅, and acknowledge what some early HTTP servers and clients were already doing 💖.
At the time of writing, RFC 1521 is expected to get a glow-up 💅. The revisions may include some of the practices found in HTTP/1.0 but not in RFC 1521.
This appendix spells out the specific areas where HTTP differs from RFC 1521 🧚. Proxies and gateways to strict MIME environments should be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments to HTTP also need to be aware of the differences, because some conversions may be required.
C.1 Conversion to Canonical Form
RFC 1521 requires that an Internet mail entity be converted to canonical form before it gets transferred, as described in Appendix G of RFC 1521 [5]. Section 3.6.1 of this document tells you which forms are allowed for subtypes of the text media type when they're sent over HTTP 📝.
RFC 1521 says content with a Content-Type of text has to represent line breaks as CRLF, and it forbids using CR or LF outside of line break sequences 🙅♀️. HTTP is more relaxed: it allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted over HTTP 🌈.
Where it's possible, a proxy or gateway from HTTP to a strict RFC 1521 environment should translate all line breaks within the text media types described in Section 3.6.1 of this document to the RFC 1521 canonical form of CRLF ✨. Heads up though, this can get messy because of a Content-Encoding, and because HTTP allows some character sets that don't use octets 13 and 10 to represent CR and LF, which is the case for some multi-byte character sets 🙈💀.
C.2 Conversion of Date Formats
HTTP/1.0 uses a restricted set of date formats (Section 3.3) to keep date comparison simple 📅🫶. Proxies and gateways from other protocols should make sure that any Date header field in a message conforms to one of the HTTP/1.0 formats, and rewrite the date if necessary 💅.
C.3 Introduction of Content-Encoding
RFC 1521 has nothing equivalent to HTTP/1.0's Content-Encoding header field 😭. Since this one acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols must either change the value of the Content-Type header field or decode the Entity-Body before forwarding the message 🔥. (Some experimental apps using Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" to do the same job as Content-Encoding. However, this parameter is not part of RFC 1521 🤷♀️.)
C.4 No Content-Transfer-Encoding
HTTP doesn't use the Content-Transfer-Encoding (CTE) field of RFC 1521 🙅♀️. Proxies and gateways going from MIME-compliant protocols to HTTP must remove any non-identity CTE ("quoted-printable" or "base64") encoding before delivering the response message to an HTTP client 🍓.
Proxies and gateways going from HTTP to MIME-compliant protocols are responsible for making sure the message is in the correct format and encoding for safe transport on that protocol 🛡️. Here "safe transport" is defined by the limitations of the protocol being used. Such a proxy or gateway should label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over the destination protocol 🦋.
C.5 HTTP Header Fields in Multipart Body-Parts
In RFC 1521, most header fields in multipart body-parts are generally ignored unless the field name begins with "Content-" 🙃. In HTTP/1.0, though, multipart body-parts may contain any HTTP header fields that are significant to the meaning of that part 💜.
D. Additional Features 🎀
This appendix documents protocol elements that some existing HTTP implementations use, but not consistently or correctly across most HTTP/1.0 applications 🫠. Implementors should be aware of these features, but they can't rely on them being present in, or interoperable with, other HTTP/1.0 applications 🙈.
D.1 Additional Request Methods
D.1.1 PUT
The PUT method requests that the enclosed entity be stored under the supplied Request-URI 📦. If the Request-URI refers to an already existing resource, the enclosed entity should be considered a modified version of the one residing on the origin server ✏️. If the Request-URI doesn't point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI 🌸.
The big difference between POST and PUT lives in what the Request-URI means 👑. The URI in a POST request identifies the resource that will handle the enclosed entity as data to be processed. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations 🧠. The URI in a PUT request, on the other hand, identifies the entity enclosed with the request -- the user agent knows exactly what URI is intended, so the server should not apply the request to some other resource 🎯.
D.1.2 DELETE
The DELETE method requests that the origin server delete the resource identified by the Request-URI 🗑️💀.
D.1.3 LINK
The LINK method establishes one or more Link relationships between the existing resource identified by the Request-URI and other existing resources 🔗✨.
D.1.4 UNLINK
The UNLINK method removes one or more Link relationships from the existing resource identified by the Request-URI ✂️🦋.
D.2 Additional Header Field Definitions
D.2.1 Accept
The Accept request-header field can be used to indicate a list of media ranges that are acceptable as a response to the request 💅. The asterisk * character groups media types into ranges, with */* meaning all media types and type/* meaning all subtypes of that type 🌈. The set of ranges the client gives should represent what types are acceptable given the context of the request 🫶.
D.2.2 Accept-Charset
The Accept-Charset request-header field can be used to indicate a list of preferred character sets other than the default US-ASCII and ISO-8859-1 🔤. This lets clients that can understand more comprehensive or special-purpose character sets tell a server that can represent documents in those character sets that they can handle them 💖.
D.2.3 Accept-Encoding
The Accept-Encoding request-header field is similar to Accept, but it restricts the content-coding values that are acceptable in the response 🎁.
D.2.4 Accept-Language
The Accept-Language request-header field is similar to Accept, but it restricts the set of natural languages that are preferred as a response to the request 🌍.
D.2.5 Content-Language
The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity 🗣️. Note that this may not be equivalent to all the languages used within the entity 👀.
D.2.6 Link
The Link entity-header field provides a way to describe a relationship between the entity and some other resource 🔗. An entity may include multiple Link values 💜. Links at the metainformation level typically indicate relationships like hierarchical structure and navigation paths 🗺️✨.
D.2.7 MIME-Version
HTTP messages may include a single MIME-Version general-header field to indicate what version of the MIME protocol was used to construct the message 📜. Use of the MIME-Version header field, as defined by RFC 1521 [5], should indicate that the message is MIME-conformant. Unfortunately, some older HTTP/1.0 servers send it indiscriminately, so this field should be ignored 😭🙈.
D.2.8 Retry-After
The Retry-After response-header field can be used with a 503 (service unavailable) response to indicate how long the service is expected to be unavailable to the requesting client ⏰. Its value can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response 🕰️.
D.2.9 Title
The Title entity-header field indicates the title of the entity 🎀.
D.2.10 URI
The URI entity-header field may contain some or all of the Uniform Resource Identifiers (Section 3.2) by which the Request-URI resource can be identified 🦋. There is no guarantee that the resource can be accessed using the URI(s) specified 💀🌸.
📦 where this page comes from
- ietf: rfc1945 1996-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms