Go Web programming first chapter Web related concepts

Chapter I. Go and Web apps

Go Learning Group: 415660935

1.1 Web app

in the world of computers, applications (application) are software programs that interact with users and accomplish user-specific tasks. Web apps are software programs that are deployed on the web and used through the web. A program satisfies the following two conditions, and we can think of it as a Web application:

1. This program must return to the client that sent the command request HTML, and the client presents the rendered HTML to the user.

2. This program must be used when transferring data to the client . HTTP protocol.

On the basis of this definition, if a program is not rendered and displayed to the user HTML, instead of returning some non-HTML-formatted data (such as XML and JSON) to other programs, the program is a Web service that serves other programs.

1.2 HTTP Introduction

protocol is the abbreviation of the network protocol, which refers to a set of conventions that both parties of the communication computer must comply with together. HTTP (Hypertext Transfer Protocol) is a hypertext Transfer protocol that defines the rules for communicating between a Web browser and a Web server. All the data in a Web program is transmitted through this seemingly simple, but unusually powerful, text protocol. Since this agreement was defined in the 1990s, only 3 iterations have been modified so far, with HTTP 1.1 currently used as a broad version, while the new version is HTTP 2.0, also known as HTTP/2.

HTTP is a stateless, text-based request-response (Request-response) protocol that uses a client-server (Client-server) model.

A request -response is the basic way that two computers communicate, and one computer sends a request to another computer, and the computer that receives the request responds to the request. In the client-server computing model, the party sending the request (the client) is responsible for initiating the session to the party that is returning the response (the server), while the server is responsible for servicing the client. In the HTTP protocol, the client is also referred to as the user agent (User-agent), and the server is often referred to as a WEB server. In most cases, the HTTP client is a Web browser.

HTTP is a stateless protocol, and the only thing that is known is that the client sends a request to the server, and the server returns a response to the client, and the subsequent request has no knowledge of the request that occurred.

As with many Internet protocols, HTTP is also sending and receiving protocol data in plain text rather than binary mode. This is done to make it easier for developers to troubleshoot what is happening in the communication without having to use specialized protocol analysis tools.

1.3 HTTP requests

HTTP is a request-response protocol, and everything involved in the protocol begins with a single request. An HTTP request consists of a series of lines of text that are arranged in the following order:

(1) request line (request-line);

(2) 0 or any number of request headers (header);

(3) a blank line;

(4) Optional message body (body).

a typical The HTTP request looks something like this:

Get/protocols/rfc2616/rfc2616.html http/1.1 Host:www.w3.org user-agent:mozilla/5.0 (Empty line)

The first line of text in this request is a request line:

Get/protocols/rfc2616/rfc2616.html http/1.1

The first word in the request line is the request method, followed by the Uniform Resource Identifier (Uniform Resource Identifier,uri) and the HTTP version used. The header of the two text behavior request that is located after the request line. Note that the following line of this message is a blank line, and even if the body part of the message is empty, the empty line must exist, as the message contains the subject which needs to be based on the method used for the request.

1.3.1 Request Method

The request method is the first word in the request line, which indicates what the client wants to do with the resource. HTTP 0.9 has only get one method, HTTP 1.0 adds the Post method and head method, and HTTP 1.1 adds 5 methods of put, DELETE, OPTIONS, Trace and connect, and allows developers to add more methods themselves -Many people immediately put this function into practice.

HTTP 1.1 requires only the Get method and the head method to be implemented, while the implementation of the other methods is optional, and even the post method is optional. The functions of each HTTP method are described as follows:

get--the command server to return the specified resource.

head--is similar to the GET method, except that the method does not require the server to return the body of the message. This method is often used to get the header of a response without acquiring a message body.

The post--command server passes the data in the message body to the resource specified by the URI, and the server is dependent on the server itself for what action it performs on the data.

The put--command server sets the data in the message body to the resource specified by the URI. If data already exists at the location specified by the URI, the data in the message body is used instead of the existing data. If the resource does not already exist, a new resource is created at the location specified by the URI.

The delete--command server deletes the resource specified by the URI.

The trace--command server returns the request itself. In this way, the client can know how the request is handled by other servers between it and the server.

The options--command server returns a list of HTTP methods that it supports.

connect--the command server to establish a network connection with the client. This method is typically used to set up an SSL tunnel to enable HTTPS functionality.

The patch--command server modifies the resource specified by the URI using the data in the message body.

1.3.2 Secure Request method

