How To Find Out HTTP Request With PHP That Rarely Known

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
Multiple Choice
Moved Permanently
Found
See Other
Not Modified
Use Proxy
unused
Temporary Redirect
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.

Related Posts