分享
 
 
 

http1.1---9

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

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

RFC 2068 HTTP/1.1 January 1997

In theory, the date SHOULD represent the moment just before the

entity is generated. In practice, the date can be generated at any

time during the message origination without affecting its semantic

value.

The format of the Date is an absolute date and time as defined by

HTTP-date in section 3.3; it MUST be sent in RFC1123 [8]-date format.

14.20 ETag

The ETag entity-header field defines the entity tag for the

associated entity. The headers used with entity tags are described in

sections 14.20, 14.25, 14.26 and 14.43. The entity tag may be used

for comparison with other entities from the same resource (see

section 13.3.2).

ETag = "ETag" ":" entity-tag

Examples:

ETag: "xyzzy"

ETag: W/"xyzzy"

ETag: ""

14.21 Expires

The Expires entity-header field gives the date/time after which the

response should be considered stale. A stale cache entry may not

normally be returned by a cache (either a proxy cache or an user

agent cache) unless it is first validated with the origin server (or

with an intermediate cache that has a fresh copy of the entity). See

section 13.2 for further discussion of the expiration model.

The presence of an Expires field does not imply that the original

resource will change or cease to exist at, before, or after that

time.

The format is an absolute date and time as defined by HTTP-date in

section 3.3; it MUST be in RFC1123-date format:

Expires = "Expires" ":" HTTP-date

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

RFC 2068 HTTP/1.1 January 1997

An example of its use is

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Note: if a response includes a Cache-Control field with the max-age

directive, that directive overrides the Expires field.

HTTP/1.1 clients and caches MUST treat other invalid date formats,

especially including the value "0", as in the past (i.e., "already

expired").

To mark a response as "already expired," an origin server should use

an Expires date that is equal to the Date header value. (See the

rules for expiration calculations in section 13.2.4.)

To mark a response as "never expires," an origin server should use an

Expires date approximately one year from the time the response is

sent. HTTP/1.1 servers should not send Expires dates more than one

year in the future.

The presence of an Expires header field with a date value of some

time in the future on an response that otherwise would by default be

non-cacheable indicates that the response is cachable, unless

indicated otherwise by a Cache-Control header field (section 14.9).

14.22 From

The From request-header field, if given, SHOULD contain an Internet

e-mail address for the human user who controls the requesting user

agent. The address SHOULD be machine-usable, as defined by mailbox

in RFC 822 (as updated by RFC 1123 ):

From = "From" ":" mailbox

An example is:

From: webmaster@w3.org

This header field MAY be used for logging purposes and as a means for

identifying the source of invalid or unwanted requests. It SHOULD NOT

be used as an insecure form of access protection. The interpretation

of this field is that the request is being performed on behalf of the

person given, who accepts responsibility for the method performed. In

particular, robot agents SHOULD include this header so that the

person responsible for running the robot can be contacted if problems

occur on the receiving end.

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

RFC 2068 HTTP/1.1 January 1997

The Internet e-mail address in this field MAY be separate from the

Internet host which issued the request. For example, when a request

is passed through a proxy the original issuer's address SHOULD be

used.

Note: The client SHOULD not send the From header field without the

user's approval, as it may conflict with the user's privacy

interests or their site's security policy. It is strongly

recommended that the user be able to disable, enable, and modify

the value of this field at any time prior to a request.

14.23 Host

The Host request-header field specifies the Internet host and port

number of the resource being requested, as obtained from the original

URL given by the user or referring resource (generally an HTTP URL,

as described in section 3.2.2). The Host field value MUST represent

the network location of the origin server or gateway given by the

original URL. This allows the origin server or gateway to

differentiate between internally-ambiguous URLs, such as the root "/"

URL of a server for multiple host names on a single IP address.

Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

A "host" without any trailing port information implies the default

port for the service requested (e.g., "80" for an HTTP URL). For

example, a request on the origin server for

<http://www.w3.org/pub/WWW/> MUST include:

GET /pub/WWW/ HTTP/1.1

Host: www.w3.org

A client MUST include a Host header field in all HTTP/1.1 request

messages on the Internet (i.e., on any message corresponding to a

request for a URL which includes an Internet host address for the

service being requested). If the Host field is not already present,

an HTTP/1.1 proxy MUST add a Host field to the request message prior

to forwarding it on the Internet. All Internet-based HTTP/1.1 servers

MUST respond with a 400 status code to any HTTP/1.1 request message

which lacks a Host header field.

See sections 5.2 and 19.5.1 for other requirements relating to Host.

14.24 If-Modified-Since

The If-Modified-Since request-header field is used with the GET

method to make it conditional: if the requested variant has not been

modified since the time specified in this field, an entity will not

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

RFC 2068 HTTP/1.1 January 1997

be returned from the server; instead, a 304 (not modified) response

will be returned without any message-body.

If-Modified-Since = "If-Modified-Since" ":" HTTP-date

An example of the field is:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

A GET method with an If-Modified-Since header and no Range header

requests that the identified entity be transferred only if it has

been modified since the date given by the If-Modified-Since header.

The algorithm for determining this includes the following cases:

a)If the request would normally result in anything other than a 200

