分享
 
 
 

http1.1---2

王朝other·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

RFC 2068 HTTP/1.1 January 1997

to the count of elements present. That is, "(element), , (element)

" is permitted, but counts as only two elements. Therefore, where

at least one element is required, at least one non-null element

must be present. Default values are 0 and infinity so that

"#element" allows any number, including zero; "1#element" requires

at least one; and "1#2element" allows one or two.

; comment

A semi-colon, set off some distance to the right of rule text,

starts a comment that continues to the end of line. This is a

simple way of including useful notes in parallel with the

specifications.

implied *LWS

The grammar described by this specification is word-based. Except

where noted otherwise, linear whitespace (LWS) can be included

between any two adjacent words (token or quoted-string), and

between adjacent tokens and delimiters (tspecials), without

changing the interpretation of a field. At least one delimiter

(tspecials) must exist between any two tokens, since they would

otherwise be interpreted as a single token.

2.2 Basic Rules

The following rules are used throughout this specification to

describe basic parsing constructs. The US-ASCII coded character set

is defined by ANSI X3.4-1986 [21].

OCTET = <any 8-bit sequence of data>

CHAR = <any US-ASCII character (octets 0 - 127)>

UPALPHA = <any US-ASCII uppercase letter "A".."Z">

LOALPHA = <any US-ASCII lowercase letter "a".."z">

ALPHA = UPALPHA | LOALPHA

DIGIT = <any US-ASCII digit "0".."9">

CTL = <any US-ASCII control character

(octets 0 - 31) and DEL (127)>

CR = <US-ASCII CR, carriage return (13)>

LF = <US-ASCII LF, linefeed (10)>

SP = <US-ASCII SP, space (32)>

HT = <US-ASCII HT, horizontal-tab (9)>

<"> = <US-ASCII double-quote mark (34)>

Fielding, et. al. Standards Track [Page 15]

RFC 2068 HTTP/1.1 January 1997

HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all

protocol elements except the entity-body (see appendix 19.3 for

tolerant applications). The end-of-line marker within an entity-body

is defined by its associated media type, as described in section 3.7.

CRLF = CR LF

HTTP/1.1 headers can be folded onto multiple lines if the

continuation line begins with a space or horizontal tab. All linear

white space, including folding, has the same semantics as SP.

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

The TEXT rule is only used for descriptive field contents and values

that are not intended to be interpreted by the message parser. Words

of *TEXT may contain characters from character sets other than ISO

8859-1 [22] only when encoded according to the rules of RFC 1522

[14].

TEXT = <any OCTET except CTLs,

but including LWS>

Hexadecimal numeric characters are used in several protocol elements.

HEX = "A" | "B" | "C" | "D" | "E" | "F"

| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

Many HTTP/1.1 header field values consist of words separated by LWS

or special characters. These special characters MUST be in a quoted

string to be used within a parameter value.

token = 1*<any CHAR except CTLs or tspecials>

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

| "," | ";" | ":" | "\" | <">

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

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

Comments can be included in some HTTP header fields by surrounding

the comment text with parentheses. Comments are only allowed in

fields containing "comment" as part of their field value definition.

In all other fields, parentheses are considered part of the field

value.

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

ctext = <any TEXT excluding "(" and ")">

Fielding, et. al. Standards Track [Page 16]

RFC 2068 HTTP/1.1 January 1997

A string of text is parsed as a single word if it is quoted using

double-quote marks.

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

qdtext = <any TEXT except <">>