If a This method is safe if the HTTP method only requires the server to provide information without any modification to the state of the server. , OPTIONS, and TRACE do not modify the state of the server, so they are all safe methods. In contrast, both post, put, and delete can modify the state of the server (for example, when processing a POST request, the data stored by the server may change), so these methods are not a secure method.

method of request for 1.3.3 Idempotent

If a This method is idempotent (idempotent) when the HTTP method makes a second call using the same data without any change to the state of the server. According to the definition of a secure method, because all secure methods do not modify the server state, they are inherently idempotent.

Put and delete are not secure, but they are idempotent, because they do not change the state of the server when they make a second call: the resource specified by the URI has been updated or created since the server executed the first put request. So a second put request for the same resource only executes actions that the server has already performed, and similarly, although the server may return an error for the second delete request to the same resource, the request does not change the state of the server.

Conversely, because of repeated Whether the POST request alters the server state is determined by the server itself, so the post method is neither secure nor idempotent.

1.3.4 Browser support for request methods

The Get method is the basic HTTP method, which is responsible for fetching the content from the server, which is supported by all browsers. The Post method can be implemented from HTML 2.0 by adding HTML forms: The HTML form tag has a property called method, and the user can specify which method to use by setting the value of the property to get or post. HTML does not support HTTP methods other than Get and post: In the early drafts of the HTML5 specification, the method property of the HTML form has previously added support for the put method and the Delete method, but the support was later deleted.

that being said, popular browsers do not usually support only HTML a data format-users can use XMLHttpRequest (XHR) to gain support for the put method and Delte method. XHR is a series of browser APIs that are typically wrapped by JavaScript (actually XHR is a browser object named XMLHttpRequest). XHR allows programmers to send HTTP requests to the server, and unlike the name "XMLHttpRequest" implies, this technique is not limited to XML format--requests and responses in any format, including JSON and plain text, can be sent through XHR.

1.3.5 The header of the request

The HTTP request method defines the action that the client that sends the request wants to perform, and the header of the HTTP request records information about the request itself and the client. The header of the request consists of any number of plaintext key-value pairs separated by colons, ending with a carriage return (CR) and a newline (LF). Most HTTP request headers are optional, and the Host header field is the only mandatory header for HTTP 1.1. Depending on the method used for the request, if the requested message contains an optional principal, the header of the request also needs to have a content-length (content-length) field or a Transfer-encoding (transfer-encoding) field. Table 1-1 shows some of the common request headers.

Header field	Function description
Accept	The type of content that the client can receive in an HTTP response. For example, the client can tell the server that it wants to receive HTML-type content in the body of the response by accept:text/html the header.
Accept-charset	The client requires the character set encoding used by the server. For example, the client can tell the server that it wants to respond using the UTF-8 character set by Accept-charset:utf-8 this header
Authorization	This header is used to send a Basic authentication certificate to the server
Cookies	The client should pass all the cookies set before the server back to the server in this header. For example, if the server previously set 3 cookies on the browser, the cookie header field would contain the 3 cookies in a string and separate the cookies with semicolons. The following is a Cookie header example: Cookie:my_first_cookie=hello; My_second_cookie=world
Content-length	The byte length of the request Principal
Content-type	When the request contains a principal, this header is used to record the type of the principal content. When you send a POST or PUT request, the type of content defaults to x-www-form-urlen-coded, but when you upload a file, the type of the content should be set to Multipart/form-data (uploading the file can be done by setting the type of the input label Implemented as file) Vary
Host	The name of the server and the port number. If this header does not record the server's port number, it means that the server is using port 80
Referrer	The address of the page where the request originated
User-agent	To describe the client that initiated the request

1.4 HTTP Response

The HTTP response message is a reply to the HTTP request message. As with HTTP requests, the HTTP response is also made up of a series of lines of text, including:

1) a status line;

2) 0 or any number of response headers;

3) a blank line;

4) an optional message body.

HTTP responses are organized in exactly the same way that HTTP requests are organized. Here's what a typical HTTP response looks like (in order to save space, we omit some of the message body):

OK Date:sat, 12:58:58 GMT SERVER:APACHE/2 Last-modified:thu, 21:01:33 GMT content-length:33115 content-type:text/html; Charset=iso-8859-1 <! DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 strict//en" "Http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" > < HTML xmlns= ' http://www.w3.org/1999/xhtml ' >

The first behavior status line of the HTTP response, which contains the status code and the corresponding reason phrase (reason phrase), is a simple description of the status code for the reason phrase. In addition, the HTTP response in this example also contains an HTML-formatted message body.

