HTTP stands for Hypertext Transfer Protocol. It's a stateless, application-layer protocol for communicating between distributed systems, and is the foundation of the modern web. As a web developer, we all must have a strong understanding of this protocol. Let's review this powerful protocol through the lens of a web developer. We'll tackle the topic in two parts. In this first entry, we'll cover the basics and outline the various request and response headers.

They cover some of the basics of the protocol first including its statelessness, the concept of URLs and the HTTP "verbs" (like GET, POST and DELETE). They also briefly cover the HTTP response codes (ex. 200, 304) and the flow of the request and response to and from the web server. They also look at some of the basic HTTP headers and the actual low-level text formats of the requests/responses.

There's a section at the end of the post that links you to a few tools that you can use to view the HTTP messaging happening in your requests, some of which you might already have. They also briefly cover the use of HTTP in a few libraries - ExpressJS, Ruby on Rails and jQuery's Ajax handling.

We're getting close to the end now, and the only thing remaining is to discuss a little more about the protocol you'll most likely use in any RESTful application that you write. Because HTTP is so often used with REST, that's the protocol I'd like to focus on.

He goes through the structure of a typical (raw) HTTP header and talks about some of the more common headers and what actions/settings they represent. He includes examples of setting headers (with header, naturally) and a curl example showing how to set the request headers. The tutorial is finished off with a brief mention of custom HTTP headers and the the good and bad that comes with them.

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.

I'm exploring the possibility of using RabbitMQ for an upcoming project. RabbitMQ is a free/open source message broker platform. It uses the open Advanced Message Queuing Protocol (AMQP) standard and is written in Erlang using the Open Telecom Platform (OTP). It promises a high level of availability, throughput, scalability, and portability. Since it is built using open standards, it is interoperable with other messaging systems and can be accessed from any platform.

He goes through the full process - installing RabbitMQ via MacPorts, grabbing the latest copy of the librabbitmq library and installing it and finally installing the AMQP extension for PHP so they can communicate. He includes some simple code that connects to the queue and sends a "hello world" message out to the connection bound to "routeA".

PHP has many functions that help us to implement Internet and/or networking protocols. In this article we will look at how to implement some of those protocols using PHP.

His examples uses PHP's FTP methods to create a simple frontend to a remote FTP server. Included is the code to get the basics of it working - listing remote files and displaying them out in a styled list.

When trying to install something, you will get the error: pear.php.net is using a unsupported protocal '" This should never happen. install failed. This problem comes from corrupted channel files. Go into your PEAR php directory and backup .channels directory.

If you go into your PEAR installation and move the .channels directory out of the way then run an "update-channels" the issue should be corrected. Unfortunately, this also means you loose all channels you'd subscribed to, but does save you from having to reinstall PEAR completely.

In this article we will look at the protocol that is involved in sending email messages. We will also examine the thorny issue of how to send an attachment with an email message. This article is the second of two parts.

They include examples of sending simple messages and more complex ones with things like attachments and custom headers. They also tack on a look at the PEAR::Mail package to the end showing how it can make sending some things a little less painful.

HTTP is a stateless protocol. This means that each request is handled independently of all the other requests and it means that a server or a script cannot remember if a user has been there before. However, knowing if a user has been there before is often required and therefore something known as cookies and sessions have been implemented in order to cope with that problem.

The tutorial is pretty introductory, so if you're not new to the PHP world, you won't learn much. New developers, though, will learn how to set cookies, use sessions and learn a bit about the security of both.

PHP has many functions that help us to implement Internet and/or networking protocols. In this article, we will look at how to implement some of those protocols using PHP.

They introduce the FTP functions for PHP (a basic list, PHP manual style) and include the code - the CSS to make it easier to use and the PHP code to make the FTP connection and grab the remote file listing. A screenshot is included to give you an idea of the end result.

Spectator is a XUL application, which should make it cross platform. I have tinkered a bit with XUL before, but not a full application. [...] So what can spectator do? Mind that this is a first version and I really just meant it as a proof of concept. I think I got a bit further than that, but it probably still has a few bugs. Still, with the current version, you can step through a program, set breakpoints and inspect the stack. Really all you would expect from a debugger.

You can grab the latest version from the subversion repository on the Google Code website.