(OK) status, or if the passed If-Modified-Since date is invalid, the

response is exactly the same as for a normal GET. A date which is

later than the server's current time is invalid.

b)If the variant has been modified since the If-Modified-Since date,

the response is exactly the same as for a normal GET.

c)If the variant has not been modified since a valid If-Modified-Since

date, the server MUST return a 304 (Not Modified) response.

The purpose of this feature is to allow efficient updates of cached

information with a minimum amount of transaction overhead.

Note that the Range request-header field modifies the meaning of

If-Modified-Since; see section 14.36 for full details.

Note that If-Modified-Since times are interpreted by the server,

whose clock may not be synchronized with the client.

Note that if a client uses an arbitrary date in the If-Modified-Since

header instead of a date taken from the Last-Modified header for the

same request, the client should be aware of the fact that this date

is interpreted in the server's understanding of time. The client

should consider unsynchronized clocks and rounding problems due to

the different encodings of time between the client and server. This

includes the possibility of race conditions if the document has

changed between the time it was first requested and the If-Modified-

Since date of a subsequent request, and the possibility of clock-

skew-related problems if the If-Modified-Since date is derived from

the client's clock without correction to the server's clock.

Corrections for different time bases between client and server are at

best approximate due to network latency.

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

RFC 2068 HTTP/1.1 January 1997

14.25 If-Match

The If-Match request-header field is used with a method to make it

conditional. A client that has one or more entities previously

obtained from the resource can verify that one of those entities is

current by including a list of their associated entity tags in the

If-Match header field. The purpose of this feature is to allow

efficient updates of cached information with a minimum amount of

transaction overhead. It is also used, on updating requests, to

prevent inadvertent modification of the wrong version of a resource.

As a special case, the value "*" matches any current entity of the

resource.

If-Match = "If-Match" ":" ( "*" | 1#entity-tag )

If any of the entity tags match the entity tag of the entity that

would have been returned in the response to a similar GET request

(without the If-Match header) on that resource, or if "*" is given

and any current entity exists for that resource, then the server MAY

perform the requested method as if the If-Match header field did not

exist.

A server MUST use the strong comparison function (see section 3.11)

to compare the entity tags in If-Match.

If none of the entity tags match, or if "*" is given and no current

entity exists, the server MUST NOT perform the requested method, and

MUST return a 412 (Precondition Failed) response. This behavior is

most useful when the client wants to prevent an updating method, such

as PUT, from modifying a resource that has changed since the client

last retrieved it.

If the request would, without the If-Match header field, result in

anything other than a 2xx status, then the If-Match header MUST be

ignored.

The meaning of "If-Match: *" is that the method SHOULD be performed

if the representation selected by the origin server (or by a cache,

possibly using the Vary mechanism, see section 14.43) exists, and

MUST NOT be performed if the representation does not exist.

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

RFC 2068 HTTP/1.1 January 1997

A request intended to update a resource (e.g., a PUT) MAY include an

If-Match header field to signal that the request method MUST NOT be

applied if the entity corresponding to the If-Match value (a single

entity tag) is no longer a representation of that resource. This

allows the user to indicate that they do not wish the request to be

successful if the resource has been changed without their knowledge.

Examples:

If-Match: "xyzzy"

If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"

If-Match: *

14.26 If-None-Match

The If-None-Match request-header field is used with a method to make

it conditional. A client that has one or more entities previously

obtained from the resource can verify that none of those entities is

current by including a list of their associated entity tags in the

If-None-Match header field. The purpose of this feature is to allow

efficient updates of cached information with a minimum amount of

transaction overhead. It is also used, on updating requests, to

prevent inadvertent modification of a resource which was not known to

exist.

As a special case, the value "*" matches any current entity of the

resource.

If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )

If any of the entity tags match the entity tag of the entity that

would have been returned in the response to a similar GET request

(without the If-None-Match header) on that resource, or if "*" is

given and any current entity exists for that resource, then the

server MUST NOT perform the requested method. Instead, if the request

method was GET or HEAD, the server SHOULD respond with a 304 (Not

Modified) response, including the cache-related entity-header fields

(particularly ETag) of one of the entities that matched. For all

other request methods, the server MUST respond with a status of 412

(Precondition Failed).

See section 13.3.3 for rules on how to determine if two entity tags

match. The weak comparison function can only be used with GET or HEAD

requests.

If none of the entity tags match, or if "*" is given and no current

entity exists, then the server MAY perform the requested method as if

the If-None-Match header field did not exist.

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

RFC 2068 HTTP/1.1 January 1997

If the request would, without the If-None-Match header field, result

in anything other than a 2xx status, then the If-None-Match header

MUST be ignored.

The meaning of "If-None-Match: *" is that the method MUST NOT be

performed if the representation selected by the origin server (or by

a cache, possibly using the Vary mechanism, see section 14.43)

exists, and SHOULD be performed if the representation does not exist.

This feature may be useful in preventing races between PUT

operations.

Examples:

If-None-Match: "xyzzy"

If-None-Match: W/"xyzzy"

If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"

If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"

If-None-Match: *

14.27 If-Range

If a client has a partial copy of an entity in its cache, and wishes

to have an up-to-date copy of the entire entity in its cache, it

could use the Range request-header with a conditional GET (using

either or both of If-Unmodified-Since and If-Match.) However, if the

condition fails because the entity has been modified, the client

would then have to make a second request to obtain the entire current

entity-body.

The If-Range header allows a client to "short-circuit" the second

