PHPor 的Blog

下面是一个常见的获取用户ip的函数：

<?php
function getip()
{
    if(getenv("HTTP_CLIENT_IP") && getenv("HTTP_CLIENT_IP")!="unknown")
        $ip = getenv("HTTP_CLIENT_IP");
    elseif(getenv("HTTP_X_FORWARDED_FOR") && getenv("HTTP_X_FORWARDED_FOR")!="unknown")
        $ip = getenv("HTTP_X_FORWARDED_FOR");
    elseif(getenv("REMOTE_ADDR") && getenv("REMOTE_ADDR")!="unknown")
        $ip = getenv("REMOTE_ADDR");
    else    
        $ip = "none"; 

    return $ip;
}
?>

下面给出一个测试脚本：

<?php
$ch = curl_init();
curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch,CURLOPT_HTTP_VERSION,CURL_HTTP_VERSION_1_1);
curl_setopt($ch,CURLOPT_HTTPHEADER,array(‘X_FORWARDED_FOR: 158.10.10.10’));
curl_setopt($ch,CURLOPT_HTTPHEADER,array(‘CLIENT_IP: 159.10.10.10’));
curl_setopt($ch, CURLOPT_URL,"http://10.10.10.21/test.php");
echo curl_exec($ch);
curl_close($ch);
exit;
?>

References

http1.0: RFC 1945.

http1.1: RFC 2068

 

Status Code

The Warning header

HTTP status codes indicate the success or failure of a request. For a successful response, the status code cannot provide additional advisory information, in part because the placement of the status code in the Status-Line, instead of in a header field, prevents the use of multiple status codes.

HTTP/1.1 introduces a Warning header, which may carry any number of subsidiary status indications. The intent is to allow a sender to advise the recipient that something may be unsatisfactory about an ostensibly successful response.

HTTP/1.1 defines an initial set of Warning codes, mostly related to the actions of caches along the response path. For example, a Warning can mark a response as having been returned by a cache during disconnected operation, when it is not possible to validate the cache entry with the origin server.

The Warning codes are divided into two classes, based on the first digit of the 3-digit code. One class of warnings must be deleted after a successful revalidation of a cache entry; the other class must be retained with a revalidated cache entry. Because this distinction is made based on the first digit of the code, rather than through an exhaustive listing of the codes, it is extensible to Warning codes defined in the future.

Other new status codes

There are 24 new status codes in HTTP/1.1; we have discussed 100 (Continue), 206 (Partial Content), and 300 (Multiple Choices) elsewhere in this paper. A few of the more notable additions include

* 409 (Conflict), returned when a request would conflict with the current state of the resource. For example, a PUT request might violate a versioning policy.

* 410 (Gone), used when a resource has been removed permanently from a server, and to aid in the deletion of any links to the resource.

Most of the other new status codes are minor extensions.

HTTP1.0

HTTP1.1

HTTP/1.0 does not define any 1xx status

codes and they are not a valid response to a HTTP/1.0 request.

100 Continue

101 Switching Protocols

Undifined

203 Non-Authoritative Information

Undifined

205 Reset Content

Undifined

206 Partial Content

Undifined

303 See Other

Undifined

305 Use Proxy

Undifined

402 Payment Required

Undifined

405 Method Not Allowed

Undifined

406 Not Acceptable

Undifined

407 Proxy Authentication Required

Undifined

408 Request Timeout

Undifined

409 Conflict

Undifined

410 Gone

Undifined

411 Length Required

Undifined

412 Precondition Failed

Undifined

413 Request Entity Too Large

Undifined

414 Request-URI Too Long

Undifined

415 Unsupported Media Type

Undifined

504 Gateway Timeout

Undifined

505 HTTP Version Not Supported

HTTP/1.0 -> HTTP/1.1

Changes to Simplify Multi-homed Web Servers and Conserve IP

Addresses

The requirements that clients and servers support the Host request-

header, report an error if the Host request-header (section 14.23) is

missing from an HTTP/1.1 request, and accept absolute URIs (section

5.1.2) are among the most important changes defined by this

specification.

Older HTTP/1.0 clients assumed a one-to-one relationship of IP

addresses and servers; there was no other established mechanism for

distinguishing the intended server of a request than the IP address

to which that request was directed. The changes outlined above will

allow the Internet, once older HTTP clients are no longer common, to

support multiple Web sites from a single IP address, greatly

simplifying large operational Web servers, where allocation of many

IP addresses to a single host has created serious problems. The

Internet will also be able to recover the IP addresses that have been

allocated for the sole purpose of allowing special-purpose domain

names to be used in root-level HTTP URLs. Given the rate of growth of