1.4.1 Response status Code

as said before, The status code in the HTTP response indicates the type of response. There are 5 types of HTTP response status codes, each prefixed by a different number, as shown in table 1-2.

Status code type	Function description
1XX	Intelligence status Code. The server informs the client through these status codes that it has received the request sent by the client and has processed the request
2XX	Success status Code. These status codes indicate that the server has received the request sent by the client and has successfully processed the request. The standard response for this type of status code is "OK"
3XX	REDIRECT Status code. These status codes indicate that the server has received the request sent by the client and has successfully processed the request, but the client will need to do some additional work in order to complete the action specified by the request. This type of status code is mostly used to implement URL redirection
4XX	Client Error status code. This type of status code indicates that there are some problems with the request sent by the client. In this type of status code, the most common is "404 Not Found", this status code indicates that the server cannot find the requested resource from the URL specified by the client
5XX	Server error status code. When the server is unable to process the request correctly for some reason, the server uses this type of status code to notify the client. In this type of status code, the most common is the "Internal Server Error" status code

1.4.2 response header

The response header, like the request header, is composed of a colon-delimited, plain-text key-value pair, and is also followed by a carriage return ( CR) and the line break (LF) ends. Just as the request header can tell the server more about the request or related to the client's claim, the response header can also convey more information to the client related to the response or to the server (client-side) claim. Table 1-3 shows some of the common response headers.

Header field	Function description
Allow	Informs the client which request methods are supported by the server
Content-length	The byte length of the response body
Content-type	If the response contains an optional principal, then this header record is the type of the principal content
Date	Current time recorded in Greenwich Mean Time (GMT) format
Location	This header is used only for redirection, which tells the client which URL to send the request to next
Server	The domain name of the server that returned the response
Set-cookie	Set a cookie inside the client. A response can contain multiple Set-cookie headers
Www-authenticate	The server uses this header to tell the client what type of authentication information should be provided in the authorization request header. The server will often send this header with the "401 Unauthorized" status line. In addition, this header provides authentication information (challenge information) (such as the basic and digest access authentication mode described in RFC 2617) to the server-licensed Authentication Authorization mode (schema)

1.5 URI

Tim Berners-lee, while creating the World Wide Web, also introduced the concept of using location strings to represent Internet resources. He defined the Uniform Resource Identifier (Uniform Resource Identifier,uri) in RFC 1630, published in 1994. In this RFC, he describes a method that uses a string to represent a resource's name, and a method that uses a string to represent the location of a resource, where the previous method is known as the Uniform Resource name (Uniform Resource name,urn). The latter method is called the Uniform Resource Locator (Uniform Resource location,url). A URI is an inclusive term that contains a URN and a URL, and both have similar syntax and formatting. Because this book only discusses URLs, the URIs mentioned in this book refer to URLs. The general format of the URI is:

