分享
 
 
 

http1.1---10

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

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

RFC 2068 HTTP/1.1 January 1997

14.39 Server

The Server response-header field contains information about the

software used by the origin server to handle the request. The field

can contain multiple product tokens (section 3.8) and comments

identifying the server and any significant subproducts. The product

tokens are listed in order of their significance for identifying the

application.

Server = "Server" ":" 1*( product | comment )

Example:

Server: CERN/3.0 libwww/2.17

If the response is being forwarded through a proxy, the proxy

application MUST NOT modify the Server response-header. Instead, it

SHOULD include a Via field (as described in section 14.44).

Note: Revealing the specific software version of the server may

allow the server machine to become more vulnerable to attacks

against software that is known to contain security holes. Server

implementers are encouraged to make this field a configurable

option.

14.40 Transfer-Encoding

The Transfer-Encoding general-header field indicates what (if any)

type of transformation has been applied to the message body in order

to safely transfer it between the sender and the recipient. This

differs from the Content-Encoding in that the transfer coding is a

property of the message, not of the entity.

Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-

coding

Transfer codings are defined in section 3.6. An example is:

Transfer-Encoding: chunked

Many older HTTP/1.0 applications do not understand the Transfer-

Encoding header.

14.41 Upgrade

The Upgrade general-header allows the client to specify what

additional communication protocols it supports and would like to use

if the server finds it appropriate to switch protocols. The server

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

RFC 2068 HTTP/1.1 January 1997

MUST use the Upgrade header field within a 101 (Switching Protocols)

response to indicate which protocol(s) are being switched.

Upgrade = "Upgrade" ":" 1#product

For example,

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

The Upgrade header field is intended to provide a simple mechanism

for transition from HTTP/1.1 to some other, incompatible protocol. It

does so by allowing the client to advertise its desire to use another

protocol, such as a later version of HTTP with a higher major version

number, even though the current request has been made using HTTP/1.1.

This eases the difficult transition between incompatible protocols by

allowing the client to initiate a request in the more commonly

supported protocol while indicating to the server that it would like

to use a "better" protocol if available (where "better" is determined

by the server, possibly according to the nature of the method and/or

resource being requested).

The Upgrade header field only applies to switching application-layer

protocols upon the existing transport-layer connection. Upgrade

cannot be used to insist on a protocol change; its acceptance and use

by the server is optional. The capabilities and nature of the

application-layer communication after the protocol change is entirely

dependent upon the new protocol chosen, although the first action

after changing the protocol MUST be a response to the initial HTTP

request containing the Upgrade header field.

The Upgrade header field only applies to the immediate connection.

Therefore, the upgrade keyword MUST be supplied within a Connection

header field (section 14.10) whenever Upgrade is present in an

HTTP/1.1 message.

The Upgrade header field cannot be used to indicate a switch to a

protocol on a different connection. For that purpose, it is more

appropriate to use a 301, 302, 303, or 305 redirection response.

This specification only defines the protocol name "HTTP" for use by

the family of Hypertext Transfer Protocols, as defined by the HTTP

version rules of section 3.1 and future updates to this

specification. Any token can be used as a protocol name; however, it

will only be useful if both the client and server associate the name

with the same protocol.

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

RFC 2068 HTTP/1.1 January 1997

14.42 User-Agent

The User-Agent request-header field contains information about the

user agent originating the request. This is for statistical purposes,

the tracing of protocol violations, and automated recognition of user

agents for the sake of tailoring responses to avoid particular user

agent limitations. User agents SHOULD include this field with

requests. The field can contain multiple product tokens (section 3.8)

and comments identifying the agent and any subproducts which form a

significant part of the user agent. By convention, the product tokens

are listed in order of their significance for identifying the

application.

User-Agent = "User-Agent" ":" 1*( product | comment )

Example:

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

14.43 Vary

The Vary response-header field is used by a server to signal that the

response entity was selected from the available representations of

the response using server-driven negotiation (section 12). Field-

names listed in Vary headers are those of request-headers. The Vary

field value indicates either that the given set of header fields

encompass the dimensions over which the representation might vary, or