the Web, and the number of servers already deployed, it is extremely

important that all implementations of HTTP (including updates to

existing HTTP/1.0 applications) correctly implement these

requirements:

o Both clients and servers MUST support the Host request-header.

o Host request-headers are required in HTTP/1.1 requests.

o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1

request does not include a Host request-header.

o Servers MUST accept absolute URIs.

Persistent

HTTP/1.0

experimental implementations of persistent connections are faulty,

and the new facilities in HTTP/1.1 are designed to rectify these

problems. The problem was that some existing 1.0 clients may be

sending Keep-Alive to a proxy server that doesn’t understand

Connection, which would then erroneously forward it to the next

inbound server, which would establish the Keep-Alive connection and

result in a hung HTTP/1.0 proxy waiting for the close on the

response. The result is that HTTP/1.0 clients must be prevented from

using Keep-Alive when talking to proxies.

original HTTP/1.0 form of persistent

connections.

When it connects to an origin server, an HTTP client MAY send the

Keep-Alive connection-token in addition to the Persist connection-

token:

Connection: Keep-Alive

An HTTP/1.0 server would then respond with the Keep-Alive connection

token and the client may proceed with an HTTP/1.0 (or Keep-Alive)

persistent connection.

An HTTP/1.1 server may also establish persistent connections with

HTTP/1.0 clients upon receipt of a Keep-Alive connection token.

However, a persistent connection with an HTTP/1.0 client cannot make

use of the chunked transfer-coding, and therefore MUST use a

Content-Length for marking the ending boundary of each message.

A client MUST NOT send the Keep-Alive connection token to a proxy

server as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1

for parsing the Connection header field.

In HTTP/1.0, most implementations used a new connection for each

request/response exchange. In HTTP/1.1, a connection may be used for

one or more request/response exchanges, although connections may be

closed for a variety of reasons .

Content Negotiation

  Web users speak many languages and use many character sets. Some Web resources are available in several variants to satisfy this multiplicity. HTTP/1.0 included the notion of content negotiation, a mechanism by which a client can inform the server which language(s) and/or character set(s) are acceptable to the user.

Content negotiation has proved to be a contentious and confusing area. Some aspects that appeared simple at first turned out to be quite difficult to resolve. For example, although current IETF practice is to insist on explicit character set labeling in all relevant contexts, the existing HTTP practice has been to use a default character set in most contexts, but not all implementations chose the same default. The use of unlabeled defaults greatly complicates the problem of internationalizing the Web.

HTTP/1.0 provided a few features to support content negotiation, but RFC1945 never uses that term and devotes less than a page to the relevant protocol features. The HTTP/1.1 specification specifies these features with far greater care, and introduces a number of new concepts.

The goal of the content negotiation mechanism is to choose the best available representation of a resource. HTTP/1.1 provides two orthogonal forms of content negotiation, differing in where the choice is made:

1.

In server-driven negotiation, the more mature form, the client sends hints about the user’s preferences to the server, using headers such as Accept-Language, Accept-Charset, etc. The server then chooses the representation that best matches the preferences expressed in these headers.

2.

In agent-driven negotiation, when the client requests a varying resource, the server replies with a 300 (Multiple Choices) response that contains a list of the available representations and a description of each representation’s properties (such as its language and character set). The client (agent) then chooses one representation, either automatically or with user intervention, and resubmits the request, specifying the chosen variant.

Although the HTTP/1.1 specification reserves the Alternates header name for use in agent-driven negotiation, the HTTP working group never completed a specification of this header, and server-driven negotiation remains the only usable form.

Some users may speak multiple languages, but with varying degrees of fluency. Similarly, a Web resource might be available in its original language, and in several translations of varying faithfulness. HTTP introduces the use of quality values to express the importance or degree of acceptability of various negotiable parameters. A quality value (or qvalue) is a fixed-point number between 0.0 and 1.0. For example, a native speaker of English with some fluency in French, and who can impose on a Danish-speaking office-mate, might configure a browser to generate requests including

Accept-Language: en, fr;q=0.5, da;q=0.1

Because the content-negotiation mechanism allows qvalues and wildcards, and expresses variation across many dimensions (language, character-set, content-type, and content-encoding) the automated choice of the best available” variant can be complex and might generate unexpected outcomes. These choices can interact with caching in subtle ways.

Content negotiation promises to be a fertile area for additional protocol evolution. For example, the HTTP working group recognized the utility of automatic negotiation regarding client implementation features, such as screen size, resolution, and color depth. The IETF has created the Content Negotiation working group to carry forward with work in the area.

Other

A server MUST NOT send

transfer-codings to an HTTP/1.0 client.