Questions about $_SERVER
in [General]
|
From: Paul M Foster on 30 Aug 2010 16:34 On Mon, Aug 30, 2010 at 09:53:46PM +0200, Peter Lind wrote: > On 30 August 2010 21:32, Paul M Foster <paulf(a)quillandmouse.com> wrote: > > On Sun, Aug 29, 2010 at 06:04:23PM +0200, Per Jessen wrote: > > > >> Jason Pruim wrote: > >> > >> > My understanding of how shared hosting works would make this near > >> > impossible... Basically Apache grabs a header that is sent at the > >> > initial connection which includes the destination hostname and from > >> > there it translates it to the proper directory on the shared host. > >> > > >> > All the IP's though are based off of the parent site's server... > >> > > >> > Now with dedicated hosting where you have the entire machine you can > >> > do what you are looking at because the IP address will always > >> > translate back to your website. > >> > >> AFAICT, Tedd was not asking about the server, he's asking about the > >> client. > > > > No, he's talking about the server. But the server he's using may offload > > the processing of a script to another machine. So > > > > $_SERVER['SERVER_ADDR'] and $_SERVER['SERVER_NAME'] > > > > both relate to the server which the client is originally communicating > > with. But he wants to know if he can get the same information about a > > different remote server which is processing a script for him. The > > problem is that we have: > > > > $_SERVER['REMOTE_ADDR'] > > > > but no > > > > $_SERVER['REMOTE_NAME'] > > > > So the question is, how would he get that last variable. It becomes > > complicated when using a shared hosting environment, because server > > names and IPs aren't a 1:1 mapping. An IP may represent numerous actual > > site names. This was part or all of the reason why the http protocol was > > revised from 1.0 to 1.1-- in order to accommodate all the domains, which > > because of the cramped IP space of IPv4, had to share IPs. So in the > > HTTP 1.1 protocol, there is additional information passed about the name > > of the domain. > > > > In the scenario painted, it's explicitly stated that one server acts > as a client in trying to access a resource on another server. Could > you enlighten me as to where the domain name of a client is located in > the request header fields? Here's the RFC for HTTP 1.1 > http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3 From http://www8.org/w8-papers/5c-protocols/key/key.html: === EXCERPT === Internet address conservation Companies and organizations use URLs to advertise themselves and their products and services. When a URL appears in a medium other than the Web itself, people seem to prefer ``pure hostname'' URLs; i.e., URLs without any path syntax following the hostname. These are often known as ``vanity URLs,'' but in spite of the implied disparagement, it's unlikely that non-purist users will abandon this practice, which has led to the continuing creation of huge numbers of hostnames. IP addresses are widely perceived as a scarce resource (pending the uncertain transition to IPv6 [DH95]). The Domain Name System (DNS) allows multiple host names to be bound to the same IP address. Unfortunately, because the original designers of HTTP did not anticipate the ``success disaster'' they were enabling, HTTP/1.0 requests do not pass the hostname part of the request URL. For example, if a user makes a request for the resource at URL http://example1.org/home.html, the browser sends a message with the Request-Line GET /home.html HTTP/1.0 to the server at example1.org. This prevents the binding of another HTTP server hostname, such as exampleB.org to the same IP address, because the server receiving such a message cannot tell which server the message is meant for. Thus, the proliferation of vanity URLs causes a proliferation of IP address allocations. The Internet Engineering Steering Group (IESG), which manages the IETF process, insisted that HTTP/1.1 take steps to improve conservation of IP addresses. Since HTTP/1.1 had to interoperate with HTTP/1.0, it could not change the format of the Request-Line to include the server hostname. Instead, HTTP/1.1 requires requests to include a Host header, first proposed by John Franks [Fra94], that carries the hostname. This converts the example above to: GET /home.html HTTP/1.1 Host: example1.org If the URL references a port other than the default (TCP port 80), this is also given in the Host header. Clearly, since HTTP/1.0 clients will not send Host headers, HTTP/1.1 servers cannot simply reject all messages without them. However, the HTTP/1.1 specification requires that an HTTP/1.1 server must reject any HTTP/1.1 message that does not contain a Host header. The intent of the Host header mechanism, and in particular the requirement that enforces its presence in HTTP/1.1 requests, is to speed the transition away from assigning a new IP address for every vanity URL. However, as long as a substantial fraction of the users on the Internet use browsers that do not send Host, no Web site operator (such as an electronic commerce business) that depends on these users will give up a vanity-URL IP address. The transition, therefore, may take many years. It may be obviated by an earlier transition to IPv6, or by the use of market mechanisms to discourage the unnecessary consumption of IPv4 addresses. ======= My mistake, though: this change was by no means the only reason for the creation of HTTP 1.1 Paul -- Paul M. Foster
From: Peter Lind on 30 Aug 2010 16:34 On 30 August 2010 22:34, Paul M Foster <paulf(a)quillandmouse.com> wrote: > On Mon, Aug 30, 2010 at 09:53:46PM +0200, Peter Lind wrote: > >> On 30 August 2010 21:32, Paul M Foster <paulf(a)quillandmouse.com> wrote: >> > On Sun, Aug 29, 2010 at 06:04:23PM +0200, Per Jessen wrote: >> > >> >> Jason Pruim wrote: >> >> >> >> > My understanding of how shared hosting works would make this near >> >> > impossible... Basically Apache grabs a header that is sent at the >> >> > initial connection which includes the destination hostname and from >> >> > there it translates it to the proper directory on the shared host. >> >> > >> >> > All the IP's though are based off of the parent site's server... >> >> > >> >> > Now with dedicated hosting where you have the entire machine you can >> >> > do what you are looking at because the IP address will always >> >> > translate back to your website. >> >> >> >> AFAICT, Tedd was not asking about the server, he's asking about the >> >> client. >> > >> > No, he's talking about the server. But the server he's using may offload >> > the processing of a script to another machine. So >> > >> > $_SERVER['SERVER_ADDR'] and $_SERVER['SERVER_NAME'] >> > >> > both relate to the server which the client is originally communicating >> > with. But he wants to know if he can get the same information about a >> > different remote server which is processing a script for him. The >> > problem is that we have: >> > >> > $_SERVER['REMOTE_ADDR'] >> > >> > but no >> > >> > $_SERVER['REMOTE_NAME'] >> > >> > So the question is, how would he get that last variable. It becomes >> > complicated when using a shared hosting environment, because server >> > names and IPs aren't a 1:1 mapping. An IP may represent numerous actual >> > site names. This was part or all of the reason why the http protocol was >> > revised from 1.0 to 1.1-- in order to accommodate all the domains, which >> > because of the cramped IP space of IPv4, had to share IPs. So in the >> > HTTP 1.1 protocol, there is additional information passed about the name >> > of the domain. >> > >> >> In the scenario painted, it's explicitly stated that one server acts >> as a client in trying to access a resource on another server. Could >> you enlighten me as to where the domain name of a client is located in >> the request header fields? Here's the RFC for HTTP 1.1 >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3 > > From http://www8.org/w8-papers/5c-protocols/key/key.html: > > === EXCERPT === > > Internet address conservation > > Companies and organizations use URLs to advertise themselves and their > products and services. When a URL appears in a medium other than the Web > itself, people seem to prefer ``pure hostname'' URLs; i.e., URLs without > any path syntax following the hostname. These are often known as > ``vanity URLs,'' but in spite of the implied disparagement, it's > unlikely that non-purist users will abandon this practice, which has led > to the continuing creation of huge numbers of hostnames. > > IP addresses are widely perceived as a scarce resource (pending the > uncertain transition to IPv6 [DH95]). The Domain Name System (DNS) > allows multiple host names to be bound to the same IP address. > Unfortunately, because the original designers of HTTP did not anticipate > the ``success disaster'' they were enabling, HTTP/1.0 requests do not > pass the hostname part of the request URL. For example, if a user makes > a request for the resource at URL http://example1.org/home.html, the > browser sends a message with the Request-Line > > Â Â GET /home.html HTTP/1.0 > > to the server at example1.org. This prevents the binding of another HTTP > server hostname, such as exampleB.org to the same IP address, because > the server receiving such a message cannot tell which server the message > is meant for. Thus, the proliferation of vanity URLs causes a > proliferation of IP address allocations. > > The Internet Engineering Steering Group (IESG), which manages the IETF > process, insisted that HTTP/1.1 take steps to improve conservation of IP > addresses. Since HTTP/1.1 had to interoperate with HTTP/1.0, it could > not change the format of the Request-Line to include the server > hostname. Instead, HTTP/1.1 requires requests to include a Host header, > first proposed by John Franks [Fra94], that carries the hostname. This > converts the example above to: > > Â Â GET /home.html HTTP/1.1 > Â Â Â Â Â Â Host: example1.org > > If the URL references a port other than the default (TCP port 80), this > is also given in the Host header. > > Clearly, since HTTP/1.0 clients will not send Host headers, HTTP/1.1 > servers cannot simply reject all messages without them. However, the > HTTP/1.1 specification requires that an HTTP/1.1 server must reject any > HTTP/1.1 message that does not contain a Host header. > > The intent of the Host header mechanism, and in particular the > requirement that enforces its presence in HTTP/1.1 requests, is to speed > the transition away from assigning a new IP address for every vanity > URL. However, as long as a substantial fraction of the users on the > Internet use browsers that do not send Host, no Web site operator (such > as an electronic commerce business) that depends on these users will > give up a vanity-URL IP address. The transition, therefore, may take > many years. It may be obviated by an earlier transition to IPv6, or by > the use of market mechanisms to discourage the unnecessary consumption > of IPv4 addresses. > > ======= > > My mistake, though: this change was by no means the only reason for the > creation of HTTP 1.1 Not only that, it has nothing whatsoever to do with the case at hand. The Host header field specifies the domain you're asking a resource from, not the the domain of the client. Hence, it cannot be used in any fashion to provide identification of the client doing the request, which is what Tedd wanted. Regards Peter -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 </hype>
From: Paul M Foster on 30 Aug 2010 17:13 On Mon, Aug 30, 2010 at 10:34:42PM +0200, Peter Lind wrote: > On 30 August 2010 22:34, Paul M Foster <paulf(a)quillandmouse.com> wrote: > > On Mon, Aug 30, 2010 at 09:53:46PM +0200, Peter Lind wrote: > > <snip> > >> > $_SERVER['REMOTE_NAME'] > >> > > >> > So the question is, how would he get that last variable. It becomes > >> > complicated when using a shared hosting environment, because server > >> > names and IPs aren't a 1:1 mapping. An IP may represent numerous actual > >> > site names. This was part or all of the reason why the http protocol was > >> > revised from 1.0 to 1.1-- in order to accommodate all the domains, which > >> > because of the cramped IP space of IPv4, had to share IPs. So in the > >> > HTTP 1.1 protocol, there is additional information passed about the name > >> > of the domain. > >> > > >> > >> In the scenario painted, it's explicitly stated that one server acts > >> as a client in trying to access a resource on another server. Could > >> you enlighten me as to where the domain name of a client is located in > >> the request header fields? Here's the RFC for HTTP 1.1 > >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3 > > > > From http://www8.org/w8-papers/5c-protocols/key/key.html: <snip> > > > > My mistake, though: this change was by no means the only reason for the > > creation of HTTP 1.1 > > Not only that, it has nothing whatsoever to do with the case at hand. > The Host header field specifies the domain you're asking a resource > from, not the the domain of the client. Hence, it cannot be used in > any fashion to provide identification of the client doing the request, > which is what Tedd wanted. Tedd was looking for the server name for the remote server, as seen from the perspective of the asking server. In his example, he was looking for a variable which would tell him "Slave's" name from "Master's" perspective. That's why he was asking if there was anything like $_SERVER['REMOTE_NAME'] as a known PHP server variable. Of course, you're correct in that the HTTP 1.1 spec I cited wouldn't help him. I just mentioned it as being of tangential interest. Paul -- Paul M. Foster
From: Paul M Foster on 30 Aug 2010 17:59 On Mon, Aug 30, 2010 at 05:13:59PM -0400, Paul M Foster wrote: > On Mon, Aug 30, 2010 at 10:34:42PM +0200, Peter Lind wrote: > > > On 30 August 2010 22:34, Paul M Foster <paulf(a)quillandmouse.com> wrote: > > > On Mon, Aug 30, 2010 at 09:53:46PM +0200, Peter Lind wrote: > > > > > <snip> > > > >> > $_SERVER['REMOTE_NAME'] > > >> > > > >> > So the question is, how would he get that last variable. It becomes > > >> > complicated when using a shared hosting environment, because server > > >> > names and IPs aren't a 1:1 mapping. An IP may represent numerous > actual > > >> > site names. This was part or all of the reason why the http > protocol was > > >> > revised from 1.0 to 1.1-- in order to accommodate all the domains, > which > > >> > because of the cramped IP space of IPv4, had to share IPs. So in the > > >> > HTTP 1.1 protocol, there is additional information passed about > the name > > >> > of the domain. > > >> > > > >> > > >> In the scenario painted, it's explicitly stated that one server acts > > >> as a client in trying to access a resource on another server. Could > > >> you enlighten me as to where the domain name of a client is located in > > >> the request header fields? Here's the RFC for HTTP 1.1 > > >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3 > > > > > > From http://www8.org/w8-papers/5c-protocols/key/key.html: > > <snip> > > > > > > > My mistake, though: this change was by no means the only reason for the > > > creation of HTTP 1.1 > > > > Not only that, it has nothing whatsoever to do with the case at hand. > > The Host header field specifies the domain you're asking a resource > > from, not the the domain of the client. Hence, it cannot be used in > > any fashion to provide identification of the client doing the request, > > which is what Tedd wanted. > > Tedd was looking for the server name for the remote server, as seen from > the perspective of the asking server. In his example, he was looking for > a variable which would tell him "Slave's" name from "Master's" > perspective. That's why he was asking if there was anything like > $_SERVER['REMOTE_NAME'] as a known PHP server variable. I'm mistaken here. He's looking for the name of the server making the request, which doesn't appear to be transmitted anywhere. Paul -- Paul M. Foster
From: tedd on 3 Sep 2010 10:38 Peter and Paul: Sorry, I went on vacation for a few days (it was a surprise vacation with a 2 day notice). I think you both understand what I was looking for and found what I wanted was not possible. It's just one of those things in life you have to live with. Thanks very much for your time and comment. Cheers, tedd -- ------- http://sperling.com/
First
|
Prev
|
Pages: 1 2 3 4 Prev: displaying constants Next: array_walk_recursive pass by reference |