The backslash character ("\") may be used as a single-character quoting

mechanism only within quoted-string and comment constructs.

quoted-pair = "\" CHAR

3 Protocol Parameters

3.1 HTTP Version

HTTP uses a "<major>.<minor>" numbering scheme to indicate versions

of the protocol. The protocol versioning policy is intended to allow

the sender to indicate the format of a message and its capacity for

understanding further HTTP communication, rather than the features

obtained via that communication. No change is made to the version

number for the addition of message components which do not affect

communication behavior or which only add to extensible field values.

The <minor> number is incremented when the changes made to the

protocol add features which do not change the general message parsing

algorithm, but which may add to the message semantics and imply

additional capabilities of the sender. The <major> number is

incremented when the format of a message within the protocol is

changed.

The version of an HTTP message is indicated by an HTTP-Version field

in the first line of the message.

HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT

Note that the major and minor numbers MUST be treated as separate

integers and that each may be incremented higher than a single digit.

Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is

lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and

MUST NOT be sent.

Applications sending Request or Response messages, as defined by this

specification, MUST include an HTTP-Version of "HTTP/1.1". Use of

this version number indicates that the sending application is at

least conditionally compliant with this specification.

The HTTP version of an application is the highest HTTP version for

which the application is at least conditionally compliant.

Fielding, et. al. Standards Track [Page 17]

RFC 2068 HTTP/1.1 January 1997

Proxy and gateway applications must be careful when forwarding

messages in protocol versions different from that of the application.

Since the protocol version indicates the protocol capability of the

sender, a proxy/gateway MUST never send a message with a version

indicator which is greater than its actual version; if a higher

version request is received, the proxy/gateway MUST either downgrade

the request version, respond with an error, or switch to tunnel

behavior. Requests with a version lower than that of the

proxy/gateway's version MAY be upgraded before being forwarded; the

proxy/gateway's response to that request MUST be in the same major

version as the request.

Note: Converting between versions of HTTP may involve modification

of header fields required or forbidden by the versions involved.

3.2 Uniform Resource Identifiers

URIs have been known by many names: WWW addresses, Universal Document

Identifiers, Universal Resource Identifiers , and finally the

combination of Uniform Resource Locators (URL) and Names (URN). As

far as HTTP is concerned, Uniform Resource Identifiers are simply

formatted strings which identify--via name, location, or any other

characteristic--a resource.

3.2.1 General Syntax

URIs in HTTP can be represented in absolute form or relative to some

known base URI, depending upon the context of their use. The two

forms are differentiated by the fact that absolute URIs always begin

with a scheme name followed by a colon.

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 | "/" )

Fielding, et. al. Standards Track [Page 18]

RFC 2068 HTTP/1.1 January 1997

scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )

net_loc = *( pchar | ";" | "?" )

query = *( uchar | reserved )

fragment = *( uchar | reserved )

pchar = uchar | ":" | "@" | "&" | "=" | "+"

uchar = unreserved | escape

unreserved = ALPHA | DIGIT | safe | extra | national

escape = "%" HEX HEX

reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"

extra = "!" | "*" | "'" | "(" | ")" | ","

safe = "$" | "-" | "_" | "."

unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"

national = <any OCTET excluding ALPHA, DIGIT,

reserved, extra, safe, and unsafe>

For definitive information on URL syntax and semantics, see RFC 1738

[4] and RFC 1808 [11]. The BNF above includes national characters not

allowed in valid URLs as specified by RFC 1738, since HTTP servers

are not restricted in the set of unreserved characters allowed to

represent the rel_path part of addresses, and HTTP proxies may

receive requests for URIs not defined by RFC 1738.

The HTTP protocol does not place any a priori limit on the length of

a URI. Servers MUST be able to handle the URI of any resource they

serve, and SHOULD be able to handle URIs of unbounded length if they

provide GET-based forms that could generate such URIs. A server

SHOULD return 414 (Request-URI Too Long) status if a URI is longer

than the server can handle (see section 10.4.15).

Note: Servers should be cautious about depending on URI lengths

above 255 bytes, because some older client or proxy implementations

may not properly support these lengths.

3.2.2 http URL

The "http" scheme is used to locate network resources via the HTTP

protocol. This section defines the scheme-specific syntax and

semantics for http URLs.

Fielding, et. al. Standards Track [Page 19]

RFC 2068 HTTP/1.1 January 1997

http_URL = "http:" "//" host [ ":" port ] [ abs_path ]

host = <A legal Internet host domain name

or IP address (in dotted-decimal form),

as defined by Section 2.1 of RFC 1123>

port = *DIGIT

If the port is empty or not given, port 80 is assumed. The semantics

are that the identified resource is located at the server listening

for TCP connections on that port of that host, and the Request-URI

for the resource is abs_path. The use of IP addresses in URL's SHOULD

be avoided whenever possible (see RFC 1900 [24]). If the abs_path is

not present in the URL, it MUST be given as "/" when used as a

Request-URI for a resource (section 5.1.2).

3.2.3 URI Comparison

When comparing two URIs to decide if they match or not, a client

SHOULD use a case-sensitive octet-by-octet comparison of the entire

URIs, with these exceptions:

o A port that is empty or not given is equivalent to the default

port for that URI;

o Comparisons of host names MUST be case-insensitive;

o Comparisons of scheme names MUST be case-insensitive;

o An empty abs_path is equivalent to an abs_path of "/".

Characters other than those in the "reserved" and "unsafe" sets (see

section 3.2) are equivalent to their ""%" HEX HEX" encodings.

For example, the following three URIs are equivalent:

http://abc.com:80/~smith/home.html

http://ABC.com/%7Esmith/home.html

