I haven’t written a blog for a long time. Taking advantage of a recent practice of sharing, I will summarize the shared content into a small blog. Let’s fighting!

HTTP status code, I believe that most of your friends are familiar with.

  • The ajax interface connected to the background returns 200
  • The background interface reported an error and returned 500
  • Front-end interviews are often asked about 304
  • Page not found returns 404
  • More…

Obviously, HTTP status codes lurk in many, many small details of our daily work, so please think again, you are familiar with HTTP status codes, enough?

Just a couple of examples

  • Background returned 5XX status code, are all background POTS?
  • Ever notice when a 1xx status code is returned?
  • What is the difference between permanent and temporary redirects?

With these examples, combined with some practice in my daily work, wave we look together, HTTP status code in actual combat, there is no magic effect?

Case 1: How to use 504 and 502 status codes for more accurate “flipping”

Assume that S company has the following roles:

  • Little A, our front-end partner, is responsible for page development and calling back-end data
  • Little B, a back-end partner, used GO to build the whole business background
  • Little G, operation and maintenance manager, is responsible for making the front and back end projects into Docker containers and deploying them online

Scenario 1: One day, Little A found that in the internal development environment, the background interface returned 504 status code, and saw the keyword “Timeout” in the returned error description. So small A query small B, you have A Bug in the background!

Vulnerable little B can’t stand the question, reply: “your Bug is called 504, you write 504 every day!”

In line with seeking truth from facts (jilted pot to be well-founded) attitude, small A began to deduce. Our goal is simple: prove that the server is down.

First of all, sort out the server down can have several possibilities:

  1. Server directly dang machine
  2. The server is alive, but there is an internal problem somewhere that is not responding to requests
  3. The background classmate interface was written incorrectly. The target interface is invalid or does not exist
  4. Proxy server down (for example, Nginx)
  5. more…

Following these possibilities sorted out, Xiao A conveniently used Express + Nginx to build A set of environment and began to simulate the investigation one by one.

// Create a route in express
/ /... Omit other code

router.get('/hello', (req, res) => {
  res.end('hello');
});
/ /...
Copy the code
# nginx, add a routing configuration
server {
    listen       80;
    server_name  ooo.test.com; 127.0.0.1ooo.test.com
    #charset koi8-r;
    access_log  /usr/local/etc/nginx/log/host.access.log  main;
	location / {
	    proxy_pass   http://127.0.0.1:3000/;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header REMOTE-HOST $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Url  "$scheme: / /$host$request_uri";
            proxy_read_timeout 3; # Add a 3-second timeout for faster results (nginx defaults to 1 minute)}}Copy the code

Then start simulating various scenarios:

  1. Normal visit http://ooo.test.com/hello

    Test result: as expected, return 200 and print “hello” successfully

  2. Emulated the server, shut down the Express service, and then visit ooo.test.com/hello

    Test result: 502 Bad Gateway is returned

  3. The server is alive, but there is an internal problem somewhere that is not responding to requests. Let’s change the code to remove the interface return. The code looks like this. Start the Express service and visit the web page again

    router.get('/hello', (req, res) => {
  //res.end('hello');
});
Copy the code

    Test result: After 3 seconds of loading504Gateway time-out is displayed

  4. The background classmate interface was written incorrectly. The target interface is invalid or does not exist. This one is relatively simple, the parameter error returns 400, not logged in returns 401, pathName error returns 404, do not simulate.

  5. The proxy server is down (for example, Nginx). Nginx, gateway servers generally only do data forwarding, the possibility of failure is very small. We can try to turn off nginx and visit the web.

Through the above tests, we can intuitively find:

  • 502: The server is faulty. The proxy server cannot access the service
  • 504: An internal exception occurs on the server, and the proxy server does not respond due to timeout

Next, little A found little B with the test conclusion, and coerced little B to conduct investigation and locate and found the memory leak of the background service, resulting in no response of the interface. “Shake the pan” complete!

Case 2, temporary vs. permanent redirection

In interviews, I sometimes ask students, do you know the difference between 301 and 302 status codes? In what situations will they be used? Most of you can answer, one is a temporary redirect, one is a permanent redirect. But any more, and it’s gone. Without further ado, let’s look at the differences between temporary and permanent redirects in the browser using code.

// The same express project


router.get('/hello', (req, res) => {
	//301, permanently redirect this path to Baidu
	res.writeHead(301, { Location: 'http://www.baidu.com/' }); 
	res.end();
})
Copy the code

OK, reset the express, visit http://ooo.test.com/hello.

  1. Modify the code to change the redirect address to http://www.google.com
  2. Disable the Express service

Yes, as a result, no matter what did you do any changes, visit http://ooo.test.com/hello, or open the baidu home page. This is where persistent caching comes in — from disk cache! The permanent cache caches the redirection information in your browser, and unless you clear the browser cache, it doesn’t matter how your service changes, sorry, it doesn’t matter to you. This is the scary part about permanent caching.

Temporary caching is much more secure. Let’s change the above code slightly:

router.get('/hello', (req, res) => {
	// temporarily redirect this path to Baidu
	res.writeHead(302, { Location: 'http://www.baidu.com/' }); 
	res.end();
})
Copy the code

Open a browser to http://ooo.test.com/hello, you’ll find success to jump to baidu, observe the console; Visit http://ooo.test.com/hello again, and then observe express output console log.

The server will receive a request

In conclusion, ** gives two simple examples to illustrate the small role of status codes in assisting us to locate problems and realize functions. Write wrong, welcome every comrade to give critique! There are other status code usage scenarios, also welcome to leave a message to discuss a wave oh!

@Author: _Jay.Lam