< scheme name >:< layered section >[? < query parameters >] [# < clips >]

Scheme name in the URI records the scheme that the URI is using, which defines the structure of the remainder of the URI. Because URIs are a very common way of identifying resources, they have a number of scenarios to use, but in most cases this book only uses HTTP scenarios. The hierarchical portion of the URI (hierarchical part) contains identifying information about the resource, which is organized hierarchically. If the layered section starts with a double slash (//), then it contains optional user information that ends with the @ sign followed by a hierarchical path. The layered part without user information is a simple path, each of which consists of a sequence of segments (segment) separated by a single slash (/) between each segment.

in the In each part of the URI, only the "schema name" and "layered section" are required. Query parameters prefixed with a question mark (?) are optional and are used to contain additional information that cannot be represented in a hierarchical manner. Multiple query parameters are organized into a series of key-value pairs, separated by a & symbol between each key-value pair. Another optional part of the URI is the fragment (fragment), which uses the pound sign (#) as the prefix, which identifies the secondary resource (secondary resource) in the resource defined by the URI. When a URI contains a query parameter, the fragment of the URI is placed after the query parameter. Because the fragment of the URI is handled by the client, the Web browser typically removes the fragment from the URI before sending it to the server. If the programmer wants to get the URI fragment, the URI fragment can be included in a GET request through JavaScript or an HTTP client library. Let's look at a URI example that uses the HTTP scheme: http://sausheong:[email protected] com/docs/file?name=sausheong&location= Singapore#summary. This URI uses the HTTP scheme, followed by a colon after the scheme name. The fragment Sausheong:password before the @ symbol records the user name and password, and the www.example.com/docs/file after the user information is the remainder of the layered section. At the top level of the hierarchy is the server's domain name www.example.com, followed by two layers, doc and file, separated by a single slash between each hierarchy. Following the layered section is a query parameter prefixed with a question mark (?), which contains the Name=sausheong and Location=singapore key-value pairs, with a & symbolic connection between key-value pairs. Finally, the end of the URI is accompanied by a fragment prefixed with the pound sign (#). Because each URL is a separate string, it is not possible to include spaces in the URL. In addition, symbols such as question marks (?) and Pound signs (#) have special meanings in URLs, so they cannot be used for other purposes. To avoid these limitations, we need to use URL encoding to convert these special symbols (URL encoding, also known as the Percent code). RFC 3986 defines reserved characters and non-reserved characters in the URL, all reserved characters need to be URLEncoding: URL encoding converts the reserved character to the corresponding byte value in the ASCII encoding of the character (byte value), and then represents the byte value as a two-bit long hexadecimal number followed by a percent (%) in front of the hexadecimal number. For example, a space in ASCII encoding has a byte value of 32, which is 20 in hexadecimal. As a result, the URL-encoded whitespace will be replaced with this value for all spaces in the%20,url. For example, in the next display of the URL, the user name Sau and sheong between the space is replaced by the%20:http://www.example.com/docs/file? Name=sau%20sheong&location=singapore.

1.6 http/2 Introduction

HTTP/2 is a new version of the HTTP protocol, a version that is very concerned about performance. The HTTP/2 protocol was improved by the SPDY/2 protocol, which was originally an open network protocol developed by Google for the purpose of transmitting WEB content.

that are represented in plain text mode. HTTP 1.x is different, HTTP/2 is a binary protocol: binary notation not only makes HTTP/2 's parsing more efficient, but also makes the protocol more compact and robust, but at the same time, for developers who are used to using HTTP 1.x, they will no longer be able to pass Applications such as Telnet send HTTP/2 messages directly for debugging.

Unlike HTTP 1.x, which can only send a single request at a time in a network connection, HTTP/2 is fully multiplexed (fully multiplexed), which means that multiple requests and responses can use the same connection at the same time. In addition, HTTP/2 also compresses the header to reduce the amount of data that needs to be transferred and allows the server to push the response (push) to the client, all of which can effectively improve performance.

because The scope of the application of HTTP is so extensive that any hasty modification of the syntax may cause damage to the existing Web, so although HTTP/2 has optimized the communication performance of the protocol, it does not modify the syntax of the HTTP protocol itself: in HTTP/2, HTTP methods and status codes can be the same syntax as HTTP 1.1.

in the Go 1.6 release, users will automatically use HTTP/2 when using HTTPS, while the previous version of Go 1.6 implements the HTTP/2 protocol in the GOLANG.ORG/X/NET/HTTP2 package.

1.7 components of a WEB application

through the previous introduction, we know A WEB application is a program that performs the following tasks:

(1) through the HTTP protocol, in the form of HTTP request messages to obtain client input;

(2) processing the HTTP request messages and performing the necessary operations;

(3) HTML is generated and returned to the client in the form of an HTTP response message.

to accomplish these tasks, Web applications are divided into two parts, the processor (handler) and the template engine.

1.7.1 Processor

In addition to receiving and processing requests from the client, the processor in the Web application needs to invoke the template engine, which then generates the HTML from the template engine and populates the data into the response message that will be passed back to the client.

1.7.2 template engine

through The HTML that the HTTP response message is passed back to the client is transformed by a template, which may contain HTML, but it may not, and the template engine uses templates and data to generate the final HTML.

Templates can be divided into static templates and dynamic templates two, both of which have their own design philosophy.

1. static templates are those that are mixed with placeholders HTML, the static template engine generates final HTML by replacing placeholders in static templates with corresponding data, which is very similar to the concept of SSI technology. Because static templates typically do not contain any logical code, or contain only a small amount of logical code, this template is also known as a non-logical template. Both ctemplate and mustache belong to the static template engine.

2. Dynamic Templates In addition to containing HTML and placeholders include some programming language constructs, such as conditional statements, iteration statements, and variables. JavaServer Pages (JSP), Active Server Pages (ASP), and Embedded Ruby (ERB) all belong to the dynamic template engine. When PHP was first born, it looked like a dynamic template, which evolved into a programming language.

Go Web programming first chapter Web related concepts