http://ABC.com:/%7esmith/home.html

Fielding, et. al. Standards Track [Page 20]

RFC 2068 HTTP/1.1 January 1997

3.3 Date/Time Formats

3.3.1 Full Date

HTTP applications have historically allowed three different formats

for the representation of date/time stamps:

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 preferred as an Internet standard and represents

a fixed-length subset of that defined by RFC 1123 (an update to RFC

822). The second format is in common use, but is based on the

obsolete RFC 850 [12] date format and lacks a four-digit year.

HTTP/1.1 clients and servers that parse the date value MUST accept

all three formats (for compatibility with HTTP/1.0), though they MUST

only generate the RFC 1123 format for representing HTTP-date values

in header fields.

Note: Recipients of date values are encouraged to be robust in

accepting date values that may have been sent by non-HTTP

applications, as is sometimes the case when retrieving or posting

messages via proxies/gateways to SMTP or NNTP.

All HTTP date/time stamps MUST be represented in Greenwich Mean Time

(GMT), without exception. This is indicated in the first two formats

by the inclusion of "GMT" as the three-letter abbreviation for time

zone, and MUST be assumed when reading the asctime format.

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"

Fielding, et. al. Standards Track [Page 21]

RFC 2068 HTTP/1.1 January 1997

weekday = "Monday" | "Tuesday" | "Wednesday"

| "Thursday" | "Friday" | "Saturday" | "Sunday"

month = "Jan" | "Feb" | "Mar" | "Apr"

| "May" | "Jun" | "Jul" | "Aug"

| "Sep" | "Oct" | "Nov" | "Dec"

Note: HTTP requirements for the date/time stamp format apply only

to their usage within the protocol stream. Clients and servers are

not required to use these formats for user presentation, request

logging, etc.

3.3.2 Delta Seconds

Some HTTP header fields allow a time value to be specified as an

integer number of seconds, represented in decimal, after the time

that the message was received.

delta-seconds = 1*DIGIT

3.4 Character Sets

HTTP uses the same definition of the term "character set" as that

described for MIME:

The term "character set" is used in this document to refer to a

method used with one or more tables to convert a sequence of octets

into a sequence of characters. Note that unconditional conversion

in the other direction is not required, in that not all characters

may be available in a given character set and a character set may

provide more than one sequence of octets to represent a particular

character. This definition is intended to allow various kinds of

character encodings, from simple single-table mappings such as US-

ASCII to complex table switching methods such as those that use ISO

2022's techniques. However, the definition associated with a MIME

character set name MUST fully specify the mapping to be performed

from octets to characters. In particular, use of external profiling

information to determine the exact mapping is not permitted.

Note: This use of the term "character set" is more commonly

referred to as a "character encoding." However, since HTTP and MIME

share the same registry, it is important that the terminology also

be shared.

Fielding, et. al. Standards Track [Page 22]

RFC 2068 HTTP/1.1 January 1997

HTTP character sets are identified by case-insensitive tokens. The

complete set of tokens is defined by the IANA Character Set registry

[19].

charset = token

Although HTTP allows an arbitrary token to be used as a charset

value, any token that has a predefined value within the IANA

Character Set registry MUST represent the character set defined by

that registry. Applications SHOULD limit their use of character sets

to those defined by the IANA registry.

3.5 Content Codings

Content coding values indicate an encoding transformation that has

been or can be applied to an entity. Content codings are primarily

used to allow a document to be compressed or otherwise usefully

transformed without losing the identity of its underlying media type

and without loss of information. Frequently, the entity is stored in

coded form, transmitted directly, and only decoded by the recipient.

content-coding = token

All content-coding values are case-insensitive. HTTP/1.1 uses

content-coding values in the Accept-Encoding (section 14.3) and

Content-Encoding (section 14.12) header fields. Although the value

describes the content-coding, what is more important is that it

indicates what decoding mechanism will be required to remove the

encoding.

The Internet Assigned Numbers Authority (IANA) acts as a registry for

content-coding value tokens. Initially, the registry contains the

following tokens:

gzip An encoding format produced by the file compression program "gzip"

(GNU zip) as described in RFC 1952 [25]. This format is a Lempel-

Ziv coding (LZ77) with a 32 bit CRC.

compress

The encoding format produced by the common UNIX file compression

program "compress". This format is an adaptive Lempel-Ziv-Welch

coding (LZW).

Fielding, et. al. Standards Track [Page 23]

RFC 2068 HTTP/1.1 January 1997

Note: Use of program names for the identification of encoding

formats is not desirable and should be discouraged for future