that the dimensions of variance are unspecified ("*") and thus may

vary over any aspect of future requests.

Vary = "Vary" ":" ( "*" | 1#field-name )

An HTTP/1.1 server MUST include an appropriate Vary header field with

any cachable response that is subject to server-driven negotiation.

Doing so allows a cache to properly interpret future requests on that

resource and informs the user agent about the presence of negotiation

on that resource. A server SHOULD include an appropriate Vary header

field with a non-cachable response that is subject to server-driven

negotiation, since this might provide the user agent with useful

information about the dimensions over which the response might vary.

The set of header fields named by the Vary field value is known as

the "selecting" request-headers.

When the cache receives a subsequent request whose Request-URI

specifies one or more cache entries including a Vary header, the

cache MUST NOT use such a cache entry to construct a response to the

new request unless all of the headers named in the cached Vary header

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

RFC 2068 HTTP/1.1 January 1997

are present in the new request, and all of the stored selecting

request-headers from the previous request match the corresponding

headers in the new request.

The selecting request-headers from two requests are defined to match

if and only if the selecting request-headers in the first request can

be transformed to the selecting request-headers in the second request

by adding or removing linear whitespace (LWS) at places where this is

allowed by the corresponding BNF, and/or combining multiple message-

header fields with the same field name following the rules about

message headers in section 4.2.

A Vary field value of "*" signals that unspecified parameters,

possibly other than the contents of request-header fields (e.g., the

network address of the client), play a role in the selection of the

response representation. Subsequent requests on that resource can

only be properly interpreted by the origin server, and thus a cache

MUST forward a (possibly conditional) request even when it has a

fresh response cached for the resource. See section 13.6 for use of

the Vary header by caches.

A Vary field value consisting of a list of field-names signals that

the representation selected for the response is based on a selection

algorithm which considers ONLY the listed request-header field values

in selecting the most appropriate representation. A cache MAY assume

that the same selection will be made for future requests with the

same values for the listed field names, for the duration of time in

which the response is fresh.

The field-names given are not limited to the set of standard

request-header fields defined by this specification. Field names are

case-insensitive.

14.44 Via

The Via general-header field MUST be used by gateways and proxies to

indicate the intermediate protocols and recipients between the user

agent and the server on requests, and between the origin server and

the client on responses. It is analogous to the "Received" field of

RFC 822 and is intended to be used for tracking message forwards,

avoiding request loops, and identifying the protocol capabilities of

all senders along the request/response chain.

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

RFC 2068 HTTP/1.1 January 1997

Via = "Via" ":" 1#( received-protocol received-by [ comment ] )

received-protocol = [ protocol-name "/" ] protocol-version

protocol-name = token

protocol-version = token

received-by = ( host [ ":" port ] ) | pseudonym

pseudonym = token

The received-protocol indicates the protocol version of the message

received by the server or client along each segment of the

request/response chain. The received-protocol version is appended to

the Via field value when the message is forwarded so that information

about the protocol capabilities of upstream applications remains

visible to all recipients.

The protocol-name is optional if and only if it would be "HTTP". The

received-by field is normally the host and optional port number of a

recipient server or client that subsequently forwarded the message.

However, if the real host is considered to be sensitive information,

it MAY be replaced by a pseudonym. If the port is not given, it MAY

be assumed to be the default port of the received-protocol.

Multiple Via field values represent each proxy or gateway that has

forwarded the message. Each recipient MUST append its information

such that the end result is ordered according to the sequence of

forwarding applications.

Comments MAY be used in the Via header field to identify the software

of the recipient proxy or gateway, analogous to the User-Agent and

Server header fields. However, all comments in the Via field are

optional and MAY be removed by any recipient prior to forwarding the

message.

For example, a request message could be sent from an HTTP/1.0 user

agent to an internal proxy code-named "fred", which uses HTTP/1.1 to

forward the request to a public proxy at nowhere.com, which completes

the request by forwarding it to the origin server at www.ics.uci.edu.

The request received by www.ics.uci.edu would then have the following

Via header field:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Proxies and gateways used as a portal through a network firewall

SHOULD NOT, by default, forward the names and ports of hosts within

the firewall region. This information SHOULD only be propagated if

explicitly enabled. If not enabled, the received-by host of any host

behind the firewall SHOULD be replaced by an appropriate pseudonym

for that host.

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

RFC 2068 HTTP/1.1 January 1997

For organizations that have strong privacy requirements for hiding

internal structures, a proxy MAY combine an ordered subsequence of

Via header field entries with identical received-protocol values into

a single such entry. For example,

Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

could be collapsed to

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

Applications SHOULD NOT combine multiple entries unless they are all

under the same organizational control and the hosts have already been

replaced by pseudonyms. Applications MUST NOT combine entries which

have different received-protocol values.

14.45 Warning

The Warning response-header field is used to carry additional

information about the status of a response which may not be reflected

by the response status code. This information is typically, though

not exclusively, used to warn about a possible lack of semantic

transparency from caching operations.

Warning headers are sent with responses using:

Warning = "Warning" ":" 1#warning-value

warning-value = warn-code SP warn-agent SP warn-text

warn-code = 2DIGIT

warn-agent = ( host [ ":" port ] ) | pseudonym

; the name or pseudonym of the server adding

; the Warning header, for use in debugging

warn-text = quoted-string

A response may carry more than one Warning header.

The warn-text should be in a natural language and character set that

is most likely to be intelligible to the human user receiving the

response. This decision may be based on any available knowledge,

such as the location of the cache or user, the Accept-Language field

in a request, the Content-Language field in a response, etc. The

default language is English and the default character set is ISO-

8859-1.

If a character set other than ISO-8859-1 is used, it MUST be encoded

in the warn-text using the method described in RFC 1522 [14].

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

RFC 2068 HTTP/1.1 January 1997

Any server or cache may add Warning headers to a response. New

Warning headers should be added after any existing Warning headers. A

cache MUST NOT delete any Warning header that it received with a

response. However, if a cache successfully validates a cache entry,

it SHOULD remove any Warning headers previously attached to that

entry except as specified for specific Warning codes. It MUST then

add any Warning headers received in the validating response. In other

words, Warning headers are those that would be attached to the most

recent relevant response.

When multiple Warning headers are attached to a response, the user

agent SHOULD display as many of them as possible, in the order that

they appear in the response. If it is not possible to display all of

the warnings, the user agent should follow these heuristics:

o Warnings that appear early in the response take priority over those

appearing later in the response.

o Warnings in the user's preferred character set take priority over

warnings in other character sets but with identical warn-codes and

warn-agents.

Systems that generate multiple Warning headers should order them with

this user agent behavior in mind.

This is a list of the currently-defined warn-codes, each with a

recommended warn-text in English, and a description of its meaning.

10 Response is stale

MUST be included whenever the returned response is stale. A cache may

add this warning to any response, but may never remove it until the

response is known to be fresh.

11 Revalidation failed

MUST be included if a cache returns a stale response because an

attempt to revalidate the response failed, due to an inability to

reach the server. A cache may add this warning to any response, but

may never remove it until the response is successfully revalidated.

12 Disconnected operation

SHOULD be included if the cache is intentionally disconnected from

the rest of the network for a period of time.

13 Heuristic expiration

MUST be included if the cache heuristically chose a freshness

lifetime greater than 24 hours and the response's age is greater than

24 hours.

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

RFC 2068 HTTP/1.1 January 1997

14 Transformation applied

MUST be added by an intermediate cache or proxy if it applies any

transformation changing the content-coding (as specified in the

Content-Encoding header) or media-type (as specified in the

Content-Type header) of the response, unless this Warning code

already appears in the response. MUST NOT be deleted from a response

even after revalidation.

99 Miscellaneous warning

The warning text may include arbitrary information to be presented to

a human user, or logged. A system receiving this warning MUST NOT

take any automated action.

14.46 WWW-Authenticate

The WWW-Authenticate response-header field MUST be included in 401

(Unauthorized) response messages. The field value consists of at

least one challenge that indicates the authentication scheme(s) and

parameters applicable to the Request-URI.

WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge

The HTTP access authentication process is described in section 11.

User agents MUST take special care in parsing the WWW-Authenticate

field value if it contains more than one challenge, or if more than

one WWW-Authenticate header field is provided, since the contents of

a challenge may itself contain a comma-separated list of

authentication parameters.

15 Security Considerations

This section is meant to inform application developers, information

providers, and users of the security limitations in HTTP/1.1 as

described by this document. The discussion does not include

definitive solutions to the problems revealed, though it does make

some suggestions for reducing security risks.

15.1 Authentication of Clients

The Basic authentication scheme is not a secure method of user

authentication, nor does it in any way protect the entity, which is

transmitted in clear text across the physical network used as the

carrier. HTTP does not prevent additional authentication schemes and

encryption mechanisms from being employed to increase security or the

addition of enhancements (such as schemes to use one-time passwords)

to Basic authentication.

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

RFC 2068 HTTP/1.1 January 1997

The most serious flaw in Basic authentication is that it results in

the essentially clear text transmission of the user's password over

the physical network. It is this problem which Digest Authentication

attempts to address.

Because Basic authentication involves the clear text transmission of

passwords it SHOULD never be used (without enhancements) to protect

sensitive or valuable information.

A common use of Basic authentication is for identification purposes

-- requiring the user to provide a user name and password as a means

of identification, for example, for purposes of gathering accurate

usage statistics on a server. When used in this way it is tempting to

think that there is no danger in its use if illicit access to the

protected documents is not a major concern. This is only correct if

the server issues both user name and password to the users and in

particular does not allow the user to choose his or her own password.

The danger arises because naive users frequently reuse a single

password to avoid the task of maintaining multiple passwords.

If a server permits users to select their own passwords, then the

threat is not only illicit access to documents on the server but also

illicit access to the accounts of all users who have chosen to use

their account password. If users are allowed to choose their own

password that also means the server must maintain files containing

the (presumably encrypted) passwords. Many of these may be the

account passwords of users perhaps at distant sites. The owner or

administrator of such a system could conceivably incur liability if

this information is not maintained in a secure fashion.

Basic Authentication is also vulnerable to spoofing by counterfeit

servers. If a user can be led to believe that he is connecting to a

host containing information protected by basic authentication when in

fact he is connecting to a hostile server or gateway then the

attacker can request a password, store it for later use, and feign an

error. This type of attack is not possible with Digest Authentication

[32]. Server implementers SHOULD guard against the possibility of

this sort of counterfeiting by gateways or CGI scripts. In particular

it is very dangerous for a server to simply turn over a connection to

a gateway since that gateway can then use the persistent connection

mechanism to engage in multiple transactions with the client while

impersonating the original server in a way that is not detectable by

the client.

15.2 Offering a Choice of Authentication Schemes

An HTTP/1.1 server may return multiple challenges with a 401

(Authenticate) response, and each challenge may use a different

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

RFC 2068 HTTP/1.1 January 1997

scheme. The order of the challenges returned to the user agent is in

the order that the server would prefer they be chosen. The server

should order its challenges with the "most secure" authentication

scheme first. A user agent should choose as the challenge to be made

to the user the first one that the user agent understands.

When the server offers choices of authentication schemes using the

WWW-Authenticate header, the "security" of the authentication is only

as malicious user could capture the set of challenges and try to

authenticate him/herself using the weakest of the authentication

schemes. Thus, the ordering serves more to protect the user's

credentials than the server's information.

A possible man-in-the-middle (MITM) attack would be to add a weak

authentication scheme to the set of choices, hoping that the client

will use one that exposes the user's credentials (e.g. password). For

this reason, the client should always use the strongest scheme that

it understands from the choices accepted.

An even better MITM attack would be to remove all offered choices,

and to insert a challenge that requests Basic authentication. For

this reason, user agents that are concerned about this kind of attack

could remember the strongest authentication scheme ever requested by

a server and produce a warning message that requires user

confirmation before using a weaker one. A particularly insidious way

to mount such a MITM attack would be to offer a "free" proxy caching

service to gullible users.

15.3 Abuse of Server Log Information

A server is in the position to save personal data about a user's

requests which may identify their reading patterns or subjects of

interest. This information is clearly confidential in nature and its

handling may be constrained by law in certain countries. People using

the HTTP protocol to provide data are responsible for ensuring that

such material is not distributed without the permission of any

individuals that are identifiable by the published results.

15.4 Transfer of Sensitive Information

Like any generic data transfer protocol, HTTP cannot regulate the

content of the data that is transferred, nor is there any a priori

method of determining the sensitivity of any particular piece of

information within the context of any given request. Therefore,

applications SHOULD supply as much control over this information as

possible to the provider of that information. Four header fields are

worth special mention in this context: Server, Via, Referer and From.

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

RFC 2068 HTTP/1.1 January 1997

Revealing the specific software version of the server may allow the

server machine to become more vulnerable to attacks against software

that is known to contain security holes. Implementers SHOULD make the

Server header field a configurable option.

Proxies which serve as a portal through a network firewall SHOULD

take special precautions regarding the transfer of header information

that identifies the hosts behind the firewall. In particular, they

SHOULD remove, or replace with sanitized versions, any Via fields

generated behind the firewall.

The Referer field allows reading patterns to be studied and reverse

links drawn. Although it can be very useful, its power can be abused

if user details are not separated from the information contained in

the Referer. Even when the personal information has been removed, the

Referer field may indicate a private document's URI whose publication

would be inappropriate.

The information sent in the From field might conflict with the user's

privacy interests or their site's security policy, and hence it

SHOULD NOT be transmitted without the user being able to disable,

enable, and modify the contents of the field. The user MUST be able

to set the contents of this field within a user preference or

application defaults configuration.

We suggest, though do not require, that a convenient toggle interface

be provided for the user to enable or disable the sending of From and

Referer information.

15.5 Attacks Based On File and Path Names

Implementations of HTTP origin servers SHOULD be careful to restrict

the documents returned by HTTP requests to be only those that were

intended by the server administrators. If an HTTP server translates

HTTP URIs directly into file system calls, the server MUST take

special care not to serve files that were not intended to be

delivered to HTTP clients. For example, UNIX, Microsoft Windows, and

other operating systems use ".." as a path component to indicate a

directory level above the current one. On such a system, an HTTP

server MUST disallow any such construct in the Request-URI if it

would otherwise allow access to a resource outside those intended to

be accessible via the HTTP server. Similarly, files intended for

reference only internally to the server (such as access control

files, configuration files, and script code) MUST be protected from

inappropriate retrieval, since they might contain sensitive

information. Experience has shown that minor bugs in such HTTP server

implementations have turned into security risks.

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

RFC 2068 HTTP/1.1 January 1997

15.6 Personal Information

HTTP clients are often privy to large amounts of personal information

(e.g. the user's name, location, mail address, passwords, encryption

keys, etc.), and SHOULD be very careful to prevent unintentional

leakage of this information via the HTTP protocol to other sources.

We very strongly recommend that a convenient interface be provided

for the user to control dissemination of such information, and that

designers and implementers be particularly careful in this area.

History shows that errors in this area are often both serious

security and/or privacy problems, and often generate highly adverse

publicity for the implementer's company.

15.7 Privacy Issues Connected to Accept Headers

Accept request-headers can reveal information about the user to all

servers which are accessed. The Accept-Language header in particular

can reveal information the user would consider to be of a private

nature, because the understanding of particular languages is often

strongly correlated to the membership of a particular ethnic group.

User agents which offer the option to configure the contents of an

Accept-Language header to be sent in every request are strongly

encouraged to let the configuration process include a message which

makes the user aware of the loss of privacy involved.

An approach that limits the loss of privacy would be for a user agent

to omit the sending of Accept-Language headers by default, and to ask

the user whether it should start sending Accept-Language headers to a

server if it detects, by looking for any Vary response-header fields

generated by the server, that such sending could improve the quality

of service.

Elaborate user-customized accept header fields sent in every request,

in particular if these include quality values, can be used by servers

as relatively reliable and long-lived user identifiers. Such user

identifiers would allow content providers to do click-trail tracking,

and would allow collaborating content providers to match cross-server

click-trails or form submissions of individual users. Note that for

many users not behind a proxy, the network address of the host

running the user agent will also serve as a long-lived user

identifier. In environments where proxies are used to enhance

privacy, user agents should be conservative in offering accept header

configuration options to end users. As an extreme privacy measure,

proxies could filter the accept headers in relayed requests. General

purpose user agents which provide a high degree of header

configurability should warn users about the loss of privacy which can

be involved.

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

RFC 2068 HTTP/1.1 January 1997

15.8 DNS Spoofing

Clients using HTTP rely heavily on the Domain Name Service, and are

thus generally prone to security attacks based on the deliberate

mis-association of IP addresses and DNS names. Clients need to be

cautious in assuming the continuing validity of an IP number/DNS name

association.

In particular, HTTP clients SHOULD rely on their name resolver for

confirmation of an IP number/DNS name association, rather than

caching the result of previous host name lookups. Many platforms

already can cache host name lookups locally when appropriate, and

they SHOULD be configured to do so. These lookups should be cached,

however, only when the TTL (Time To Live) information reported by the

name server makes it likely that the cached information will remain

useful.

If HTTP clients cache the results of host name lookups in order to

achieve a performance improvement, they MUST observe the TTL

information reported by DNS.

If HTTP clients do not observe this rule, they could be spoofed when

a previously-accessed server's IP address changes. As network

renumbering is expected to become increasingly common, the

possibility of this form of attack will grow. Observing this

requirement thus reduces this potential security vulnerability.

This requirement also improves the load-balancing behavior of clients

for replicated servers using the same DNS name and reduces the

likelihood of a user's experiencing failure in accessing sites which

use that strategy.

15.9 Location Headers and Spoofing

If a single server supports multiple organizations that do not trust

one another, then it must check the values of Location and Content-

Location headers in responses that are generated under control of

said organizations to make sure that they do not attempt to

invalidate resources over which they have no authority.

16 Acknowledgments

This specification makes heavy use of the augmented BNF and generic

constructs defined by David H. Crocker for RFC 822. Similarly, it

reuses many of the definitions provided by Nathaniel Borenstein and

Ned Freed for MIME. We hope that their inclusion in this

specification will help reduce past confusion over the relationship

between HTTP and Internet mail message formats.

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

RFC 2068 HTTP/1.1 January 1997

The HTTP protocol has evolved considerably over the past four years.

It has benefited from a large and active developer community--the

many people who have participated on the www-talk mailing list--and

it is that community which has been most responsible for the success

of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert

Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois

Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob

McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc

VanHeyningen deserve special recognition for their efforts in

defining early aspects of the protocol.

This document has benefited greatly from the comments of all those

participating in the HTTP-WG. In addition to those already mentioned,

the following individuals have contributed to this specification:

Gary Adams Albert Lunde

Harald Tveit Alvestrand John C. Mallery

Keith Ball Jean-Philippe Martin-Flatin

Brian Behlendorf Larry Masinter

Paul Burchard Mitra

Maurizio Codogno David Morris

Mike Cowlishaw Gavin Nicol

Roman Czyborra Bill Perry

Michael A. Dolan Jeffrey Perry

David J. Fiander Scott Powers

Alan Freier Owen Rees

Marc Hedlund Luigi Rizzo

Greg Herlihy David Robinson

Koen Holtman Marc Salomon

Alex Hopmann Rich Salz

Bob Jernigan Allan M. Schiffman

Shel Kaphan Jim Seidman

Rohit Khare Chuck Shotton

John Klensin Eric W. Sink

Martijn Koster Simon E. Spero

Alexei Kosut Richard N. Taylor

David M. Kristol Robert S. Thau

Daniel LaLiberte Bill (BearHeart) Weinman

Ben Laurie Francois Yergeau

Paul J. Leach Mary Ellen Zurko

Daniel DuBois

Much of the content and presentation of the caching design is due to

suggestions and comments from individuals including: Shel Kaphan,

Paul Leach, Koen Holtman, David Morris, and Larry Masinter.

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