request. Informally, its meaning is `if the entity is unchanged, send

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

entity.'

If-Range = "If-Range" ":" ( entity-tag | HTTP-date )

If the client has no entity tag for an entity, but does have a Last-

Modified date, it may use that date in a If-Range header. (The server

can distinguish between a valid HTTP-date and any form of entity-tag

by examining no more than two characters.) The If-Range header should

only be used together with a Range header, and must be ignored if the

request does not include a Range header, or if the server does not

support the sub-range operation.

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

RFC 2068 HTTP/1.1 January 1997

If the entity tag given in the If-Range header matches the current

entity tag for the entity, then the server should provide the

specified sub-range of the entity using a 206 (Partial content)

response. If the entity tag does not match, then the server should

return the entire entity using a 200 (OK) response.

14.28 If-Unmodified-Since

The If-Unmodified-Since request-header field is used with a method to

make it conditional. If the requested resource has not been modified

since the time specified in this field, the server should perform the

requested operation as if the If-Unmodified-Since header were not

present.

If the requested variant has been modified since the specified time,

the server MUST NOT perform the requested operation, and MUST return

a 412 (Precondition Failed).

If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date

An example of the field is:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

If the request normally (i.e., without the If-Unmodified-Since

header) would result in anything other than a 2xx status, the If-

Unmodified-Since header should be ignored.

If the specified date is invalid, the header is ignored.

14.29 Last-Modified

The Last-Modified entity-header field indicates the date and time at

which the origin server believes the variant was last modified.

Last-Modified = "Last-Modified" ":" HTTP-date

An example of its use is

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

The exact meaning of this header field depends on the implementation

of the origin server and the nature of the original resource. For

files, it may be just the file system last-modified time. For

entities with dynamically included parts, it may be the most recent

of the set of last-modify times for its component parts. For database

gateways, it may be the last-update time stamp of the record. For

virtual objects, it may be the last time the internal state changed.

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

RFC 2068 HTTP/1.1 January 1997

An origin server MUST NOT send a Last-Modified date which is later

than the server's time of message origination. In such cases, where

the resource's last modification would indicate some time in the

future, the server MUST replace that date with the message

origination date.

An origin server should obtain the Last-Modified value of the entity

as close as possible to the time that it generates the Date value of

its response. This allows a recipient to make an accurate assessment

of the entity's modification time, especially if the entity changes

near the time that the response is generated.

HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.

14.30 Location

The Location response-header field is used to redirect the recipient

to a location other than the Request-URI for completion of the

request or identification of a new resource. For 201 (Created)

responses, the Location is that of the new resource which was created

by the request. For 3xx responses, the location SHOULD indicate the

server's preferred URL for automatic redirection to the resource. The

field value consists of a single absolute URL.

Location = "Location" ":" absoluteURI

An example is

Location: http://www.w3.org/pub/WWW/People.html

Note: The Content-Location header field (section 14.15) differs

from Location in that the Content-Location identifies the original

location of the entity enclosed in the request. It is therefore

possible for a response to contain header fields for both Location

and Content-Location. Also see section 13.10 for cache requirements

of some methods.

14.31 Max-Forwards

The Max-Forwards request-header field may be used with the TRACE

method (section 14.31) to limit the number of proxies or gateways

that can forward the request to the next inbound server. This can be

useful when the client is attempting to trace a request chain which

appears to be failing or looping in mid-chain.

Max-Forwards = "Max-Forwards" ":" 1*DIGIT

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

RFC 2068 HTTP/1.1 January 1997

The Max-Forwards value is a decimal integer indicating the remaining

number of times this request message may be forwarded.

Each proxy or gateway recipient of a TRACE request containing a Max-

Forwards header field SHOULD check and update its value prior to

forwarding the request. If the received value is zero (0), the

recipient SHOULD NOT forward the request; instead, it SHOULD respond

as the final recipient with a 200 (OK) response containing the

received request message as the response entity-body (as described in

section 9.8). If the received Max-Forwards value is greater than

zero, then the forwarded message SHOULD contain an updated Max-

Forwards field with a value decremented by one (1).

The Max-Forwards header field SHOULD be ignored for all other methods

defined by this specification and for any extension methods for which

it is not explicitly referred to as part of that method definition.

14.32 Pragma

The Pragma general-header field is used to include implementation-

specific directives that may apply to any recipient along the

request/response chain. All pragma directives specify optional

behavior from the viewpoint of the protocol; however, some systems

MAY require that behavior be consistent with the directives.

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

pragma-directive = "no-cache" | extension-pragma

extension-pragma = token [ "=" ( token | quoted-string ) ]

When the no-cache directive is present in a request message, an

application SHOULD forward the request toward the origin server even

if it has a cached copy of what is being requested. This pragma

directive has the same semantics as the no-cache cache-directive (see

section 14.9) and is defined here for backwards compatibility with

HTTP/1.0. Clients SHOULD include both header fields when a no-cache

request is sent to a server not known to be HTTP/1.1 compliant.

Pragma directives MUST be passed through by a proxy or gateway

application, regardless of their significance to that application,

since the directives may be applicable to all recipients along the

request/response chain. It is not possible to specify a pragma for a

specific recipient; however, any pragma directive not relevant to a

recipient SHOULD be ignored by that recipient.

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

RFC 2068 HTTP/1.1 January 1997

HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1

caches SHOULD treat "Pragma: no-cache" as if the client had sent

"Cache-Control: no-cache". No new Pragma directives will be defined

in HTTP.

14.33 Proxy-Authenticate

The Proxy-Authenticate response-header field MUST be included as part

of a 407 (Proxy Authentication Required) response. The field value

consists of a challenge that indicates the authentication scheme and

parameters applicable to the proxy for this Request-URI.

Proxy-Authenticate = "Proxy-Authenticate" ":" challenge

The HTTP access authentication process is described in section 11.

Unlike WWW-Authenticate, the Proxy-Authenticate header field applies

only to the current connection and SHOULD NOT be passed on to

downstream clients. However, an intermediate proxy may need to obtain

its own credentials by requesting them from the downstream client,

which in some circumstances will appear as if the proxy is forwarding

the Proxy-Authenticate header field.

14.34 Proxy-Authorization

The Proxy-Authorization request-header field allows the client to

identify itself (or its user) to a proxy which requires

authentication. The Proxy-Authorization field value consists of

credentials containing the authentication information of the user

agent for the proxy and/or realm of the resource being requested.

Proxy-Authorization = "Proxy-Authorization" ":" credentials

The HTTP access authentication process is described in section 11.

Unlike Authorization, the Proxy-Authorization header field applies

only to the next outbound proxy that demanded authentication using

the Proxy-Authenticate field. When multiple proxies are used in a

chain, the Proxy-Authorization header field is consumed by the first

outbound proxy that was expecting to receive credentials. A proxy MAY

relay the credentials from the client request to the next proxy if

that is the mechanism by which the proxies cooperatively authenticate

a given request.

14.35 Public

The Public response-header field lists the set of methods supported

by the server. The purpose of this field is strictly to inform the

recipient of the capabilities of the server regarding unusual

methods. The methods listed may or may not be applicable to the

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

RFC 2068 HTTP/1.1 January 1997

Request-URI; the Allow header field (section 14.7) MAY be used to

indicate methods allowed for a particular URI.

Public = "Public" ":" 1#method

Example of use:

Public: OPTIONS, MGET, MHEAD, GET, HEAD

This header field applies only to the server directly connected to

the client (i.e., the nearest neighbor in a chain of connections). If

the response passes through a proxy, the proxy MUST either remove the

Public header field or replace it with one applicable to its own

capabilities.

14.36 Range

14.36.1 Byte Ranges

Since all HTTP entities are represented in HTTP messages as sequences

of bytes, the concept of a byte range is meaningful for any HTTP

entity. (However, not all clients and servers need to support byte-

range operations.)

Byte range specifications in HTTP apply to the sequence of bytes in

the entity-body (not necessarily the same as the message-body).

A byte range operation may specify a single range of bytes, or a set

of ranges within a single entity.

ranges-specifier = byte-ranges-specifier

byte-ranges-specifier = bytes-unit "=" byte-range-set

byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )

byte-range-spec = first-byte-pos "-" [last-byte-pos]

first-byte-pos = 1*DIGIT

last-byte-pos = 1*DIGIT

The first-byte-pos value in a byte-range-spec gives the byte-offset

of the first byte in a range. The last-byte-pos value gives the

byte-offset of the last byte in the range; that is, the byte

positions specified are inclusive. Byte offsets start at zero.

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

RFC 2068 HTTP/1.1 January 1997

If the last-byte-pos value is present, it must be greater than or

equal to the first-byte-pos in that byte-range-spec, or the byte-

range-spec is invalid. The recipient of an invalid byte-range-spec

must ignore it.

If the last-byte-pos value is absent, or if the value is greater than

or equal to the current length of the entity-body, last-byte-pos is

taken to be equal to one less than the current length of the entity-

body in bytes.

By its choice of last-byte-pos, a client can limit the number of

bytes retrieved without knowing the size of the entity.

suffix-byte-range-spec = "-" suffix-length

suffix-length = 1*DIGIT

A suffix-byte-range-spec is used to specify the suffix of the

entity-body, of a length given by the suffix-length value. (That is,

this form specifies the last N bytes of an entity-body.) If the

entity is shorter than the specified suffix-length, the entire

entity-body is used.

Examples of byte-ranges-specifier values (assuming an entity-body of

length 10000):

o The first 500 bytes (byte offsets 0-499, inclusive):

bytes=0-499

o The second 500 bytes (byte offsets 500-999, inclusive):

bytes=500-999

o The final 500 bytes (byte offsets 9500-9999, inclusive):

bytes=-500

o Or

bytes=9500-

o The first and last bytes only (bytes 0 and 9999):

bytes=0-0,-1

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

RFC 2068 HTTP/1.1 January 1997

o Several legal but not canonical specifications of the second

500 bytes (byte offsets 500-999, inclusive):

bytes=500-600,601-999

bytes=500-700,601-999

14.36.2 Range Retrieval Requests

HTTP retrieval requests using conditional or unconditional GET

methods may request one or more sub-ranges of the entity, instead of

the entire entity, using the Range request header, which applies to

the entity returned as the result of the request:

Range = "Range" ":" ranges-specifier

A server MAY ignore the Range header. However, HTTP/1.1 origin

servers and intermediate caches SHOULD support byte ranges when

possible, since Range supports efficient recovery from partially

failed transfers, and supports efficient partial retrieval of large

entities.

If the server supports the Range header and the specified range or

ranges are appropriate for the entity:

o The presence of a Range header in an unconditional GET modifies

what is returned if the GET is otherwise successful. In other

words, the response carries a status code of 206 (Partial

Content) instead of 200 (OK).

o The presence of a Range header in a conditional GET (a request

using one or both of If-Modified-Since and If-None-Match, or

one or both of If-Unmodified-Since and If-Match) modifies what

is returned if the GET is otherwise successful and the condition

is true. It does not affect the 304 (Not Modified) response

returned if the conditional is false.

In some cases, it may be more appropriate to use the If-Range header

(see section 14.27) in addition to the Range header.

If a proxy that supports ranges receives a Range request, forwards

the request to an inbound server, and receives an entire entity in

reply, it SHOULD only return the requested range to its client. It

SHOULD store the entire received response in its cache, if that is

consistent with its cache allocation policies.

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

RFC 2068 HTTP/1.1 January 1997

14.37 Referer

The Referer[sic] request-header field allows the client to specify,

for the server's benefit, the address (URI) of the resource from

which the Request-URI was obtained (the "referrer", although the

header field is misspelled.) The Referer request-header allows a

server to generate lists of back-links to resources for interest,

logging, optimized caching, etc. It also allows obsolete or mistyped

links to be traced for maintenance. The Referer field MUST NOT be

sent if the Request-URI was obtained from a source that does not have

its own URI, such as input from the user keyboard.

Referer = "Referer" ":" ( absoluteURI | relativeURI )

Example:

Referer: http://www.w3.org/hypertext/DataSources/Overview.html

If the field value is a partial URI, it SHOULD be interpreted

relative to the Request-URI. The URI MUST NOT include a fragment.

Note: Because the source of a link may be private information or

may reveal an otherwise private information source, it is strongly

recommended that the user be able to select whether or not the

Referer field is sent. For example, a browser client could have a

toggle switch for browsing openly/anonymously, which would

respectively enable/disable the sending of Referer and From

information.

14.38 Retry-After

The Retry-After response-header field can be used with a 503 (Service

Unavailable) response to indicate how long the service is expected to

be unavailable to the requesting client. The value of this field can

be either an HTTP-date or an integer number of seconds (in decimal)

after the time of the response.

Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )

Two examples of its use are

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT

Retry-After: 120

In the latter example, the delay is 2 minutes.

谁翻译了别忘了给我发一份 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- 王朝網路 版權所有