encodings. Their use here is representative of historical practice,

not good design. For compatibility with previous implementations of

HTTP, applications should consider "x-gzip" and "x-compress" to be

equivalent to "gzip" and "compress" respectively.

deflate The "zlib" format defined in RFC 1950[31] in combination with

the "deflate" compression mechanism described in RFC 1951[29].

New content-coding value tokens should be registered; to allow

interoperability between clients and servers, specifications of the

content coding algorithms needed to implement a new value should be

publicly available and adequate for independent implementation, and

conform to the purpose of content coding defined in this section.

3.6 Transfer Codings

Transfer coding values are used to indicate an encoding

transformation that has been, can be, or may need to be applied to an

entity-body in order to ensure "safe transport" through the network.

This differs from a content coding in that the transfer coding is a

property of the message, not of the original entity.

transfer-coding = "chunked" | transfer-extension

transfer-extension = token

All transfer-coding values are case-insensitive. HTTP/1.1 uses

transfer coding values in the Transfer-Encoding header field (section

14.40).

Transfer codings are analogous to the Content-Transfer-Encoding

values of MIME , which were designed to enable safe transport of

binary data over a 7-bit transport service. However, safe transport

has a different focus for an 8bit-clean transfer protocol. In HTTP,

the only unsafe characteristic of message-bodies is the difficulty in

determining the exact body length (section 7.2.2), or the desire to

encrypt data over a shared transport.

The chunked encoding modifies the body of a message in order to

transfer it as a series of chunks, each with its own size indicator,

followed by an optional footer containing entity-header fields. This

allows dynamically-produced content to be transferred along with the

information necessary for the recipient to verify that it has

received the full message.

Fielding, et. al. Standards Track [Page 24]

RFC 2068 HTTP/1.1 January 1997

Chunked-Body = *chunk

"0" CRLF

footer

CRLF

chunk = chunk-size [ chunk-ext ] CRLF

chunk-data CRLF

hex-no-zero = <HEX excluding "0">

chunk-size = hex-no-zero *HEX

chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )

chunk-ext-name = token

chunk-ext-val = token | quoted-string

chunk-data = chunk-size(OCTET)

footer = *entity-header

The chunked encoding is ended by a zero-sized chunk followed by the

footer, which is terminated by an empty line. The purpose of the

footer is to provide an efficient way to supply information about an

entity that is generated dynamically; applications MUST NOT send

header fields in the footer which are not explicitly defined as being

appropriate for the footer, such as Content-MD5 or future extensions

to HTTP for digital signatures or other facilities.

An example process for decoding a Chunked-Body is presented in

appendix 19.4.6.

All HTTP/1.1 applications MUST be able to receive and decode the

"chunked" transfer coding, and MUST ignore transfer coding extensions

they do not understand. A server which receives an entity-body with a

transfer-coding it does not understand SHOULD return 501

(Unimplemented), and close the connection. A server MUST NOT send

transfer-codings to an HTTP/1.0 client.

3.7 Media Types

HTTP uses Internet Media Types in the Content-Type (section 14.18)

and Accept (section 14.1) header fields in order to provide open and

extensible data typing and type negotiation.

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

type = token

subtype = token

Parameters may follow the type/subtype in the form of attribute/value

pairs.

Fielding, et. al. Standards Track [Page 25]

RFC 2068 HTTP/1.1 January 1997

parameter = attribute "=" value

attribute = token

value = token | quoted-string

The type, subtype, and parameter attribute names are case-

insensitive. Parameter values may or may not be case-sensitive,

depending on the semantics of the parameter name. Linear white space

(LWS) MUST NOT be used between the type and subtype, nor between an

attribute and its value. User agents that recognize the media-type

MUST process (or arrange to be processed by any external applications

used to process that type/subtype by the user agent) the parameters

for that MIME type as described by that type/subtype definition to

the and inform the user of any problems discovered.

Note: some older HTTP applications do not recognize media type

parameters. When sending data to older HTTP applications,

implementations should only use media type parameters when they are

required by that type/subtype definition.

Media-type values are registered with the Internet Assigned Number

Authority (IANA). The media type registration process is outlined in

RFC 2048 [17]. Use of non-registered media types is discouraged.

3.7.1 Canonicalization and Text Defaults

Internet media types are registered with a canonical form. In

general, an entity-body transferred via HTTP messages MUST be

represented in the appropriate canonical form prior to its

transmission; the exception is "text" types, as defined in the next

paragraph.

When in canonical form, media subtypes of the "text" type use CRLF as

the text line break. HTTP relaxes this requirement and allows the

