In my previous article, we covered some of HTTP's basics, such as the URL scheme, status codes and request/response headers. With that as our foundation, we will look at the finer aspects of HTTP, like connection handling, authentication and HTTP caching. These topics are fairly extensive, but we'll cover the most important bits.

In this article, they talk about things like the HTTPS secure version of HTTP, server-side connection handling, identification/authorization and working with caching and cache control headers.

The reason this posting lands in the PHP category is that I want to have a playground testing PHP applications with mod_spdy. Currently (and probably also in the future), this machine uses mod_php instead of php_(f)cgi(d) - this is not recommended for interoperation with mod_spdy. To test the real-life impact of the possible thread safety issues, I am using my private pages as a sandbox.

He has two other PHP-based applications running with the accelerator - a Gallery3 install and a WordPress site. SPDY ("speedy") was released by Google and is similar to HTTP but with a focus on minimized latency and heightened web security.

As I wrote in my PHP multithreading with cURL article, the libcurl is a free and easy-to-use client-side URL transfer library, supporting DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET and TFTP. PHP supports the libcurl library which allows you to connect and communicate to many different types of servers with many different types of protocols.

The tutorial focuses on two different types of connections (well, four really) - FTP/FTPS and HTTP/HTTPS - and how to transfer data across each. Some code is included to create a (procedural) tool to send an uploaded file to a remote site.

In light of the recent remote PHP exploit, I decided to update a couple servers I manage to ensure they weren't vulnerable. In each case, I had been using hand-compiled PHP builds, but decided that I'm simply too busy lately to be trying to maintain updates -- so I decided to install Zend Server. [...] One thing I've never been happy about, however, is that by default Zend Server exposes its administration GUI via both HTTP and HTTPS. Considering that the password gives you access to a lot of sensitive configuration, I want it to be encrypted.

He points out that, since the Zend Server interface runs on a lighttpd instance, it's easy to modify a few config files to change the setting. Adding a few lines to limit the socket it can connect on, the IP address to filter to and a URL filter on anything starting with "/ZendServer/" takes away the HTTP access.

The tutorial gives you a step-by-step process to follow with commands and configuration changes every step of the way:

• Create a certificate
• Generate a key
• Sign the key with the certificate
• Copy the keys to the right directory
• Make configuration changes for the SSL connections
• Connect to the remote HTTPS web service

If you're using PHP, you can also use the OpenSSL and SOAP clients with the SSL libraries to make requests to secure remote resources.

The problem is that Internet Explorer does not handle file dowloads without caching over https very well. Or at all. According to knowledge articles on Microsofts website the problem occurs when having one or two of the http headers. [...] Previously I have have just omitted the http header "Pragma: nocache" for IE but it seems it does not always help.

So the fix is relatively simple - rely on the $_SERVER['HTTP_USER_AGENT'] value to tell if it's an IR browser or not. If it is, "Pragma: cache" works. If not, stick with "Pragma: no-cache".

When trying to maintain a secure protocol on an Apache-based website, you can expect to deal with certain issues, especially if you're also trying to rank well in the search engines. [...] This article provides tips and solutions to help any web developer effectively manage the two most difficult problems in maintaining the secure protocol side of any website. These are the: Duplicate content and 301 redirection from the non-https to http version.

They recommend two things to handle the duplicate content issues: placing a meta tag on the https pages to keep them from being indexed (keeping the search engines from seeing the http and htttps as two different resources, thus two different sites to index) and using a canonical value in a link tag.

As far as the 301 redirects go, they include some PHP code that, if placed at the top of your pages, can detect if the protocol is https or not. If its not, it uses header to perform the 301 redirect.