There is a dark spot in everything we do when it comes to building a website called the HTTP protocol. It’s not really dark. This is great because it is what allows you to use all the internet functions. When you visit a website, the server sends HTML over the Internet, which happens before the HTML reaches the browser.
These are called HTTP headers and contain important information about the web session that needs to be presented to the browser.
This is dispatched earlier than others. In fact, the reason this process started is because you were trying to visit the website in the first place. What if you type your favorite URL in any browser and hit Enter? The browser sends a GET request to the server in the form of HTTP headers over the HTTP protocol.
As you can see, these are all at the core of how websites and the Internet work, so you need to have a good understanding of how to use them in PHP. In many cases, people use a dedicated php http client to handle http. PHP has many functions and approaches for working directly with HTTP and HTTP headers, so let’s get started!
HTTP is the devil, isn’t it?
You may have noticed the appalling importance that the title of this post attaches to PHP. Actually, HTTP is not that bad. In fact, it could be our friend. However, it is a little clever and difficult at first, so we need to remain vigilant in learning. One way to really learn about the HTTP protocol is to install something like the Live HTTP Headers add-on in Firefox.
This allows you to view all communication between the web browser and the remote server in real time. It’s actually pretty smooth. If you have Live HTTP Headers set, clicking on Tools -> Live HTTP Headers will open a new window showing all the HTTP headers for your web session. Here’s an example of a Twitter request / response.
Request
https://twitter.com/
GET / HTTP/1.1
Host: twitter.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: guest_id=example cookie data
Connection: keep-alive
Response
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Content-Encoding: gzip
Content-Length: 12361
content-security-policy-report-only: default-src https:; connect-src https:; font-src https: data:; frame-src https: http://*.twimg.com http://itunes.apple.com about: javascript:; frame-ancestors https:; img-src https: data:; media-src https:; object-src https:; script-src ‘unsafe-inline’ ‘unsafe-eval’ about: https:; style-src ‘unsafe-inline’ https:; report-uri;
Content-Type: text/html;charset=utf-8
Date: Thu, 09 Oct 2014 14:36:46 UTC
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Last-Modified: Thu, 09 Oct 2014 14:36:46 GMT
ms: S
Pragma: no-cache
Server: tsa_a
Set-Cookie: _twitter_sess=example session cookie
status: 200 OK
The main thing to note here is the status code. You can see Twitter responding with 200 OK. It’s called “Hello, everything is great.” There is a complete set of status codes that facilitate communication between client and server. Here is a table.
HTTP Code Number |
HTTP Code Meaning |
---|---|
Messages in the 100 range are informational | |
100 | Continue |
101 | Switching Protocol |
Messages in the 200 range indicate success | |
200 | OK |
201 | Created |
202 | Accepted |
203 | Non-Authoritative Information |
204 | No Content |
205 | Reset Content |
206 | Partial Content |
Messages in the 300 range deal with redirection | |
300 | Multiple Choice |
301 | Moved Permanently |
302 | Found |
303 | See Other |
304 | Not Modified |
305 | Use Proxy |
306 | unused |
307 | Temporary Redirect |
308 | Permanent Redirect |
Messages in the 400 range indicate client errors | |
400 | Bad Request |
401 | Unauthorized |
402 | Payment Required |
403 | Forbidden |
404 | Not Found |
405 | Method Not Allowed |
406 | Not Acceptable |
407 | Proxy Authentication Required |
408 | Request Timeout |
409 | Conflict |
410 | Gone |
411 | Length Required |
412 | Precondition Failed |
413 | Request Entity Too Large |
414 | Request-URI Too Long |
415 | Unsupported Media Type |
416 | Requested Range Not Satisfiable |
417 | Expectation Failed |
Messages in the 500 range are server errors | |
500 | Internal Server Error |
501 | Not Implemented |
502 | Bad Gateway |
503 | Service Unavailable |
504 | Gateway Timeout |
505 | HTTP Version Not Supported |
Header ($string)
The web server sends website visitors the appropriate headers as appropriate. This happens automatically and transparently in the background, which we usually don’t even think about. Sometimes developers need to manually configure how headers are displayed on the server, in which case they can use the header () function. Let’s take a look at the code that changes the title.
https://gist.github.com/7d38451e870009bd9fc907af288ba18e
The code above shows an example of sending headers for an Adobe PDF document, server error, page not found and attachment being downloaded.
Headers come first
There is a very important thing to know about HTTP headers, and they are passed before all page data. First. The reason is that the HTTP protocol pays attention to the user’s browser.
This may tell you something else, but the main thing to know is that the HTTP protocol provides this, so we need to know about it. Any changes you want to make to the header must be done before any other work in your code. When the server starts sending anything, no matter how small the space is
Warning: Cannot modify header information – headers already sent (output started at file:line).
Redirects in PHP
In fact, changing headers in PHP is not common, but it is always used, and there are use cases worth implementing. This use case is page redirection. Page redirection is useful when you want users to be redirected directly to key information on a specific page when they enter your site. You can do this with a page redirect. All popular PHP frameworks have this feature in their easy-to-use methods, but you can also use it with your own PHP. Let’s see how.
302 redirect
The HTTP protocol uses 302 redirects to perform page redirects. It has two parts.
-
- HTTP 1.1/ 302 Found
- Location: path
Now, if you do it in PHP, it will look something like this: Let’s say you redirect someone to the login page.
https://gist.github.com/bd4fe06763b7e69dce41fd8e816a3693
Then you can provide a path to redirect. Interestingly, when the browser sees a 302 redirect, it actually makes a second GET request right away.
https://gist.github.com/b08c2f902b61bf2553a1ac89a4fbc46e
You can even put it in a dedicated redirect function if you like. I don’t know what it might look like.
https://gist.github.com/fd7bf66481e70ad2d7b76d69b55bafc5
Now, if you want to redirect someone to AlfinTech Computer, you can do that.
https://gist.github.com/5579ecb944283233b478b9a888f61366
HTTP header conclusion
In this installment of the PHP tutorial series, we learned about the HTTP protocol and how it works in PHP. It may have started to scare you, but now that I understand how it works, it’s not that scary in the end. The point is that HTTP headers always come first when communicating over the Internet, and every message has an associated status code. A handy status code table lets you know what information is, success, redirection, client error or server error. It would be helpful to know the basic connections of at least 100, 200, 300, 400 and 500.
AUTHOR BIO
On my daily job, I am a software engineer, programmer & computer technician. My passion is assembling PC hardware, studying Operating System and all things related to computers technology. I also love to make short films for YouTube as a producer. More at about me…
Leave a Reply