transport of text media with plain CR or LF alone representing a line

break when it is done consistently for an entire entity-body. HTTP

applications MUST accept CRLF, bare CR, and bare LF as being

representative of a line break in text media received via HTTP. In

addition, if the text is represented in a character set that does not

use octets 13 and 10 for CR and LF respectively, as is the case for

some multi-byte character sets, HTTP allows the use of whatever octet

sequences are defined by that character set to represent the

equivalent of CR and LF for line breaks. This flexibility regarding

line breaks applies only to text media in the entity-body; a bare CR

or LF MUST NOT be substituted for CRLF within any of the HTTP control

structures (such as header fields and multipart boundaries).

If an entity-body is encoded with a Content-Encoding, the underlying

data MUST be in a form defined above prior to being encoded.

Fielding, et. al. Standards Track [Page 26]

RFC 2068 HTTP/1.1 January 1997

The "charset" parameter is used with some media types to define the

character set (section 3.4) of the data. When no explicit charset

parameter is provided by the sender, media subtypes of the "text"

type are defined to have a default charset value of "ISO-8859-1" when

received via HTTP. Data in character sets other than "ISO-8859-1" or

its subsets MUST be labeled with an appropriate charset value.

Some HTTP/1.0 software has interpreted a Content-Type header without

charset parameter incorrectly to mean "recipient should guess."

Senders wishing to defeat this behavior MAY include a charset

parameter even when the charset is ISO-8859-1 and SHOULD do so when

it is known that it will not confuse the recipient.

Unfortunately, some older HTTP/1.0 clients did not deal properly with

an explicit charset parameter. HTTP/1.1 recipients MUST respect the

charset label provided by the sender; and those user agents that have

a provision to "guess" a charset MUST use the charset from the

content-type field if they support that charset, rather than the

recipient's preference, when initially displaying a document.

3.7.2 Multipart Types

MIME provides for a number of "multipart" types -- encapsulations of

one or more entities within a single message-body. All multipart

types share a common syntax, as defined in MIME [7], and MUST

include a boundary parameter as part of the media type value. The

message body is itself a protocol element and MUST therefore use only

CRLF to represent line breaks between body-parts. Unlike in MIME, the

epilogue of any multipart message MUST be empty; HTTP applications

MUST NOT transmit the epilogue (even if the original multipart

contains an epilogue).

In HTTP, multipart body-parts MAY contain header fields which are

significant to the meaning of that part. A Content-Location header

field (section 14.15) SHOULD be included in the body-part of each

enclosed entity that can be identified by a URL.

In general, an HTTP user agent SHOULD follow the same or similar

behavior as a MIME user agent would upon receipt of a multipart type.

If an application receives an unrecognized multipart subtype, the

application MUST treat it as being equivalent to "multipart/mixed".

Note: The "multipart/form-data" type has been specifically defined

for carrying form data suitable for processing via the POST request

method, as described in RFC 1867 [15].

Fielding, et. al. Standards Track [Page 27]

RFC 2068 HTTP/1.1 January 1997

3.8 Product Tokens

Product tokens are used to allow communicating applications to

identify themselves by software name and version. Most fields using

product tokens also allow sub-products which form a significant part

of the application to be listed, separated by whitespace. By

convention, the products are listed in order of their significance

for identifying the application.

product = token ["/" product-version]

product-version = token

Examples:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Server: Apache/0.8.4

Product tokens should be short and to the point -- use of them for

advertising or other non-essential information is explicitly

forbidden. Although any token character may appear in a product-

version, this token SHOULD only be used for a version identifier

(i.e., successive versions of the same product SHOULD only differ in

the product-version portion of the product value).

3.9 Quality Values

HTTP content negotiation (section 12) uses short "floating point"

numbers to indicate the relative importance ("weight") of various

negotiable parameters. A weight is normalized to a real number in the

range 0 through 1, where 0 is the minimum and 1 the maximum value.

HTTP/1.1 applications MUST NOT generate more than three digits after

the decimal point. User configuration of these values SHOULD also be

limited in this fashion.

qvalue = ( "0" [ "." 0*3DIGIT ] )

| ( "1" [ "." 0*3("0") ] )

"Quality values" is a misnomer, since these values merely represent

relative degradation in desired quality.

3.10 Language Tags

A language tag identifies a natural language spoken, written, or

otherwise conveyed by human beings for communication of information

to other human beings. Computer languages are explicitly excluded.

HTTP uses language tags within the Accept-Language and Content-

Language fields.

谁翻译了别忘了给我发一份 xzjxu@126.com

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有