includes via HTTP

Woudln't this slow down pages?

[rocknbil]

Reworking a site for someone and have found many instances of this. The docs have much to say about it but couldn't find anything to efficiency or speed of one over the other.

I know it's valid to do this, and works . . .

include('https://example.com/file.php');

(Only used httpS so the link doesn't get munged up)

but if the include is on the same server, wouldn't this slow down a "page?" It seems like it would as it's making a separate http request. Wouldn't a file request be more efficient and faster?

include($_SERVER['DOCUMENT_ROOT'] . '/file.php');

[coopster]

Yes, more efficient, faster. Plus you won't run into possible routing issues when your server and/or router/firewall get confused on where and how to route the request. Often times you will have to add a host entry just to overcome an issue like that.

[lostdreamer]

NOTE:
Including a file through HTTP will include the allready parsed PHP file.
so if example.com/file.php has the following:

<?php
echo "hello world";
?>

The include will only get "hello world", not the actual PHP code.

You might want to watch out for this if you change the includes to include($_SERVER['DOCUMENT_ROOT'] . '/file.php'); as you would need to change the file.php to accomodate.

[morehawes]

I have never seen an include used like this before and with good reason I think. I can't see any way that it wouldn't be less efficient and hugely increase the parse time whilst waiting for the page to download over http. I guess if you are wanting to output the parsed HTML directly to the browser it's one way of doing it... odd though. Is there an output buffer wrapped around the line?

[coopster]

Output buffering is exactly how you overcome the situation described by lostdreamer.

I have never seen an include used like this before

You likely haven't worked on code developed by an "immature" PHP developer. And I use the word "immature" because many new developers just do not realize the power of output buffering and how it can be used. Perhaps the word "inexperienced" is a better term. The immaturity level stems from inexperience. It just seems much easier for them to use the output and one way for them to accomplish that goal is to employ the HTTP protocol which renders the HTML for them. They just haven't learned that the same result can be accomplished by reading from the file system using output buffering.

[rocknbil]

Right, thank you all . . . But have discovered a problem. This one is a new one on me. :-)

I'm reconstructing a revision in a test directory. These includes in particular are using a program I haven't researched yet - OpenX. I'm speaking with the client soon about it's precise usage, but basically it's an ad inclusion program. Well guess what, when I do this

include($_SERVER['DOCUMENT_ROOT'] . '/file.php');

It "works," it does output the ad, but outputs an "output headers already sent" immediately after the ad. I looked into the code, and sure enough, it outputs a header.

As said, off to research it, there's probably a simple config in the OpenX admin that will fix it, but THAT is why they are using an http include. Odd!

An interesting thing I caught from the docs was that when you include using a url, if the url is on a remote server it will only return the output already processed on that server. That is, the remote server does the processing, not the local one. So I'm guessing that also, when you include on the same server, it's doubling the PHP processing time. But in this case it looks like they did that because it's the only way they could get it to work.

I'll fix it . . . :-)

[coopster]

It "works," it does output the ad, but outputs an "output headers already sent" immediately after the ad. I looked into the code, and sure enough, it outputs a header.

Probably because it is outputting html. Turn output buffering on first, then at the end of the include capture the buffer in a variable and turn off output buffering. That way you have the rendered html stored in a variable for further manipulation, use or disposal, depending on your logic flow.

An interesting thing I caught from the docs was that when you include using a url, if the url is on a remote server it will only return the output already processed on that server. That is, the remote server does the processing, not the local one. So I'm guessing that also, when you include on the same server, it's doubling the PHP processing time. But in this case it looks like they did that because it's the only way they could get it to work.

Any time you include using a url you are going to get the rendered document and not PHP code.