RFC1945 Hypertext Transfer Protocol - HTTP1.0

xiaoxiao2021-03-05  22

Organization: China Interactive Publishing Network (http://www.china-pub.com/)

RFC Document Chinese Translation Program (http://www.china-pub.com/compters/emook/aboutemook.htm)

E-mail: Ouyang@china-pub.com

Translator: Huang Xiaodong (Huang Xiaodong XDhuang@eyou.com)

Translation time: 2001-7-14

Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but must

Keep the translation and copyright information of this document.

Network Working Group T. Berners-Lee

Request for Comments: 1945 mit / lcs

Category: INFORMATIONAL R. FIELDING

UC IRVINE

H. FryStyk

MIT / LCS

May 1996

Hypertext Transfer Protocol - HTTP / 1.0

(HypterText Transfer Protocol - HTTP / 1.0)

About the next memo (Status of this Memo)

This paragraph text provides information for the Internet group and is not specified in any way. This paragraph text is not

There is a distribution limit.

IESG Note:

IESG is already paying attention to this agreement and looks forward to this document can be replaced by standard tracking documents as soon as possible.

Abstract

HTTP (Hypertext Transfer Protocol is the application level agreement, which adapts to the distributed hypermedia collaborative system

Flexibility and speed requirements. It is a general, stateless, object-based protocol, through its request method

(Request Methods) is expanded, can be used in a variety of purposes, such as named servers (Name Server)

Flat object management system. One feature of HTTP is that its data representation is allowed to build a system no longer dependence on

The data.

HTTP has been widely used on WWW since 1990. This specification reflects the general usage of "http / 1.0".

Table of Contents

1. Introduction 6

1.1 Purpose 6

1.2 Terminology 6

1.3 Overview (Overalll Operation) 8

1.4 HTTP and MIME 9

2. Sign Conversion and General Syntax (Notational Conventions and Generic Grammar) 9

2.1 Supplemental Feedback Method (Augment BNF) 9

2.2 Basic Rules 10

3. Protocol parameters 12

3.1 HTTP version (HTTP Version) 12

3.2 Uniform Resource Identifier $ 13

3.2.1 General Syntax 133.2.2 HTTP URL 14

3.3 Date / Time Format (DATE / TIME FORMATS) 15

3.4 Character Sets 16

3.5 Content Codings 16

3.6 Media Types 17

3.6.1 Standards and text default (Canonicalization and text defaults 18

3.6.2 Multipart Types 18

3.7 Product Logo (Product tokens) 19

4. HTTP Message 19

4.1 Message Types 19

4.2 Message Headers 20

4.3 General Header Fields 20

5. Request 21

5.1 Request-Line 21

5.1.1 Method (METHOD) 22

5.1.2 Request URI (Request-URI) 22

5.2 Request Header Fields 23

6. Respond (response) 23

6.1 Status-line 24

6.1.1 Status Code and Reason Analysis (Status Code and Reason Phrase) 24

6.2 Responding to the title header Fields 25

7. Entity (Entity) 26

7.1 Entity Title Domain (Entity Header Fields) 26

7.2 Entity Body 26

7.2.1 Type (TYPE) 27

7.2.2 Length (Length) 27

8. Method Definitions 27

8.1 Get 28

8.2 HEAD 28

8.3 POST 28

9. Status Code Definition (STATUS CODE Definitions) 29

9.1 Message 1xX (Information 1XX) 29

9.2 Success 2XX (Successful 2xx) 29

9.3 Redirection 3XX) 30

9.4 Client error (Client Error) 4XX 31

9.5 Server Error 5xx 32

10. Title Domain Definitions (Header Field Definitions) 33

10.1 Allowing 33

10.2 Authorization 34

10.3 Content-encoding 34

10.4 Content-length 3410.5 Content Type (Content-Type) 35

10.6 Date (Date) 35

10.7 Expired (Expires) 36

10.8 from (from) 37

10.9 When you change (if-modified-since) 37

10.10 Recent change (Last-Modified 38

10.11 Location (Location) 38

10.12 Note (PRAGMA) 39

10.13 Submition (Referer) 39

10.14 Server (SERVER) 40

10.15 User-Agent 40

10.16 WWW - WWW-Authenticate 40

11. Access Authentication 41

11.1 Basic Authentication Scheme 42

12. Safety considerations (Security Considance) 43

12.1 Customer Authentication Of Clients 43

12.2 Safety Method (SAFE Methods) 43

12.3 Disadvantages of Server Log Information (Abuse of Server Log Information) 43

12.4 Transfer of Sensitive Information 44

12.5 Attacks Based on File and Path Names 44

13. Thank you (ACKNOWLEDGMENTS) 45

14. Reference book (References) 45

15. Author's address (Authors' Addresses) 47

Appendices 48

A. Internet Media Type Message / HTTP (Internet Media Type Message / HTTP) 48

B. Way tolerant Applications 48

C. Relationship with MIME (RELATIONSHIP to MIME) 49

C.1 Conversion to specification form (Conversion to Canonical Form) 49

C.2 Date Format Conversion (Conversion of Date Formats) 49

C.3 Content Code Introduction (Introduction Of Content-Encoding) 50

C.4 No content transmission coding (no content-transfer-encoding) 50

C.5 HTTP Title Domain (HTTP Header Fields in Multipart Body-Parts)

50

D. Additional Features (Additional Features) 50

D.1 Additional Request Methods 51D.2 Additional Title Domain Definition (Additional Headr DEFINitions) 51

Introduction (Introduction)

1.1 purpose (Purpose)

HTTP (Hypertext Transfer Protocol is the application level agreement, which adapts to the distributed hypermedia collaborative system

Flexibility and speed requirements. It is a general, stateless, object-based protocol, through its request method

(Request Methods) is expanded, can be used in a variety of purposes, such as named servers (Name Server)

Flat object management system. One feature of HTTP is that its data representation is allowed to build a system no longer dependence on

The data.

HTTP has been widely used on WWW since 1990. This specification reflects the general usage of "http / 1.0".

This specification describes the features that have been implemented on most HTTP / 1.0 clients and servers. Specification will be

Divided into two parts: The implementation of the HTTP characteristics is the main content of this document, and other less popular implementations will be listed

Recording D.

A practical information system requires more functions, not just data acquisition, including search, front-end updates, and annotations.

HTTP allows an open command set to represent the purpose of the request, which uses a URI [2] (Uniform Resource

Identifier, ie the rules of the unified resource identification to position (URL [4]) or naming (URN [16]) method

source. HTTP uses and mail (Internet Mail [7]) and MIME (Multipurpose Internet Mail Extensions [5])

Similar formats to deliver messages.

HTTP also serves as a general protocol for communicating with other Internet protocols as a user agent, a proxy server / gateway.

Some protocols are SMTP [12], NNTP [11], FTP [14], Gopher [1], And WAIS [8], etc. HTTP allows different

Applications can make basic hypermedia resource access, and simplify user agents.

1.2 Terminology

This specification uses many terms related to participants, objects and HTTP communication, as follows:

Connection

Two applications create virtual circuits in the transport layer in the transport layer in communication.

Message

The basic unit of the HTTP communication, the structured, sequential byte of the connection is transmitted (its meaning in fourth)

The section is defined in section).

Request

HTTP request message (defined in Section 5)

Response (Response)

HTTP response message (defined in section 6)

Resource

Data objects or services that can be identified by URI (see Section 3.2) on the network (see Section 3.2)

Entity (Entity)

Special representation, data resources can be attached or responding to the representation of the data, and the response of the service resource, etc.,

Composed of meta information existing in the form of entity header or entity body (Entity Body).

Client (client)

Refers to the application to establish a connection with the purpose of issuing a request. User Agent

Refers to the client, such as browser, editor, spider (Web crawler) or other terminal

User tool.

Server

Refers to the connection and respond to the application of the service request by sending a response.

Origin Server

Store resources or generate resources that generate resources.

Proxy

At the same time, the intermediate procedure of servers and client roles is placed to generate requests for other customers. Request

For the transfer to the final destination server, inside the agent, requests or processes, or being passed. generation

The message must be interpreted before the message forwarding, and if necessary, it has to be rewritten. Agent is usually used

For client exits through the firewall to assist the request to process the user agent.

Gateway

Server between servers. Unlike the agent, the gateway accepts the request as if it is the requested resource.

Original server, the requesting client may not be aware that it communicates with the gateway. Gateway is the network

A portal of the firewall server side. When accessing non-HTTP system resources, the gateway is an intermediate protocol

Translator.

Tunnel

The tunnel is like a repeater that connects to both ends. When it is activated, it is from HTTP request.

Initialization, it does not participate in HTTP communication. When the two ends of the relay connection are needed, the tunnel is naturally

termination. Tunnels are usually used when there is a demand and intermediate procedure that is required and the intermediate program cannot or not explained.

technology.

Cache

Reference The retriever local storage and the subsystem used to control the message storage, recovery, and delete.

The purpose of the cache response is to reduce the request response time and the consumption of network bandwidth in the next time. Either

How the client and the server can contain a cache. The server cannot use a cache when working in a tunnel.

Any specified program has the ability to be used as a client and server. When we use this concept, it is not a look.

Do you have customer and server on the order function, but what role is played on a specific connection time (customer or service

Sterler). Similarly, any server can play the original server, agency, gateway, tunnel, etc.

Due to the content of each request.

1.3 Overview (Overale Operation)

The HTTP protocol is based on request / response mechanism. After the client is connected to the server, the client is established to request the method, URI,

Protocol version, etc., send a request to the server, which can follow the included request modifier, customer information, and possible

MIME type message for the request body (body).

The server side responds through the Status Line, including the protocol version of the message, success or error generation

Code, followed by a MIME type message containing server information, physical metample information, and entity content.

Most HTTP communications are initialized by the user agent, and the request is assembled to get stored in some original.

Resources on the initiator. In the simplest case, between the User Agent (UA) and the original server (O)

A simple connection (V) can be done.

Request chain ------------------------>

UA ------------------- V ------------------ O

<----------------------- Response Chain

More complex situations are one or more intermediate links between the request / response chain. Overall, there are three middle

Section: Proxy, Gateway, Tunnel. Proxy (proxy) is a forward-pusher agent (Agent), which receives URI requests in absolute form, rewriting all

Or part of the message and will continue to push at the server specified in the URI.

The gateway is a receiving agent. It is on the server layer, and it is transmitted by the server to recognize the agreement.

request.

The tunnel does not change the message, it is just a relay point to connect both ends. In the middle layer (such as a firewall) or the intermediate layer cannot be solved

In the case of a message content, it is necessary to rely on tunnel technology to help communicate cross the intermediate layer.

Request chain -------------------------------------->

UA ----- V ----- A ----- V ----- B ----- V ----- C ----- V ----- O

<------------------------------------- Response Chain

The above graphic represents three intermediate layers (A, B, and C) between the user agent and the original server. as illustrated,

Request or response message running on the entire information chain to pass four separate connections, it is the simple feelings introduced before this

There is a difference between the situation, and this difference is very important. Because the HTTP communication option can be set to several cases, if only

Connect to the nearest non-tunnel neighbor, only connect to the end of the information chain, or can be connected to all links in the chain. Although

The picture of the face is linear, and in fact, each participating link is also communicating with multiple parties. For example, B is accepted

Other client requests from other clients, push requests from other servers other than C, at this moment, it may

Accept A request and give it processing.

Any party participating in the communication if there is no work in a tunnel, you must handle the internal cache mechanism.

Ask, if a part of the chain happens to caches a request for a request, it corresponds to the shortened request / response chain. under

The legend of the face demonstrates the case where the B is cached from the response information from C, while the case where ua and a have no cache:

Request chain ---------->

UA ----- V ----- A ----- V ----- B - - - - - C - - - - - O

<--------- Response Chain

Not all responses can be cached, and some requests may be special in the modifiers included in the request.

Indicate. Some HTTP / 1.0-based applications use a heuristic way to describe which responses can be cached, and which

No, but unfortunately, these rules have not formed standards.

On the Internet, HTTP communication is often based on TCP / IP connection. The default port is TCP 80 [15] mouth,

However, other ports can also be used. Does not exclude HTTP implementation of other protocols or network protocols on the INETERNET

The HTTP is just assumed that the transmission is reliable, so any protocol that can provide this guarantee can be used. Until

HTTP / 1.0 requests and responds to data structures in the data transfer process, not within the scope of this article.

Except for laboratory applications, the current practice is that the client establishes a connection before each request, and the server is sent back.

This connection is closed after it should be closed. Regardless of the client or server, pay attention to handling burst interruptions, because both parties have

It can be closed because the user operates, automatic timeout, the program failure, etc. In this case, regardless of the request

What kind of state, such as unilateral or both, will cause the current request to be terminated.

1.4 HTTP and MIMEHTTP / 1.0 uses a variety of structures to define MIME, see RFC1521 [5] for details. Appendix C describes the Internet

The INTERNET media type is different from the MAIL media type and gives the basic explanation of both.

2. Sign conversion and general syntax (Notational Conventions and

Generic grammar)

2.1 Supplemental Feedback Method (Augment BNF)

It is very similar to RFC822 [7], which is described in the manner of all mechanisms in a prose and supplementary feedback.

For implementations, you must understand these agreements, you must be familiar with these symbols. Supplementary feedback (Augmented

BNF) includes the following structure:

Nouns to explain = noun explanation (Name = definition)

The name of the rule is it itself (without any angle bracket, "<", ">"), followed by the equal number =,

Then the definition of this rule. If the rule needs to be described in multiple rows, the retracted format is used to use spaces.

Version. Some basic rules use uppercase, such as SP, LWS, HT, CRLF, Digit, Alpha, and more. definition

You can also use angle brackets to help understand the use of rule names.

Lesser meaning ("literal")

The literal meaning of the text is placed in the middle of the quotation, unless specified, the text is sensitive.

Rule 1 | Rule 2 (Rule1 | Rule2)

"|" Indicates that its separated element is optional, for example, "Yes" Yes "is 'is' or 'No'.

(Rule 1 Rule 2) ((rule1 rule2))

Elements in parentheses indicate that one of them must be selected. Such as (element 1 (element 2 | element 3) element 4) can indicate two

Interest, ie "element 1 element 2 element 4" and "element 1 element 3 element 4"

* Rules (* rule)

In front of the elements, the star number "*" represents the cycle, its complete form is " * element", indicating the minimum output of the element

times, up to times. The default is 0 to infinite, for example, "1 * element" means at least one,

"1 * 2 element" indicates that there are 1 or 2.

[Rule] ([Rule])

In square brackets are optional elements. Such as "[element 1 element 2]" and "* 1 (element 1 element 2)" is one

thing.

N rule (n rule)

Number of times of cycling: " (element)" is " * (element)", which is precisely pointed out in

Value. Thus, 2Digit is 2 digits, and 3ALPHA is a string consisting of three letters.

# 规 ((#rule)

"#" Is similar to "*" to define a list of elements.

The complete form is " # element" means at least at most element, intermediate "," or

Any number of spacespaces are separated, which will make the list, such as "(* LWS element * (* LWS", "* LWS element)" is equivalent to "1 # element".

Empty elements can be used any in the structure, but do not participate in the count of the number of elements. That is, "(element 1),

(Element 2) "only represents 2 elements. However, in the structure, there should be at least one non-empty element. By default

The value is 0 to unlimited, ie "# (element)" means any value, including 0; and "1 # element" representation

There are less than 1; "1 # 2 element" means there is 1 or 2.

Comment (; Comment)

The semicolon is noted later, only in a single line.

Injection * LWS (IMPLIED * LWS)

The grammatical description of this article is based on words. Unless otherwise specified, linear spaces (LWS) can be two adjacent

Number or separator (tspecials) is used anything, but will not affect the meaning of the whole sentence. In two symbols

There must be at least one separator between them because they also interpret them as separate symbols. In fact, the application is

When generating an HTTP structure, it should be tried to follow the "usual mode" because it is indeed in the usual manner.

It is not working properly.

2.2 Basic Rules

The following rules will be used in the basic analysis of structures after this article.

US-ASCII encoded character set definition [17].

OcTet = <8-bit sequential data, ie Bytes>

Char =

Upalpha =

LOALPHA =

Alpha = Upalpha | Loalpha

Digit =

CTL =

Cr =

LF =

SP =

HT =

<"> =

HTTP / 1.0 regulations, except for entity main body (entry-body, see Appendix B fault tolerant application), all protocols

The end of the line is over the CRLF (in byte order). The end flag definition of the line end of the entity main body and

Its corresponding media type is defined, see a description of Section 3.6.

CRLF = CR LF

The head of HTTP / 1.0 can be folded into a lot, as long as each subsequent line starts with a space or horizontal tab. all

Linear spaces (LWS), with spaces (SP) have the same semantics.

LWS = [CRLF] 1 * (SP | HT)

In fact, some applications do not consider handling such a multi-line head, so consider compatibility, http / 1.0

It is best not to generate a multi-line head.

The TEXT rule is just the content of the domain used to describe the message interpreter and its value. Text content can be included

Unlike the character of US-ASCII.

TEXT =

The recipients in the title domain, such as characters that include the US-ASCII character set, these characters will follow

ISO-8859-1 is interpreted.

Hexadecimal digital characters are in several protocol elements.

HEX = "a" | "b" | "c" | "d" | "e" | "f"

"A" | "B" | "C" | "D" | "e" | "f" | DIGIT

The content of many http / 1.0 headers consists of words or special characters separated by LWS, these special characters

The string must be placed in the middle of the quotation marks as the parameter value.

Word = Symbol (TOKEN) | Strings caused by quotation marks

Token = 1 *

Tspecials = "(" | ")" | <"|"> "|" @ "

| "," | ";" | | "/" | <">

| "/" | "[" "]" | "" | "="

| "{" | "}" | SP | HT

In the HTTP header field, you can use brackets to indicate text. Note Only writes the domain containing the comment, as a domain value

Part of the definition. In addition to other domains, parentheses will be considered as domain values.

Comment = "(" * (ctext | comment) ")"

ctext =

The text string in the double quotes will be considered a word.

Quoted-string = (<"> * (qdtext) <">)

QDText =

The rear slash "/" is not allowed in HTTP / 1.0 to reference a single character.

3. Protocol parameters (Protocol parameters)

3.1 HTTP Version (HTTP Version)

HTTP uses the master from (. ) to represent the version. The version policy of the agreement tends to make hair

The delivery party indicates the format and function of its message, not just for the characteristics of communication, the purpose of this is to be higher

Version HTTP implementation communication. Only increasing the value of the extension or increases messages that do not affect communication behavior will not cause

Version data changes. When the main parsing algorithm of the protocol message is different, the message syntax and the implicit function of the sender have increased, which will result in an increase from the version number (); when the format of the message in the agreement changes, the main version number (< Major>)

Changes will occur.

The version of the HTTP message is represented by the HTTP version field in the first row. If the protocol version in the message is not

Specify, the recipient must assume that it is a simple standard that meets HTTP / 0.9.

Http-version = "http" / "1 * Digit". "1 * DIGIT

Note that the master-slave version should be considered a separate integer because they all have increased, thus more than one whole

number. Thus, HTTP / 2.4 is lower than HTTP / 2.13, and HTTP / 2.13 is lower than HTTP / 12.3.

0 of the version number will be ignored by the recipient, but should not be generated at the sender.

This document defines 0.9 and 1.0 versions of the HTTP protocol. Send full request (full-request) and complete

The application of the Full-response message must indicate that the HTTP version is "http / 1.0".

HTTP / 1.0 server must:

o Identify the format of the request queue in the HTTP / 0.9 and HTTP / 1.0 request commands.

o Understand any legal request format in HTTP / 0.9 and HTTP / 1.0.

o Use the same version of the agreement to respond to the client.

HTTP / 1.0 client must:

o Identify the format of the Status-line in the HTTP / 1.0 response.

o Understand the format of legal response in HTTP / 0.9 and HTTP / 1.0.

When the agent and gateway receives HTTP requests with their own versions, be careful to handle the push of the request because

The protocol version indicates that the sender's capabilities, the agent, or gateway should not issue a message higher than its own version. If you receive a high version

Request, proxy or gateway must reduce the version of the request and respond to an error. The low version of the request should also be pushed

Pre-upgrade.

The proxy or gateway responds to the request, you must follow the previously listed regulations.

3.2 Uniform Resource Identifiers

There are many names such as WWW addresses, Universal Document Identifiers.

With resource identifiers (Universal Resource Identifiers [2]), and the final unified resource locator (Uniform

Resource Locators (URL) [4]) and Unified Resources (URN). Before related to HTTP, URI uses simple format

String Description - Name, location, or other characteristics, such as network resources.

3.2.1 General Synthics (General Syntax)

In HTTP, the URI can be expressed in absolute form, or it can be represented in the form of a certain basic URI [9].

The body depends on their way of use. The difference in these two forms is that the absolute URI always begins with the method name ":": "

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 =

Reserved, Extra, Safe, And UNSAFE>

Authoritative URL syntax and semantic information, see RFC1738 [4] and RFC1808 [9]. BNF mentioned above

The symbols that are not allowed in the legal URL (RFC1738) because the HTTP server is not limited to only

Non-reserved characters in the character set to represent address paths, and HTTP proxy may also receive RFC1738 without definition

URI request.

3.2.2 HTTP URL

"Http" means to locate network resources through the HTTP protocol. This section defines the syntax and semantics of the HTTP URL.

http_url = "http:" "" Host [":" port] [ABS_PATH] HOST =

See RFC1123, 2.1 Definition>

Port = * DIGIT

If the port is empty or not specified, the default is 80 ports. For the URI of the absolute path, it has requested

The server host of the resource receives the URI request by listening to the TCP connection of the port. If there is not given in the URL

Absolute path, use as a request URI (see Section 5.1.2), must be given in "/".

Note: Although the HTTP protocol is independent of the transport layer protocol, the HTTP URL only identifies the TCP location of the resource, but

For non-TCP resources, there must be identified in the form of other URIs.

Specification HTTP URL forms can be converted to lowercase by converting uppercase characters in the host (host name is sensitive

) To get. If the port is 80, remove the colon and port number, and replace the empty path to "/".

3.3 Date / Time Format (DATE / TIME FORMATS)

For historical reasons, HTTP / 1.0 applications allow three formats to represent timestamps:

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 () Format

The first format is the preferred INTERNET standard format, indicating method length (RFC 1123 [6]). Second

It is used in normal cases, but it is based on the date format in the abandoned RFC850 [10], and the year is not used.

The four digits are represented. HTTP / 1.0 client and server side can identify all three formats during parsing date, but it

They cannot produce a third time format (ASCTIME).

Note: When receiving date data generated by non-HTTP applications, the received date values ​​are promoted.

This is because, at some point, the agent or gateway may get or send messages via SMTP or NNTP.

All HTTP / 1.0 Date / TIMP Timestamps must use World Time (UT), That is, Greenwich

Time is expressed (Greenwich Mean Time, GMT) without any residual room. The two formats in front are used.

"GMT" indicates the time zone, and when reading the ASC, it should also be assumed to be this time zone.

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 can only use the Data / Time timestamp format in the protocol stream, do not require client and services

The server uses this type in the case of user description, request login, etc.

3.4 Character Sets

The character set used by HTTP defines the same as the MIME:

This document uses a character set to indicate the order of sequence bytes into a sequence word using one or more tables.

Method of characters. Note that there is no need for unconditional conversion in other directions, because all characters can be used

The character set is expressed, and a character set may also provide one or more byte order to represent a special

Special characters. This definition tends to allow different types of character encodes to be implemented by simple single table mapping.

For example, switch from Table US-ASCII to complex tables such as ISO2202. In fact, associated with the MIME character collection name

Definition must completely specify mappings from bytes to characters, especially not allowed by utilizing external configuration information.

Accurate mapping.

Note: The term character set is characterized by character encoding. In fact,

Because HTTP is commonly used with MIME, the terminology should also be consistent.

The HTTP character set consists of case sensitive symbols. All symbol definitions See IANA character set registration

[15]. Because the registration office does not define a symbol separately, we see the characters you see.

Most of the collection is related to HTTP entities. These characters registered in RFC 1521 [5], namely

US-ASCII [17] and ISO-8859 [18] character set, and some other character sets are strongly recommended in MIME

The character set parameter is used inside.

Charset = "US-ASCII"

| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"

"ISO-8859-4" | "ISO-8859-5" | "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"

| token

Although HTTP allows the use of dedicated symbols as a character set, any of the IANA character set registry [15]

The symbols with a predefined value must indicate the character sets they belong. Application should be limited to the character set

System within the range specified by IANA registry.

If the character set of the entity main body is not required to mark, otherwise,

The most basic naming in the main character encoding should be used.

3.5 Content Codings

The content decoding value is used to indicate encoding conversion to the resource. Content decoding is mainly used to compress, encrypt, etc.

The document is restored to keep it its original media type. Typically, the coded saved resources can only be

Decoding or similar operations can be restored.

Content-Coding = "X-Gzip" | "X-compress" | token

Note: For future compatibility, HTTP / 1.0 applications should be "gzip" and "compress" respectively

"X-Gzip" and "X-compress" corresponds.

All content decoding values ​​are sensitive. HTTP / 1.0 uses within the header field of content encoding (10.3)

Conformor code value. Although this value is described in the content decoding, but more important is that it indicates what mechanism should be used

decoding. Note that a separate program may have the ability to implement decoding of multiple format encoding.

In this text, two values ​​mentioned:

X-Gzip

File compression program "Gzip" (GNU ZIP, developed by jean-loup gailly). This format belongs to

Typical Lempel-ZIV decoding with 32-bit CRC validation (LZ77).

X-compress

File compression program "compress" encoding format, this format is available for LZW (Lempel-Ziv-Welch) translation

code.

Note: Use the program name to identify the code format, not very ideal, in the future, may not continue to do so. right now

This is the reason for history, not a good design.

3.6 Media Types

HTTP uses Internet Media Types in Content-Type Header (10.5) [13] to provide openness

Scalable data types.

Media-type = type "/" subtype * (";" parameter)

Type = token

Subtype = token

The parameters can refer to the properties / value pair, written with the type / subtype format.

Parameter = attribute "=" value

Attribute = token

Value = token | quoted-string

Where, type, subtype, parameter attribute name is sensitive. The parameter value is not necessarily sensitive, which is depends on the syntax of the parameter name. There is no LWS (space) between type and subtypes, attribute names, and attribute values. when

When receiving parameters of the type of media that cannot be identified, the user agent should ignore them.

Some old HTTP applications cannot identify media type parameters, so the application of HTTP / 1.0 can only define

Use media parameters when content is content.

Media-Type value with Internet authorization allocation numbers (Internet Assigned Number)

Authority, IANA [15]) Register. See RFC1590 [13] for the media type registration process. Not encouraged unregistered

Medium type.

3.6.1 Standards and Text Defaults (CANONICALIZATION AND TEXT Defaults)

The Internet media type is registered in the form of a specification. Generally, the entity main body is transmitted through the HTTP protocol.

Before entity-body, it must first indicate it into an appropriate specification format. If the main body is used with one

Content-encoding is encoded, the following data must be converted into a normative form before encoding:

The media subtype of the "Text" type is interrupted by using CRLF in the specification form. In fact, for the entity

The use of the entry body is consistent, and the HTTP allows transport to interrupts separately in CR or LF.

Text media. The HTTP application must use CRLF, Cr, and CRL, CR,

Lf is seen as a line break.

In addition, if the character set of the text medium does not use bytes 13 and 10 as CR and LF, like some multi-byte words

The symbol set, HTTP allows the use of any sequential bytes specified by this character set to be interrupted, this line

The flexible mode of use of interrupts can only be in the entity main body (entity-body). A pure Cr or LF should not be in any http

The control structure (such as the title domain-Header Field and Multi-block-Multipart Boundaries) replaces CRLF.

The parameter "charset" is used with some media types when defining the data set (Section 3.4). Sender

When there is no explicitly gives a character parameter, HTTP defines the "text" media subtype when receiving the default.

Value "ISO-8859-1". "ISO-8859-1" character set or data other than its subset must mark its corresponding character set value,

This ensures that the reception can be parsed correctly.

Note: Many current HTTP servers provide data from "ISO-8859-1" other character sets, and also

Without the correct mark, this mode of work limits interoperability, it is recommended not to adopt. As a remedy,

Some HTTP User Agents provide configuration options that can be changed by using the user without specified.

Default media type interpretation method.

3.6.2 MultiPart Types

MIME provides a number of numbers of "Multipart") - in a separate message entity main body

(Entity-Body) can be packaged in several entities (enttive). Although the user agent may need to know each type, from

It can correctly explain the intent of each part of the subject, but in the multipart types of IANA [15]

It can't find the content specified for HTTP / 1.0. HTTP User Agent has to do its own work, the process and behavior are the same or similar to the MIME user agent. HTTP server should not assume HTTP customers

Both have the ability to handle multiple types.

All multi-segment types use generic syntax, and must include boundary parameters in the media type value section.

Boundary Parameter. The main body of the message is its own, as an agreement element, it must only use CRLF as a segment

Body-Parts' row intermittors. Multipart Body-Parts may include it is important to each paragraph

Righteous HTTP Title Domain.

3.7 Product Identification (Product tokens)

It is a communication application to identify a simple symbol of its own, often use with any letters and version descriptions.

Most product identities also lists the version numbers of the important components of their products, separated by spaces in the middle.

Press conventions, when identifying the application, the components are arranged in its importance.

Product = token ["/" product-version]

Product-Version = Token

E.g:

User-agent: Cern-linemode / 2.15 lowww / 2.17b3

Server: Apache / 0.8.4

The product identity should be short, thus prohibiting the use of this domain to fill in the advertisement or other unrelated information. Although any symbolic characters

In the product version, the symbol should only be used to make a version definition, that is, a continuous version of the same product

It can only be distinguished between the product version value.

4. HTTP Message (HTTP Message)

4.1 Message Types

The HTTP message consists of a request for the client to the server and a response from the server to the client.

Http-message = Simple-request; http / 0.9 Messages

| Simple-Response

Full-Request; HTTP / 1.0 Messages

| Full-Response

Full-Request and full response (full-response) use RFC822 [7] in physical pass

The message format specified in the section. The news of the two may include the title domain (HEADERS, optional), entity main body (Entity)

Body). The entity main body is separated by the blanks (i.e., there is no line before 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.2

Simple request (Simple_Request) and Simple-response are not allowed to use any title information,

And limit only the unique request method (GET) Simple-Request = "Get" sp Request-URI CRLF

Simple-response = [Entity-body]

Do not advocate the use of simple ways request format because it prevents the server from returning to entities when the server receives a simple request.

Quality type is verified.

4.2 Message Title (Message Headers)

HTTP Title Domain, including the main title (General-Header, Section 4.3), request title (Request-HEADER, 5.2),

Response title (Response-HEADER, 6.2) and entity title (Entity-HEADER, 7.1), follow RFC822-3.1

The general format definition given by Section [7]. Each title domain is followed by the name of the colon, single spacer (SP), characters, and domain value groups

to make. The domain name is case sensitive. Although it is not advocated, the title domain can be expanded into multi-line use, as long as these lines are

The above SP or HT starts.

Http-header = field-name ":" [Field-Value] CRLF

Field-name = token

Field-value = * (Field-Content | LWS)

Field-content =

And consisting of each * text or combinations

of token, tspecials, and quoted-string>

The order in the title domain is not important, but good habits are, first send the master title, then the request title or response

The title, the final is the entity title.

When all the domain values ​​of the title domain are indicated by a comma-separated column (ie, the # (value)), there are multiple identical domain names.

The HTTP header domain can be represented in a message. Moreover, it must be able to send concurrently without changing the message syntax.

The domain value is added to the first value, and between the comma, it will eventually combine multiple title domains into a "domain name".

4.3 General Header Fields

There are several headings to be used by requests, but do not be used to be transmitted. These headings are only used

Transferred message.

General-header = date; section 10.6

| Pragma; Section 10.12

The general title domain name can only be reliable only after the change in the change in the protocol version. In fact,

The new or experimental header domain can be used by communication parties, and its grammar can be used, and the key domain that cannot be identified will

It is considered an entity domain.

5. Request

Request messages from the client to the server include, the message header, the request method of the resource, the identifier of resources

And the protocol used. Taking into account the backward compatibility of HTTP / 0.9, there are two legal HTTP requests.

format:

REQUEST = Simple-Request | Full-Request

Simple-request = "get" sp Request-URI CRLF

Full-Request = Request-line; Section 5.1

* (General-head; section 4.3 | request-head; section 5.2

| Entity-header; section 7.1

CRLF

[Entity-body]; section 7.2

If the HTTP / 1.0 server receives a simple request, it must respond to a simple response in an HTTP / 0.9 format.

The HTTP / 1.0 client has the ability to receive a complete response, but it cannot produce a simple request.

5.1 Request-line

The request queue starts with a method symbol, followed by the request URI and protocol version, ending with CRLF.

This element is separated by space SP. A separate CR or LF value is not allowed in addition to the final CRLF.

REQUEST-line = Method SP Request-Uri SP HTTP-VERSION CRLF

Note that the difference between the simple request queue is between the request queue in the full request is whether there is an HTTP version field and if

Use other methods other than Get.

5.1.1 Method (Method)

The method code indicates how many ways to be accessed by request URI will be accessed. The method is case sensitive.

Method = "get"; section 8.1

| "HEAD"; section 8.2

| "Pos"; section 8.3

| Extension-Method

EXTENSION-METHOD = TOKEN

The method list that can access the specified resource can be dynamically changed; if you use some way to access the resource is rejected, passengers

The end can be notified from the return code in the response. The server side returns a status code when the method cannot identify or not implement it.

501 (has not yet been achieved).

These methods are commonly used by the HTTP / 1.0 applications, and see Section 8 for complete definitions.

5.1.2 Request URI (Request-URI)

The request URI is the Unified Resource Identifier (Section 3.2) to identify resources to be requested.

Request-Uri = Absoluteuri | ABS_PATH

The above two requests URI mode can be selected according to the actual request.

The absolute URI (ABSOLUTEURI) format is only used when the proxy is generated during the request. The responsibility of the agent is

Request to push forward and return it back. If the request is a GET or HEAD mode, and the previous response is cached,

If the agent ignores expiration information restrictions in the title domain, it may use the messages in the cache. Note that the agent may push the request

Send to another agent, you can also send the request directly to the destination server specified in the absolute URI. To avoid requests

Loop, the agent must be able to identify all of its server names, including alias, local variables, and digital forms of IP addresses.

Here is an example of a request queue:

Get http://www.w3.org/pub/www/theproject.html http / 1.0

The most common request URI is the way the original server or gateway is used to identify resources. In this way,

Only URIs given to the absolute path can be transferred (see Section 3.2.1). For example, if the client wants to directly serve directly

Receive resources on the server, which will generate a TCP connection with the host "www.w3.org" 80 port, and in full request

After sending the following command:

Get /Pub/www/theproject.html http / 1.0

Note that the absolute path cannot be empty. If there is no content in the URI, it must be added "/" (Server root). The request URI is transmitted by encoding a string, and some characters may be escaped during the transmission process, such as changing

"% Hexhex" form. For details, please refer to RFC1738 [4]. Original server is correctly explained

The request URI must be decoded before.

5.2 Request the title (Request Header Fields)

Request the title field allows the client to deliver additional information and client information to the server to the server. This domain is a request

The modified portion, in accordance with the grammatical form of the programming language program calls the parameters.

Request-header = authorization; section 10.2

| From; section 10.8

| If-modified-Since; Section 10.9

| Refrer; section 10.13

User-agent; section 10.15

Request the title domain name only after combining the change in the protocol version to make a reliable extension. In fact, new

Or the title domain in the experiment can be identified by the communication parties, and its syntax can be used, and the key domain that cannot be identified will be

It is considered an entity domain.

6. Respond (response)

After receiving, the server side returns an HTTP response message after receiving the request 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.2

When the request is http / 0.9 or when the server is only supports http / 0.9, it can only be simple-response method.

Respond. If the client sends an HTTP / 1.0 full request, the received response is not status line (STATUS-line)

At the beginning, the client will deepen it as a simplicity and analyze it accordingly. Note that simple requests only include entity main body,

It terminates when the server is closed.

6.1 Status-line

The first line of the full response message is the status line, which is in turn by the protocol version, the status of state, and the corresponding

The word text composition, each element is separated by space (SP), except for the end of CRLF, is not allowed separately

CR or LF.

Status-line = http-version sp status-code sp seed-phrase CRLF

The status line always starts with the protocol version and status code, such as:

"HTTP /" 1 * DIGIT "." 1 * Digit SP 3Digit SP

(Eg, "HTTP / 1.0 200").

This expression is not enough to distinguish the complete request and simple request. Simple response may allow this expression to appear

The start portion of the entity main body, but will cause misunderstandings of the message. Because most HTTP / 0.9 servers can only return

In this case, it is impossible to generate a complete response in this case.

6.1.1 Status Code and Reason Analysis (STATUS CODE AND REASONPHRASE)

Status-code consists of 3 digits, indicating whether the request is understood or is satisfied. Cause analysis is

Use short text to describe the cause of the status code. Status code is used to support automatic operation, the reason analysis is for humans

User is ready. The client does not need to check or display the reason analysis.

The first digit of the status code defines the category of the response, and the two digits have no specific classification. The first digit has 5

Value value:

o 1xx :: Reserved, in the future.

o 2XX: Success - operation is received, understood, accept, accept, understood, accepts.

o 3XX: Redirection - To complete the request, further action must be performed.

o 4XX: Client error - requests for speech errors or cannot be implemented.

o 5XX: The server end error - the server cannot achieve legal requests.

The status code of HTTP / 1.0 is explained below. The reason is explained below is recommended to use it.

Changes without affecting the protocol. The complete code is 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 Implement

| "502"; BAD GATEWAY

| "503"; Service Unavailable

| Extension-Code

Extension-code = 3digit

REason-phrase = *

The HTTP status code is scalable, and only the above code can be identified by all current applications. HTTP

Application does not require all registered status code, of course, if it is better. In fact, the application must understand

Any state code, if you encounter an unrecognized situation, can determine its type and process according to its first digit. In addition,

Do not cache the response that cannot be identified.

For example, if the client receives a state code 431 that cannot be identified, it can be safely assumed that the problem is requested.

The status code that can be considered responding is 400. In this case, the user agent should notify the user in the entity responding to the message.

Since the entity can include some description information of the non-normal state that humans can identify.

6.2 Responding to the title header field (Response Header Fields)

The response Title domain includes additional response information that cannot be placed in the status line. This domain can also be stored related to the server

Information, and next information for accessing the resource specified by the request URI.

Response-header = location; section 10.11 | Server; Section 10.14

WWW-Authenticate; section 10.16

The response title domain name is only a reliable extension only after the change in the protocol version is combined. In fact, new

Or the title domain in the experiment can be identified by the communication parties, and its syntax can be used, and the key domain that cannot be identified will be

It is considered an entity domain.

7. Entity (Entity)

Complete requests and complete response messages may transfer entities in the request or response. Entity is headed by the entity

(Entity-header) domain, (usually) Entity-body composition. From this perspective, the client

The role of the sender and the receiver will be played with the server. The role positioning at a certain moment depends on who is in this moment.

Send an entity, and who is receiving the entity.

7.1 Entity header field (Entity Header Fields)

Some optional meta information is defined in the entity header domain, if there is an entity, request resources.

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

The extension-header mechanism allows the additional entity header domain to be defined without changing the protocol.

However, it cannot be assumed that the recipient can identify these domains. For unconcerned title domains, the recipient generally ignores regardless of it.

The agent continues to push it forward.

7.2 Entity Body (Entity Body)

The format and encoding information of the entity main body sent together with HTTP request or respond together are in the entity header domain.

(Entity-header) defined in.

Entity-body = * octet

The entity main body is only placed in the request message only when the request method is required. Request the content length of the message title domain

The symbol of the content-length header field will indicate whether the entity main body in the request exists. Entity

The HTTP / 1.0 request of the body must contain legal content length header domain.

For the response message, whether the entity body contains the entity main body depends on the request method and response code. All head

The response to the request should not include the body, even if there is a subject in the entity title field. No bags in the main body

Including these response information, all 1xx (information), 204 (no content) and 304 (not modified). And other responses must be packaged

Including the entity main body or the contents of the contents thereof of the contents of the contents of zero.

7.2.1 Type (TYPE)

When the message includes an entity main body, the data type of the body is in the content type in the title domain, and within

Content-encoding decision. Define the second layer order encoding mode:

Entity-body: = Content-Encoding (Content-Type (DATA))

Content type (Content-Type) specifies the media type (Media Type) of the following data. Content-encoding can be used to indicate additional content decoding methods, usually used to be requested with data compression attributes

source. The default value of content encoding is None.

Any message including the entity body must contain the content type title domain to define the class of the main body.

type. Only when the media type is not given in the content type title field, such as simple response messages, the recipient may have the URL

The specified resource is determined, such as its content and extension, etc., guess the media type of the body. If there is no

The method determines the type of media, and the receiver should treat it as an "Application / OCTET-Stream" type.

7.2.2 Length (Length)

When the entity main body is included in the message, the main body length can be determined by two ways. If the content length

(Content-length) Title domain exists, its byte value is the length of the entity main body; otherwise, its main body length is passed by the server

Determine when the connection is turned off.

Since the server cannot send a response information when the connection is closed, the junction of the request main body cannot be indicated with a closed connection.

bundle. Thus, HTTP / 1.0 requests If the body is included, it must be given in the content length (Content-length title ".

Legal value. If the request includes the entity main body, and the content length is not specified, the server will not be able to identify or cannot be from other

The main body length is calculated in the domain, in which case the server will return to the 400 (illegal request) response.

Note: Some old servers support illegal internals when sending data stream files that contain dynamically inserted by the server.

Based length. It is emphasized that the future version of the HTTP protocol will change this situation soon. Unless the client yourself

Knowing that it is responding from a server side that supports it, otherwise it should not depend on the correctness of the content length domain.

8. Method Definitions

The general HTTP / 1.0 method set will be defined below, although the method set can be expanded, but does not guarantee additional

The method can be expanded to the client and server end support.

8.1 get

The GET method is to obtain information specified by the request URI in an entity method. If the request URI is just one

The data generation process is finally returned in the response entity, which is pointed to by the result of the process, not

It is a description of the process of returning to the process unless the text is exactly the output.

If the request message contains the IF-Modified-Since title domain, the syntax of the GET method becomes "condition GET", ie

Conditional Get ". The condition GET method can determine the specified resource if it is in IF-Modified-Since

The update has been updated after the specified date in the title field (see Section 10.9), which is not transmitted, otherwise it will not be transmitted. This condition GET

Allows the cached entity to refresh without having to pass multiple requests or unnecessary data transmission, thereby helping to reduce

Network load.

8.2 HEAD

The HEAD method is almost the same as get, the difference is that the HEAD method does not allow the server to return any implementation in response.

body. For the response part of the HEAD request, the meta information contained in its HTTP title is obtained by receiving the GET.

It is the same. By using this method, it is not necessary to transmit the entire entity body, you can get the request URI specified.

The meta information of the resource. This method is often used to test the legality, accessibility and recent update of hyperlinks.

Unlike conditions GET, there is no so-called "conditional head", ie "Conditional Head". It will also be ignored even if the IF-Modified-Since Title field is specified in the HEAD request.

8.3 POST

The POST method is used to send a request to the purpose, requiring it to accept the entity attached to the request and treat it as

Request-line requests additional new child of the resource specified by the URI. POST is designed with a unified

Methods implement the following functions:

o Annotation of existing resources for existing resources;

o Send a message to the electronic public bill, newsgroup, mailing list, or similar discussion group;

o Submit the data block, such as submitting the results of the form (Form [3]) to the data processing process;

o Extension the database by additional operation.

The actual function of the POST method is determined by the server, and is usually dependent on the request URI. During the POST process,

The entity is the slave part of the URI, as if the file is part of the directory containing it, the newsgroup file is subordinate to send this file.

The news group, which records the database from which it is its location.

Successful POST does not need to create an entity in the original server, and do it as a resource; no need to visit the future

provide conditions. That is, the POST method does not necessarily point to the resources specified by the URI. In this case, 200 (Cheng

Power) or 204 (no content) is all appropriate response status, depending on the description of the results in the actual response entity.

If a resource is created on the original server, the response should be 201 (created) and contain an entity

(The "Text / HTML" type is most suitable), which records the status description of the new resource request.

In all POST requests of all HTTP / 1.0, the legitimate length of content is required. Such as

If the HTTP / 1.0 server does not determine its length when receiving the request message content, it will return 400 (illegal request)

Code.

The application cannot cache the response to the POST request, because as an application, they have no way to know

How to respond in the future request.

9. Status Code Definition (STATUS CODE DEFINitions)

Each status code will be described below, including which method they will correspond, and all the letter required in response

interest.

9.1 Message 1xx (Information)

This type of state code is used to indicate a temporary response. The temporary response consists of status lines and optional titles.

Terminate by the blank line. No 1xx status code is defined in HTTP / 1.0, so they are not requested to HTTP / 1.0

Legal response. In fact, they are mainly used for experimental purposes, which has exceeded the scope of this document.

9.2 Success 2XX (Successful 2xx)

Indicates that the client request is successfully received, understood, and accepts.

200 OK

The request is successful. The information responded relies on the method used to request, as follows:

The resources you want to request have been placed in the entity responded.

HEAD has no entity main body, and only the title information is included in the response. Bamboo

POST entity (description or result of the result of the operation).

201 Created

The request is completed, and the result is a new resource. The URI of the newly created resource can be obtained in the entity responded. original

The start server should create this resource before issuing the status code. If the operation cannot be completed immediately, the server must give a prompt in the response body when the resource is available, otherwise, the server should receive 202 (acceptable).

The method defined herein, only POST can create resources.

202 ACCEPTED

The request is accepted, but the processing has not been completed. The request may not be finally completed, it is possible to be processed

When interrupt, in this case, there is no way to resend status code in asynchronous operation.

202 response is no obligation, this purpose is to allow the server to wait until the user agent and server

At the end of the connection, you can respond to the request of other processes (like running once a day, batch-based procedure).

In the entity returned in some response, including the status indication of the current request, status monitor pointer or user

Ask if the evaluation information can be implemented.

204 no content

The server has already implemented a request, but no new information is returned. If the customer is a user agent, don't need

Update your own document view for this purpose. This response is mainly in order to activate the document view without affecting the user agent.

Take it, the input and other operations of the SCRIPT statement. This response may also include new, entity title

The meta-form formula indicates that it can be used by the current user agent activating the document in the view.

9.3 Redirection (Redirection 3XX)

This type of state code indicates that the user agent wants to complete the request, and further operations need to be issued. These operations are only

When the request is a get or head, it can be implemented by the user agent without paying with the user.

mutual. The user agent will never do more than 5 redirection of the request, which may result in infinite cycle.

ring.

300 Multiple Choices

This status code is not used directly by the application of HTTP / 1.0, just the default interpretation of the 3xx type response.

There are multiple available requested resources.

Unless it is a HEAD request, the character list and location information of these resources must be included in the entity.

Which is the most suitable by the user or user agent.

If the server has the first choice, it should store the corresponding URL information at the location field,

The User Agent implements an automatic redirection based on the value of this domain.

301 MOVED Permanently

The requested resource allocates a permanent URL so that you can access this URL in the future.

Resource. The client with editing link is automatically updated according to the new link back by the server side.

Request URI.

The new URL must be specified by the location domain in the response. Entity main body responding unless it is a HEAD request

(Entity-Body) must include a brief description of the new URL hyperlink.

If a request is issued with a POST method, the 301 response status code is received. In this case, unless the user

Confirm, otherwise the user agent does not have to automatically redirect requests, as this will result in changing the environment that has been issued.

Note: Some existing user agents are automatically redirected when receiving the 301 status code

Will be incorrectly changed to the GET request.

302 MOVED TEMPORARILY

The requested resource is temporarily saved at a different URL. Because the redirection is sometimes changed, the client

The request URI should be continued to issue later requests.

The new URL must be specified by the location domain in the response. Entity main body responding unless it is a HEAD request

(Entity-Body) must include a brief description of the new URL hyperlink.

If a request is issued with a POST method, the 302 response status code is received. In this case, unless the user

Confirm, otherwise the user agent does not have to automatically redirect requests, as this will result in changing the environment that has been issued.

Note: When the POST request is automatically redirected after receiving a 302 status code, some existing user agents will incorrectly change it to the GET request.

304 Not Modified

If the client successfully executes the condition GET request, the corresponding file is specified from the IF-Modified-SINCE domain.

Since the date, there has been no updates, the server should respond to this status code, not send the entity main body to the guest

NOT. Responding to the title domain should only include some related information, such as the cache manager, recently updated with the entity.

(Entity's last-modified) date independent modification. Examples of the relevant header domain are: Date, Server,

expire date. Whenever the domain value given in the 304 response changes, the cache should be more

new.

9.4 Client Error 4xx

The status code of the 4XX class indicates an error in the client. If the client requests not completed when receiving 4xx code,

It should immediately terminate data to the server. In addition to responding to the HEAD request, regardless of the wrong or permanent

The server side must contain an interpretation of the error state in the entity responding. These status codes apply to any request method.

Note: If the client is sending data, the TCP implementation of the server side should be careful to ensure the client is

Receive the response package before passing the input connection. If the client is still sending data to the server after closing, the server will give the customer.

End Send a reset package, empty the input buffer that has not been processed, to terminate the reading, solution of the HTTP application

Release activities.

400 illegal requests (Bad Request)

If the requested syntax is wrong, the server will not understand. Before the client changes the request, it should not

The request is repeated to the server again.

401 unauthorized

Request user authorization. The WWW-Authenticate Title Domain (10.16) in response should be prompted

Request resources in an authorization manner. The client should use the appropriate authorized title domain (10.2) to repeat the request. in case

The authorization trust information has been included in the request, and the 401 responses indicates that this authorization is rejected. If the user agent is more

After the trial, the response or returns 401 status code, the user should check the entity responding, because

Some related dynamic information will be included in the entity. The HTTP Access Authorization will explain in Section 11.

403 prohibition (Forbidden)

Server understands the request, but refuses to implement the request. Authorization is not helpful, the client should stop repeating

Send this request. If not use the HEAD request method, and the server is willing to publish the request untimely

Under the premise, the server will write the rejection in the response entity. This status code is generally used for server-side do not want to announce

The request is rejected or there is no other response available.

404 did not find (Not found)

The server does not find resources that match the request URI. The 404 status code does not specify whether the situation is temporary or

Permanent. If the server does not want to provide this information for the client, the 403 (prohibition) status code is also responded.

9.5 Server Error 5xx

The response code indicates the status code starting at '5' to indicate that the server is found to have an error, and cannot continue to execute.

begging. If the client receives the 5xx status code, the request has not been completed, it should immediately stop sending numbers to the server

according to. In addition to responding to the HEAD request, the server should include the interpretation of the error in its response entity, and

Indicates that it is a temporary persistent.

This type of response code does not have a title domain, which can be applied to any request method.

500 Server Internal Error Server has encountered an unexpected situation that cannot continue to respond to requests.

501 unrealized (Not Implement)

The server is unable to provide support required for the request. If the server cannot identify the request method will return

This status should not be able to respond to any resources required to request.

502 illegal gateway (Bad Gateway)

A server that acts as a gateway or agent receives illegal responses from the UPStream server to send the request.

503 Service Unavailable (Service Unavailable)

The server is currently unable to handle the request. This is generally caused by the temporary overload or maintenance of the server. This state

The code suggests that the situation is temporary, and some delays are generated.

Note: The 503 status code does not imply that the server must return this status when overload. Some servers

It is desirable to use simple processing when overload, that is, disconnects the connection.

10. Title Domain Definitions (Header Field Definitions)

This section defines syntax and semantics commonly used in HTTP / 1.0 header domain. Whether it is sender or a receiver,

It may be the client or server side. The specific role depends on who is receiving at this time, who is sending.

10.1 Allow (Allow)

Indicates that the resource specified by the request URI is supported in the Allow entity title domain, with the purpose of receiving

The party clearly knows the legal way to request this resource. The Allow Title domain is not allowed to be used in the Post method, if not

To do this, it will be ignored.

Allow = "allow": "1 # method

Example of use:

Allow: get, head

This domain does not prevent the client from trying to other methods. But actually indication represented by the value in the Allow title domain

Information is useful and should be observed. The actual Allow method set is required to issue a request to the original server each time

Righteousness.

Since the user agent may communicate with the original server for other purposes, proxy

For example, even if all the methods specified by the request cannot be identified, the requested Allow Title domain cannot be modified.

The Allow Tita domain does not indicate which methods have been implemented.

10.2 Authorization

Typically, the user agent may (or may not) hope that the server will wish to be probably in the receiving 401 (unauthorized) response.

right. If you want to authorize, the user agent will join the authorization request title in the request (Authorization Request-HEADER)

area. The authorization domain value is composed of trust certificates, including authorization information on the user agent requesting resources.

Authorization = "Authorization": "Credentials": "Credentials

HTTP Access Authorization is described in Section 11. If the authorization in the request specifies a range, it is here

It also has the same trust relationship.

It is not possible to cache for requests that contain authorized information domains.

10.3 Content-encoding

Content encoding entity header domain (Entity-head) is used as a modifier of Media-Type. It indicates

To obtain an additional content decoding of resources, it is necessary to obtain a content type (content-type title).

Media types must be used with decoding mechanisms consistent with decoding. The content encoding is mainly used to record the compression method of the file. Various compression methods will be listed later.

Content-encoding = "content-encoding": "Content-Coding

Content Codings defines in Section 3.5, for example:

Content-encoding: X-Gzip

Content coding is a feature that requests URI specified resource. In general, resources are stored in encoding, only

Can be used after decoding the transformation.

10.4 Content Length (Content-Length)

Content-length entity title indicates an entity main body (entity-body) sent to the receiver

Length, decimal numbers stored in byte mode. For the Head method, its size is already in the previous GET.

Since it is issued.

Content-length = "content-length": "1 * DIGIT

E.g:

Content-Length: 3495

Regardless of the type of media, the application will determine the entity main body size to be transmitted through this domain. Instant

Request messages with HTTP / 1.0 including the entity main body must include legal content length values.

Any value of any 0 or more (including 0) is a legal content length value. In Section 7.2.2, it describes that when the content length value is not

How to give it to the method of responding to the physical main body length.

Note: The meaning of this domain is an important difference as defined in MIME. In MIME, it is an optional domain, only

Use in the "Message / External-Body" content type; in HTTP, the domain is decided before the entity is transmitted.

The length of the entity.

10.5 Content Type (Content-Type)

The content type entity title field indicates the length of the physical main body transmitted to the recipient. For Head methods, media classes

The type has been issued in the previous GET request.

Content-type = "content-type": "Media-Type

The media type is defined in Section 3.6, as in the following example:

Content-Type: Text / HTML

More discussions on media types in Section 1.2.1.

10.6 Date (Date)

Date General-header domain indicates the time of the message, its syntax is defined in RFC822

ORIG-date is the same. The domain value is an HTTP type, which is described in Section 3.3.

Date = "Date": "http-date

E.g:

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

If the message is received directly through the user agent (such as request) or the original server (such as response), the date can be

It is considered to be the current time of the receiving end. However, for the original server, the time of the time to respond to the cache is very heavy.

To, so, the original server will always include the date title. When the client is only sent to the entity,

Send a date title domain to the server, such as a POST request. If the received message is passed by the receiver or gateway

When the required protocol caches, the message will allocate one for it even if there is no date title domain.

In theory, the date should be generated when the entity is generated, and in fact, the date may be generated at any time of the message generation process without any adverse effects.

Note: Early versions are incorrectly defined as the date when the entity is packaged. This has been applied to the actual application

positive.

10.7 Expired (Expires)

The date / time value in the expired entity header domain specifies the time of the entity expired. This provides a letter to the information provider

Means of interest failure. When exceeds this period, the application should not be cached on this entity. Expired does not mean the original

The initial resource will change or stop the existence after this period. In practical applications, the information provider passes the expiration header domain.

The time specified in the presentation or predicts the exact date of the changes will change. This format is used by an absolute date

Room (Section 3.2).

Expires = "expiRes": "http-date

E.g:

Expires: THU, 01 DEC 1994 16:00:00 GMT

If the given date is higher than the date (or the same) in the date title, the recipient should not cache additional entities. If resource

It is dynamic naturally generated, like a lot of data, the entity of the resource should be plus an appropriate expiration time value.

The expiration domain does not force the user agent to refresh or reload resources, it is only used for cache mechanisms. Be right

When the initialized resource issues a new request, the mechanism checks the expiration state of the resource.

User agent usually has a history, such as the "Back" button and a list of history. This kind of mechanism can be used

Re-displays the entity information that has been acquired before the SESSION. In the default, the expiration domain is not a history machine.

Use. Unless the user specifies the expiration of the history file when configuring the user agent, as long as the entity is also guaranteed

Store, the historical mechanism can display it, regardless of whether the entity has expired.

Note: Applications should be compatible with illicit or erroneous implementations of expiration headers, such as touches 0 values ​​or illegal date formats.

Applications should be considered as "Expires Immediately". Although these values ​​do not meet HTTP / 1.0,

It is still necessary for a robust app.

10.8 from (from)

From request the title domain, if given, it should include an Internet of human users who use this user agent.

E-mail address. This address should be identified by the system, like the RFC822 [7] (already updated to RFC1123 [6])

The box definition is the same.

From = "from": "Mailbox

E.g:

From: webmaster@w3.org

The title domain may be used as a login purpose to determine if a request for a resource is legal. It does not apply

Safety access protection. The interpretation of this domain is that the request has been completed in the way the requestor specified, and the requestor will

The way is responsible. In special cases, the robot agent should also include this title domain, which indicates who is running it.

In this way, when any problems occur in the receiving end, you can contact this person.

The Internet E-MAIL address in this domain can be separated from the Internet host that processes the request. For example, when the request passes

When proxy, the original transmission address should be used.

Note: The client should not send the FROM title domain when it is not approved by the user, because this may result

User privacy and website security issues. It is highly recommended to provide a means to disable (disable), enable (enable), and modify the value of this domain.

10.9 When you change (if-modified-since)

If-modified-since requests the title domain and the get method for processing the following: when the domain is specified

Since the date, request resources have not changed any changes. At this time, the server will not submit the copy of the resource, namely, back

There should be no entity main body, just 304 status code (not modified).

If-modified-since = "if-modified-since": "http-date

E.g:

IF-Modified-Since: SAT, 29 OCT 1994 19:43:31 GMT

Condition GET method can request a change after the server will change after the specified date in the if-modified-since title domain.

The designated resource is submitted, that is, if the resource has not changed, it will not pass. Its algorithm is as follows:

a) If the response status of the request is not 200 (success) code or it is passing in the if-modified-scence

The date is not legal, and at this time, according to the ordinary Get. If the date is more than the current time of the server

That is late, it is illegal time.

b) If the resource changes after the if-modified-since date, the response is also the same as ordinary GET.

c) If the resource has not changed after the if-modified-since date, the server will respond to 304 (not modified).

Note: This date should be legal.

The purpose of this is to effectively update the cached information in order to minimize the cost.

10.10 Recent change (Last-Modified)

The Last-Modified entity title domain represents the resource set by the sender recently modified the date and time. Prefancy of this domain

The righteousness is how the recipient explains it: if the recipient has a copy of this resource, this copy rather than the last-modified domain

The time specified is old, the copy is expired.

Last-Modified = "Last-Modified": "http-date

E.g:

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

The precise meaning of the title domain depends on the execution method of the sender and the natural state of the original resource. For documents,

It may be its Last-Modified time in the file system. For entities that contain multiple components, it may be constructed

The latest Last-Modify time in the section. For the database gateway, it may be a recorded Last-Update timestamp. for

Virtual object, may be the nearest change time of the internal state.

The original server should not send a last-modified date that generates time than the server message, because the message will

Causes the server for a certain time in the future, the domain value is updated again with the original date.

10.11 Location (Location)

The Location response Title domain defines the location of the resource specified by the request URI. Respond for 3xx (redirect),

The location field must help the server find the corresponding URL to achieve redirection of resources. Only absolute URL is allowed.

Location = "location": "Absoluteuri

E.g:

Location: http://www.w3.org/hypertext/www/newlocation.html10.12 Note (PRAGMA)

The PRAMA normal title area includes some special instructions that may be useful for any recipient in the request / response chain.

From the perspective of the protocol, all annotations indicate some specific optional behaviors. In fact, some systems may require behavior.

Consistent with the indication.

Pragma = "Pragma" ":" 1 # pragma-directive

Pragma-Directive = "no-cache" | Extension-Pragma

Extension-pragma = token ["=" word]

When "NO-Cache" appears in the request message, the application should push this request to the original server, even if it has

A copy has been cached at the last request. This will ensure that the client can receive the most authoritative response. It is also used

Copying the copy is enforced when the copy is not available or expired in the client.

Regardless of the Note (PRAGMA) instruction information is important to the proxy and gateway applications,

It must pass these applications because the information may be useful for other recipients on the request / response chain. In fact, if

Instructed is not related to a recipient, it should be ignored by the receiver.

10.13 Submit (Referer)

The submission request title domain is for the consideration of server-side interests, allowing clients to indicate the source of the link, ie

The request URI that points to the resource address is obtained. In this way, the server will generate a backup link (Back-Links)

List, used to maintain activities such as resource, login, and cache optimization.

Referer = "Referer": "(Absoluteuri | Relativeuri)

example:

Referer: http://www.w3.org/hypertext/datasources/overview.html

If only part of the URI is given, you should refer to the request URI to explain it. The URI cannot include a section (Fragment).

Note: Because the original code of the link may expose some privacy information, it is strongly recommended by the user to decide whether to send

Submit the human domain. For example, a browser client has an option to make offline browsing, enable or prohibit the author or

The sending of form information.

10.14 Server (Server)

The server response the title domain contains software information used by the original server to process the request. This domain can contain multiple product standards

Knowledge (Section 3.7) and comments to identify servers and important subproducts. According to the habit, the product identification will be important according to its application.

Order order.

Server = "server": "1 * (Product | Comment)

E.g:

Server: CERN / 3.0 LIBWW / 2.17

If you respond to push through a proxy, the agent application should not add its own data to the product list.

Note: Some of the versions of the specified server software have an enlightenment because these versions of the software exists some security vulnerabilities.

Will make the server more vulnerable. Advocating server software When implementing, turn this domain into options that can be configured.

Note: Some servers do not follow the grammatical constraints of the server domain product identity.

10.15 User Agent (User-Agent)

The user agent request the title domain contains information of the user's original request, which can be used for statistical purposes. Automatically identify the user agent to avoid the limitations of special user agents to avoid the limitations of special user agents. Although there is no

Provisions, the user agent should include this domain in the request. This domain can include multiple product identifiers (Section 3.7) and annotations to identify

The agent and its important subproducts. According to habits, the product identification will be arranged in the order of the importance of the application.

User-agent = "user-agent": "1 * (Product | Comment)

E.g:

User-agent: Cern-linemode / 2.15 lowww / 2.17b3

Note: Existing agent applications return their product information to the user agency domain, this method is not worth promoting,

Because this will cause the machine to confuse when explaining this information.

Note: Some clients are now not complying with the syntax constraints of the product identity in the user agency domain.

10.16 WWW - Www-Authenticate

WWW-Authorized response The title field must be included in the 401 (unauthorized) response message. This domain value is from more than one

Challenge consists of these Challenges to indicate the authorization scheme and parameters of the request URI.

WWW-authenticate = "www-automate": "1 # challenge

HTTP Access Authorization Processing is described in Section 11. User agent should pay special attention to the analysis of WWW-authorized domain values

See if it contains more than more than one problem or no more than one WWW-authorized standard

The topic domain, because of the problem with the problem to be resolved, may include a list of authorized parameters separated by commas.

11. Access authentication (Access Authentication)

HTTP provides a simple challenge-response authentication mechanism that can be used for the server

The authorization information provided by the client is identified. Authorized program uses scalable, sensitive symbols

Know, followed by obtaining a comma-separated 'attribute-value' pair required.

Auth-scheme = token

Auth-param = token "=" quoted-string

The original server responds to the message with a 401 (unauthorized) to question the authorization of the user agent. This response must include WWW-

The authorized header domain, and the WWW-authorization title area includes more than one parameter for requesting resource authentication.

Challenge = auth-scheme 1 * sp reason * ("," auth-param)

Realm = "realm" "=" realm-value

Realm-value = quoted-string

Any authorization program involving parameters processing has a Realm property (case sensitive). With standard URL

(Part of the Realm value (also case sensitive) used in combination with access server root is used to define the protection area.

Realm makes the protected resource on the server in a special protection partition, and these areas have their own authorization.

And (or) authorized databases. The RELM value is a string, usually allocated by the original server, and for the authorization plan,

There may be some additional syntax processing issues.

Typically, the user agent may (or may not) expect the server to authorize it when receiving a 401 (unauthorized) response. If you want to authorize, the user agent will join the authorization request title in the request (Authorization Request-HEADER)

area. The authorization domain value is composed of trust certificates, including authorization information on the user agent requesting resources.

Credentials = Basic-Credentials

| (Auth-scheme # auth-param)

The area that can be accessed by the user agent through the trust mode is determined by the protection area. If the earlier request has been recognized

Certificate, other requests can be the same within the time interval specified by the authorization scheme, parameters, and / or user selection, etc.

Trust to access the protection area.

Unless otherwise specified by the authorization, the range of a single protection area cannot be extended to the server.

If the server does not want to accept trust by request, it should return 403 (forbidden) response.

Access authorization of the HTTP protocol is not limited to this simple challenge response mechanism,

Use other methods, such as transport grade encryption or message packaging, and by additional title domains. but,

These methods are not discussed in this document.

The agent must completely transparently handle the authorization of the user, that is, they must be in the premise of do not do any changes.

WWW-Authorization and Authorization Title are pushed forward or caches to include authorized responses. HTTP / 1.0 is not passenger

Number offers methods authorized by proxy.

11.1 Basic Authentication Scheme

User agent must be awarded itself through user ID (User-ID) and password for each domain.

Right, this is the working mode of the basic authorization program. Realm value should be seen as an opaque string, which will be used in the same service

Compare the other REALM value of the server. Only the user ID and password pass through the certification of the protected resource, the server will give

Request authorization. Authorized parameters have no options.

When receiving unauthenticated resource requests for protected areas, the server should respond to a question.

(Challenge) as follows:

WWW-Authenticate: Basic Realm = "WallyWorld"

"WallyWorld" is a string allocated by the server for labeting the protected resources specified by the request URI.

knowledge.

In order to receive authorization, the client needs to send a user ID and password in a certificate based on 64-bit (Base64 [5]).

In the middle, the colon ':' is separated.

Basic-credentials = "Basic" sp Basic-cookie

Basic-cookie =

Except Not Limited to 76 Char / Line>

Userid-password = [token] ":" * text

If the user agent wants to send the user to identify "ALADDIN" and password "Open SESAME", the following title should be followed.

Domain form:

Authorization: Basic Qwxhzgrpbjpvcgvuihnlc2ftzq ==

The BASIC Authorization Scheme is a non-secure method for filtering the unauthorized access of the HTTP server resource. It is based on fake

The connection to the client and the server is safe. Why is it assumed, because in the actual open network, use the Basic authorization plan often there are many unsafe places. Despite this, the client still needs this program to

Communicates with a server adopted in this order.

12. Safety considerations (Security Considance)

The description of this section is related to the following roles: information application developer, information provider, HTTP / 1.0 security

Limited users. This section is only to discuss security issues and put forward recommendations on reducing hidden dangers, but does not provide the most

Final solution.

12.1 Customer Authentication Of Clients

As mentioned in Section 11.1, the Basic Authentication scheme is not a secure user authorization plan.

It is also not possible to prevent the physical source of the entity from being transmitted in the physical network in text. HTTP / 1.0 is not against current

Adoption of other licensing methods and encryption mechanisms in front of the increasing security issues.

12.2 Safety Method (SAFE Methods)

Client software developers should note that client software represents users with other aspects on the Internet, and should

Note that avoiding the user knows the specific action between it, these actions may expose a letter to the interaction parties.

interest.

In particular, in accordance with the agreement, the GET and HEAD methods should be considered safe, and the data should be obtained.

When there is no difference. This allows the user agent to adopt other methods, such as POST, in some case, there may be this

One case, that is, the request contains unsafe behavior.

Typically, after the server is executed after the GET request, the by-products such as the result remains on the server;

In addition, some dynamic resources require this feature to be implemented. The important difference here is that users have not requested these by-products.

Therefore, such requests should not be explained.

12.3 Disadvantages of Server Log Information (Abuse of Server Log

Information information

The server provides space to save personal data related to the user request, such as reading methods or the subject of interest, and the like.

These storage information is obviously protected by certain national laws, so the processing of such data should be careful. HTTP

Part of the agreement to provide data should be responsible for ensuring that this information will not spread out before the partition is permitted.

12.4 Sensitive Information Transport (Transfer of Sensitive Information)

Like other protocols, the HTTP protocol cannot adjust the content of the transmitted data, and there is no method of nothing.

The context information segment of the given request can speculate on the sensitivity of the information. Thus, the application should be as far as possible

Like the information provider, more control is provided for this information. Here, there are three heading domains worth mentioning: Server,

Referr and from (from).

Some of the version of the specified server software has a revelation, because these versions of the software have some security vulnerabilities, will make

The server is more vulnerable to attack. Advocating the server software When implementing, turn the Server title field into the selection of configurable

item.

The Referer Title domain allows the reading pattern to be exposed and the reverse link can be exported.

Although this domain is useful, if the user information contained in this domain is not separated, its effect is likely to be abused.

use. In addition, even if the user information is cleared in this domain, the URI of its private file can still be speculated from other information in this domain, which may be that the information publisher wants to see.

From the (from) Title domain may include some information related to user private privacy and site security, so

Before sending data, users should allow users to use some settings, such as disable, allowing (enable), and modifications

(Modify), configure this domain information. Users should be able to use their choices or use the lack of application

Provincial configuration to set the content of this domain.

We recommend, but do not make requirements: provide users with convenient interfaces to allow (disable) or disabled

Send information from the FROM domain or the Referer domain.

12.5 Attacks Based on File and Path Name

Path Names)

The implementation of the HTTP original server should pay attention to the name of the server administrator, for a file

HTTP request is restricted. If the HTTP server sends the HTTP URI to the system call, the server is special

Note that when a request file is not sent to the HTTP client, you should reject the service. For example, in UNIX, Microsoft

Windows and other operating systems use ".." as the superior directory name. Under such systems, the HTTP server side

Other ranges of other HTTP servers must be prohibited from accessing the HTTP server. Similarly, service

Some files used inside the server, including access control files, configuration files, script code, etc., also subject to special insurance

Protect to avoid being illegally requested to obtain, lead to exposure of system sensitive information. Experimental prove, even the smallest bug, you can

Can lead to serious security issues.

13. Thank you (ACKNOWLEDGMENTS)

This document focuses on the supplemental feedback method (Augment BNF) and by David H. Crocker in RFC822 [7]

General structure defined in. Similarly, it uses many by Nathaniel Borenstein and Ned Freed for MIME [5]

Many definitions do. We hope to reduce the relationship between HTTP / 1.0 and MAIL messages.

The HTTP protocol has developed very quickly in the past four years, but it benefits from a huge and active development group - is them, these

Participate in the WWW discussion of the mail list to create HTTP success in a global scale. 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 Vanheynnen, they put a huge energy for the earlier versions of this document. Paul Hoffman

Provides information about the information status, and the contents of Appendix C, D.

This document has benefited from the commentary of HTTP-WG members. The following is people who contribute to this specification:

Gary Adams Harald Tveit Alvestrand

Keith Ball Brian Behlendorf

Paul Burchard Maurizio Codognomike 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-Flatin

14. Reference book (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 name

Objects on the network as buy 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. Author's address (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

This information appears in the appendix only one reason, that is, they have not become an integral part of the HTTP / 1.0 specification.

A. Internet Media Type Message / HTTP (Internet Media Type

Message / http)

As a supplement to the HTTP / 1.0 protocol, this document is a specification for Internet Media Types "Message / HTTP". the following

The content is registered in IANA [13].

Media Type name: Message

Media Subtype Name: http

Required Parameters: NONE

Optional parameters: Version, MSGTYPE

Version: The HTTP version number of additional messages, such as "1.0". If not given, version

This can be obtained from the first row of its main body.

Message Type (MSGTYPE): Message Type - Request or Respond. in case

No, the version can be obtained from the first row of its main body.

Encoding Considances: Only "7bit", "8bit", or "binary" is allowed.

Security considerations: Noneb. Way tolerant Applications

Although this document indicates the necessary conditions for generating HTTP / 1.0 messages, not all applications are corrected their

achieve. Therefore, we recommend that the application enhances its fault tolerance, so that when you can still be explicitly explained, it can also guarantee

normal operation.

When the client parsing status row (Status-line) and server resolution request line, it should be accommodated.

wrong. In particular, even if only one SP is separated, they can also accept any number of SP or HT words.

Splitted domain.

The row termination of the HTTP header domain is the sequence character CRLF. And we recommend that the application is resolving such titles,

It should also be identified as a terminator condition for a single LF (no previous CR).

C. Relationship with MIME (RELATIONSHIP to MIME)

HTTP / 1.0 uses many Internet mail (RFC822 [7]) and multi-purpose Internet mail extensions

(MULTIPURPOSE Internet Mail Extensions) MIME [5] defined structure to allow entities to pass one open

Scalable mechanisms are transmitted. In fact, some characteristics in HTTP are different from the emails discussed in RFC1521, these

Difference to optimize the performance of binary transmission, provide greater degrees of freedom to the use of media types, making the date comparison

It is easier, of course, this is also a compatible application of some of the early HTTP servers and client applications.

When writing this article, it is said that RFC1521 will be revised. The revision will include some appearance in HTTP / 1.0.

Existing applications, but these applications are not included in the current RFC1521.

The appendix describes the differences in HTTP and RFC 1521. When the agent and gateway restricts the MIME environment,

These differences are noted, and the corresponding conversion support is provided at the time. Proxy and network from MIME to HTTP environment

It is also important to pay attention to these differences because some conversions may be necessary.

C.1 Conversion to specification form (Conversion to Canonical Form)

RFC1521 requires Internet mail entities to convert to specific forms before transmitting, just as RFC1521 [5] Appendix C

As described in it. The subclass of the "TEXT" media type allowed during transmission is described in this document.

Specific form of type.

RFC1521 requires "text" content type (content-type) must use CRLF as a line break break, prohibited separately

Use CR or LF. HTTP allows the use of CRLF when HTTP transmission, separate CR or LF as a line break.

As long as it is possible, the agent or gateway in the HTTP environment or the RFC1521 environment should be described in this document 3.6.1.

All row interruptions in the text media type are converted to CRLF. Note that due to the existence of content encoding

(Content-Encoding) Issues, and HTTP allows multi-character sets, and some of these characters are not byte

13 and 10 are CR and LF, so that the actual processing is more complicated.

C.2 Date Format Conversion (Conversion of Date Formats)

HTTP / 1.0 uses the restricted date format set (Section 3.3) to simplify the process of date comparison. Other agreement agent

And the gateway should ensure that any date the title field in the message is consistent with the HTTP / 1.0 format, otherwise it is rewritten.

C.3 Content Coding Introduction Of Content-Encoding

RFC1521 does not include concepts such as the content encoding the title field in HTTP / 1.0. Since the content type domain is the medium

Type modification, thus the proxy and gateway from the HTTP to MIME compatibility protocol must be pushed forward before pushing the message.

Change the value of the content type title domain or decode the entity main body (entity-body) (some

The experimental application of Internet Mail content type is "CONVERSIS =

Instead of the content decoding, in fact, this parameter is not an integral part of the RFC 1521).

C.4 No content Transmission Coding (no content-transfer-encoding)

HTTP does not use the CTE (Content-Transfer-Encoding) domain of RFC1521. Compatible with MIME protocol

Agent and gateway must clear any not identified CTE encoding before passing the response message to the HTTP client.

("Quoted-printable" or "base64").

Proxy and gateways from HTTP to MIME compatibility protocols should be responsible for ensuring the correct and encoding transmission of messages on the protocol

Safety, so-called secure transmission refers to the restrictions or constraints that meet the corresponding protocols. The agent or gateway should be appropriate

Content-Transfer-Encoding to identify data to improve secure transmission on the destination protocol

The possibility.

C.5 HTTP Title Domain of Multiple Main Bodes (HTTP Header Fields in

Multipart Body-Parts)

In RFC1521, most of the headings that make up of multiple subjects are usually ignored unless their domain name is "Content-".

head. In HTTP / 1.0, any HTTP title field included in multiple subject ports, only

It makes sense for the corresponding part.

D. Additional Features (Additional Features)

Some protocol elements included in this appendix are present in some HTTP implementations, but not for all HTTP / 1.0

Applicable applications. Developers should pay attention to these features, but they cannot rely on them to do with other HTTP / 1.0 applications.

Interact.

D.1 Additional Request Methods (Additional Request Methods)

D.1.1 PUT

The PUT method requesting the server stores the entity of the attachment in the request URI. If the request URI points to

The resource already exists, and the accessory entity should be seen as a modified version of the resource on the current original server. If request URI

Did not point to existing resources, the URI will be defined by the requested user agent becomes a new resource, original server

This resource will be generated with this URI.

The basic difference between the POST and PUT two requests is that the understanding of the request URI is different. In the POST request method

The resources identified by the URI will be processed as an accessory entity, which may be a data receiving process, a certain

Some other protocols of the gateway, or individual entities that can be annotated. In contrast, the user agent is very clear that the PUT it will be issued.

Ask the entity identified by the URI to point, and the server should not be used on other resource headers.

D.1.2 Delete

The delete method requests the original server to delete the resources specified by the request URI.

D.1.3 LINK

The LINK method establishes one or more connection relationships between the resource specified by the request URI or other existing resources.

D.1.4 unlink

UNLINK method Deletes one or more connection relationships between the resources specified by the request URI. D.2 Additional Title Domain Definitions (Additional Header Field Definitions)

D.2.1 ACCEPT

The Accept request title domain is used to indicate a list of media ranges that can be accepted. Asterisk "*" for scope

Grouping media types, indicating all media types with "* / *"; use "type / *" instruction to accept all types of TYPE types

Subtype. For a given context, the client should indicate which types are it acceptable.

D.2.2 Acceptable font set (Accept-charset)

The ACCEPT-CHARSET request Title domain is used to indicate the preferred character set in addition to US-ASCII and ISO-8859-1.

This domain will enable the client to understand or have a broader or special-purpose character set, which can be stored on the server.

This type of document of this type of character set.

D.2.3 Accept coding (Accept-encoding)

Accept-encoding request The title field is similar to Accept, but limits the acceptable content encoding in response.

Content-Coding value.

D.2.4 Accept-language (Accept-Language)

Accept-language request The title domain is similar to Accept, but limits the preferred natural language set in the request response.

D.2.5 Content Language (Content-Language)

The Content-Language entity header domain describes the natural language specified in additional entities. Note that this may

The various languages ​​used inside the entity are not a code.

D.2.6 Connection (LINK)

The LINK entity title domain describes the relationship between entities and certain other resources. An entity may include multiple connections

value. LINK in the meta-information level indicates the relationship between the hierarchical structure and the navigation path.

D.2.7 MIME version (MIME-VERSION)

HTTP messages may include a single MIME version of the general-header domain for indicating

The version of the MIME protocol used to construct messages. The use of the MIME version of the title is as defined in RFC1521 [5].

In that case, it should be used to indicate whether the message complies with the MIME specification. However, unfortunately, some old HTTP / 1.0 servers

This domain is not allowed to send this domain, causing this domain to be discarded.

D.2.8 is in .... Retroyal-After

Retry-after response The title field can be used with 503 (service unavailable), which is used to indicate the server stopping

The length of time should be requested. The value of this domain can be represented by the date in the HTTP format, or when using an integer to repay

The number of seconds after room.

D.2.9 Title (Title)

Title entity Title domain is used to indicate the title of the entity.

D.2.10 URI

The URI entity title may contain some or all of the uniform resource identifiers, see

Section 3.2, through these identities to represent the resource specified by the request URI. Not guaranteed to be specified according to URI

H.

RFC1945 - HYPTERText Transfer Protocol - HTTP / 1.0 Hypertext Transfer Protocol 1.0

转载请注明原文地址:https://www.9cbs.com/read-32327.html

New Post(0)