While profiling our application I came across a a rather strange memory usage by the ob_start() function. We do use ob_start() quite a bit to defer output of data, which is a common thing in many applications. What was unusual is that 16 calls to ob_start() up chewing through almost 700kb of memory, given that the data being buffered rarely exceeds 1-2kb, this was quite unusual.

Through a bit more testing he found that, if a buffer provided for content isn't enough, PHP automatically bumps it up by 10kb each time - a waste of resources if you only need a small subset of that. He includes a small patch he made to the PHP core API that allows for defining a custom buffer size and, if it's not enough, bumps up the buffer size by 1kb instead of 10kb.

If you are using phpcloud.com and are experiencing errors with git [...] and you are trying to push large files (not sure what is defined as "large") you may need to change some git settings.

He points out two settings - one for Windows and the other for Linux - that increase the buffer size to handle larger files that might be included in your repository.

Output buffering makes this process quicker and more efficient. The buffer is essentially a big memory-resident string. When text is output, it's appended to the buffer rather than returned to the browser immediately. The buffer is then "flushed", i.e. its contents are transmitted and the string is reset pending further output.

He notes the instances where the buffer would be flushed - end of page, exceeds number of bytes allowed or a manual flush is called - and code snippet example of a simple flushing setup. He also asks for some feedback on this method, so be sure to look at the comments for more thoughts from the community.

For example we want to show videos only to registered users based on our authentication system. Imagine we're using sessions for validate users. That's means we cannot put the media in a public folder and point our media player to those files. We can obfuscate the file name but it'll remain public. In this small tutorial We're going to see how to implement it with PHP.

Since the video stream he wants to deal with is a live one (and not a single video file that can be read all at once) he shows how to use the output buffering functions in PHP to output small chunks of the data at a time with the correct headers attached.

HTTP is the communication protocol that happens between your web server and the user's browser. Without too much detail, this is broken into two pieces of data: headers and the body. The body is the HTML you send. But, before the body is sent, the HTTP headers are sent.

He includes a sample raw HTTP response for a page and how the ob_start function works to buffer the output of the resulting page to save the header information until the buffer is echoed or cleaned out. There is a down side he mentions, though - there's no partial buffering built in so it's an all or nothing short.

One thing I need to do while building the multi-user version of webme is to convert it so file references such as /f/photos/an_image.jpg get transparently converted so they serve correctly, even though the actual file may be located somewhere entirely else.

There's two steps involved - rewriting the URL request for the types of files you'd like to pull through the script (using some mod_rewrite magic in Apache) and make the script to do the actual work. Source for that is included too. Not only can something like this help you keep things organized but it also allows for extra security if you need to store the files outside of the webserver's document root.

Output control (or output buffering) allows you to write and execute your scripts normally but send data to the web browser at selected times. The main benefit of this system is that you can call the header(), setcookie() and session_start() functions at any place in your scripts without having to worry about the "headers already sent" error message.

They start with the basics - the functions and what they do - then move on to an example, a login form, that uses the buffering to capture errors and html to be flushed and echoed at the end.

mysqlnd saves memory. It consumes half as much memory as libmysql. This is what we have been convinced of. This is what we taught you. Then I tried to test it and made Andrey get nervous for a few hours'¦ Meanwhile he is fine again and we can announce: mysqlnd saves memory, not only in theory, we tested it - we can proof it, can we?

The proof comes in the form of a few "tricks" and some of the settings that the software can use to optimize buffer sizes. Benchmarks (and the code to run them) are also included to show what the differences are between mysqlnd and libmysql.

The vulnerabilities are caused due to boundary errors within the "htmlentities()" and "htmlspecialchars()" functions. If a PHP application uses these functions to process user-supplied input, this can be exploited to cause a heap-based buffer overflow by passing specially crafted data to the affected application.

Successful exploitation may allow execution of arbitrary code, but requires that the UTF-8 character set is selected.

Products affected include the Network Analysis Modules (NAM) for Cisco 6500 switch, Cisco 7600 router/Branch Routers and the CiscoWorks Wireless LAN Solution Engine (WLSE) and CiscoWorks Wireless LAN Solution (among others, check out the advisory for a more complete list).

There are some patches that have been released to correct this issue (like the one for the Cisco Unified Application Environment) but others are still yet to come. They recommend limiting access to only trusted IPs and devices only to reduce the risk of the problem being exploited.

If you use PEAR::MDB2, you can set a custom debug handler and collect all the queries you execute for debugging and performance tunning purposes, as shown before. But what if you're using PEAR::DB? Well, since PEAR::DB doesn't allow you such a functionality out of the box, you can hack it a bit to get similar results.

He creates a simple app to help with the illustration - a number of select queries to grab zipcode information from the database. As it stands, the PEAR::DB package doesn't handle the debugging well, so he adds in a few more lines to buffer the connection and some reporting code to check the resulting output (as well as some of his sample reports).