HTTP request

wang xiao bo 's photo
wang xiao bo
·Feb 21, 2022·

5 min read

Subscribe to my newsletter and never miss my upcoming articles

Table of contents

  • Content in the HTTP request

Content in the HTTP request

An HTTP request consists of three parts:

  • request line
  • capital
  • entity

The request line is roughly as long as GET /images/logo.gif HTTP/1.1, which basically consists of the request method, URL, and protocol version. It is worth mentioning the request method.

There are many kinds of request methods, the most commonly used are Get and Post. Although there are many request methods, it is more about conveying a semantic, not saying that what Post can do, Get can't do. You can use either a Get request or a Post request if you want. More semantic descriptions of request methods can be found in the documentation.

What's the Difference Between Post and Get?

First, the concepts of side effects and idempotency are introduced.

Side effects refer to making changes to resources on the server. Search has no side effects, and registration has side effects.

Idempotency refers to sending M and N requests (both are different and both greater than 1), and the status of resources on the server is consistent. For example, registering 10 and 11 accounts is not idempotent, and changing the article 10 and 11 times is idempotent. Because the former is one more account (resource), the latter just updates the same resource.

In terms of standard application scenarios, Get is mostly used in side-effect-free and idempotent scenarios, such as searching for keywords. Post is mostly used in side effects, not idempotent scenarios, such as registration.

Technically speaking:

  • Get requests can be cached, Post cannot.
  • Post is a little safer than Get, because Get requests are included in the URL (of course, you can write them in the body), and the browser will save the history. Post doesn't, but it's the same in the case of packet capture.
  • The URL has a length limit, which will affect the Get request, but this length limit is specified by the browser, not by the RFC. -Post supports more encoding types and does not limit data types.

capital

The headers are request headers and response headers, and some headers are common to both. Next, we will learn some common headers.

common header

  • Cache-Control:Control the behavior of the cache
  • Connection:The type of connection the browser wants to use in preference, such as keep-alive
  • Date: Create message time
  • Pragma: message command
  • Via: Proxy server related information
  • Transfer-Encoding: transfer encoding
  • Upgrade: Ask the client to upgrade the protocol
  • Warning: There may be errors in the content

request header

  • Accept: Types of media that can be received correctly
  • Accept-Charset: Character set that can be received correctly
  • Accept-Encoding: List of encoding formats that can be correctly received
  • Accept-Language: List of languages ​​that can be received correctly
  • Expect: Expect specified behavior from the server
  • From: Requester's email address
  • Host: server's domain name
  • If-Match: Comparison of resource tags at both ends
  • If-Modified-Since : Local resource not modified returns 304 (compare time)
  • User-Agent: Client information
  • Max-Forwards: Limit the number of times that can be forwarded by proxies and gateways
  • Proxy-Authorization: Send authentication information to proxy server
  • Range: request part of something
  • Referer: Represents the previous page visited by the browser

response header

  • Accept-Ranges: whether certain kinds of ranges are supported
  • Age: How long the resource has been in the proxy cache
  • ETag: Resource ID
  • Location: Client redirects to a URL
  • Proxy-Authenticate: Send authentication information to proxy server
  • Server: server name
  • WWW-Authenticate: Obtain the authentication information required for the resource

Common Status Codes

The status code represents a status of the response, which allows us to clearly understand whether the request succeeded or failed this time, and if it failed, what caused it. Of course, the status code is also used to convey semantics. If the status code is used indiscriminately, then its meaning is lost.

Status codes are often a common question.

2XX success

  • 200 OK 200 OK, indicating that the request from the client is correctly processed on the server side
  • 204 No content 204 No content, indicating that the request is successful, but the response message does not contain the body part of the entity
  • 205 Reset Content 205 Reset Content, indicating that the request is successful, but the response message does not contain the body part of the entity, but it is different from the 204 response in that the requester is required to reset the content
  • 206 Partial Content 206 Partial Content, make a range request

3XX redirect

  • 301 moved permanently 301 moved permanently, a permanent redirect, indicating that the resource has been assigned a new URL
  • 302 found 302 found, a temporary redirect, indicating that the resource is temporarily assigned a new URL
  • 303 see other 303 see other, indicating that there is another URL for the resource, and the GET method should be used to obtain the resource
  • 304 not modified 304 not modified, indicating that the server allows access to the resource, but the request does not meet the conditions due to the occurrence of
  • 307 temporary redirect 307 temporary redirect, temporary redirect, similar to 302, but expects the client to keep the request method unchanged and make a request to a new address

4XX Client Error

  • 400 bad request 400 bad request, there is a syntax error in the request message
  • 401 unauthorized 401 unauthorized, indicating that the request sent requires authentication information through HTTP authentication
  • 403 forbidden 403 forbidden, indicating that access to the requested resource was denied by the server
  • 404 not found 404 not found, indicating that the requested resource was not found on the server

5XX server error

  • 500 internal sever error 500 internal sever error, indicating that an error occurred on the server side when executing the request
  • 501 Not Implemented 501 Not Implemented, indicating that the server does not support a function required by the current request
  • 503 service unavailable 503 service unavailable, indicating that the server is temporarily overloaded or is down for maintenance and cannot process requests
 
Share this

Impressum

JavaScript Ruby on Rails