Introduction to the HTTP protocol and web framework

Introduction to the HTTP protocol and web frameworkfirst, the HTTP protocol

Introduction to HTTP

The HTTP protocol is an abbreviation for the Hyper Text Transfer Protocol (Hypertext Transfer Protocol), which is used to transfer hypertext to the local browser from the World Wide Web (www:world Wide Web) server.

HTTP is a TCP/IP communication protocol that transmits data (HTML files, image files, query results, and so on).

HTTP is an object-oriented protocol belonging to the application layer, which is suitable for distributed hypermedia information System because of its simple and fast way. It was proposed in 1990, after several years of use and development, has been continuously improved and expanded. Currently used in the WWW is the sixth edition of Http/1.0, http/1.1 standardization work is in progress, and Http-ng (Next Generation of HTTP) has been proposed.

The HTTP protocol works on the client-server architecture. The browser sends all requests via URLs to the HTTP server, which is the Web servers, as an HTTP client. The Web server sends a response message to the client, based on the received request.

HTTP Features

1, simple and fast: When a customer requests a service from the server, it simply transmits the request method and path. The request method commonly has, POST. Each method specifies a different type of contact between the customer and the server.

Because the HTTP protocol is simple, the HTTP server's program size is small, so the communication speed is fast.

2, Flexible: HTTP allows the transfer of any type of data objects. The type being transmitted is marked by Content-type.

3, no connection: The meaning of no connection is to limit the processing of one request per connection. When the server finishes processing the customer's request and receives the customer's answer, the connection is disconnected. In this way, the transmission time can be saved.

4, stateless: HTTP protocol is a stateless protocol. Stateless means that the protocol has no memory capacity for transactional processing.

A lack of state means that if the previous information is required for subsequent processing, it must be re-routed, which may cause the amount of data to be transferred per connection to increase. On the other hand, it responds faster when the server does not need the previous information.

HTTP Request Protocol

The request agreement complies with the following format:

Request the first line;/        / Request Path protocol and version, for example: get/index.html http/1.1 request header information;      //  Request Header name: request Header content, This is the key:value format, for example: Host:localhost blank line;           //  used to separate the request body from the request body .         //  get no request body, only post has request body. 

The browser sends the contents of the server to this format, if not this format the server will not be able to interpret! In the HTTP protocol, there are many request methods for requests, the most common of which is GET and POST.

GET request

Get/562f25980001b1b106000338.jpg http/1.1Host    img.mukewang.comUser-agent    mozilla/5.0 (Windows NT 10.0; WOW64) applewebkit/537.36 (khtml, like Gecko) chrome/51.0.2704.106 safari/537.36Accept    image/webp,image /*,*/*; q=0.8referer    http://www.imooc.com/Accept-Encoding    gzip, deflate, Sdchaccept-language    zh-cn,zh;q=0.8

The HTTP default request method is get

Features of GET requests:
* No request body
* Data volume is limited!
* GET request data is exposed in the browser's address bar

Get requests commonly used actions:
1. Give the URL directly in the address bar of the browser, then it must be a GET request
2. Clicking on a hyperlink on the page must also be a GET request
3. When submitting a form, the form uses the GET request by default, but can be set to post

Request Header:

""" 1, the host requests the Web server domain name Address 2, the User-agenthttp client runs the browser type details. With this header information, the Web server can determine the type of browser for the HTTP request client. 3, accept specifies the content type that the client can receive, the order of the content type indicates the order that the customer receives 4, Accept-lanuage specifies the language that the HTTP client browser uses to display the preferred choice of return information 5, accept-encoding specifies that the Web server that the client browser can support returns the content compression encoding type. Indicates that the server is allowed to compress the output before it is sent to the client to conserve bandwidth. The return compression format that the client browser can support is set here. 6, accept-charsethttp the client browser can accept the character encoding set 7, Content-type displays the content type submitted by this HTTP request. This property is typically only required for post submission. There are two encoding types for the Content-type property value: (1) "application/x-www-form-urlencoded": the type of encoding the form data is submitted to the server, The default defaults are "application/x-www-form-urlencoded".     However, this encoding is inefficient when sending large amounts of text to the server, including text or binary data that contains non-ASCII characters. (2) "Multipart/form-data": When the file is uploaded, the type of encoding used should be "Multipart/form-data", which can both send text data and support binary data upload. You can use "application/x-www-form-urlencoded" when committing to form data, and when you commit a file, you need to use the "multipart/form-data" encoding type. """

POST request

The data sent by the POST request is saved in the request body, so the data is more secure

post/http1.1Host:www.wrox.comUser-agent:mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;. NET CLR 2.0.50727;. NET CLR 3.0.04506.648;. NET CLR 3.5.21022) content-type:application/ x-www-form-urlencodedcontent-length:40connection:keep-alivename=professional%20ajax& Publisher=wiley

HTTP Response Protocol

Response format

In general, the server will return an HTTP response message after receiving and processing a request from the client.

The HTTP response is also made up of four parts: the status line, the message header, the blank line, and the response body.

The first part: The status line, consists of the HTTP protocol version number, the status code, the status message three parts.

The first behavior status line, (http/1.1) indicates that the HTTP version is 1.1, the status code is 200, and the status message is (OK)

Part II: Message headers that describe some additional information that the client will use

The second line and the third behavior message header,
Date: The day and time the response was generated; Content-type: The MIME-type HTML (text/html) is specified and the encoding type is UTF-8

The third part: A blank line, a blank line after the message header is required. The HTML portion following the empty line is the response body. Part IV: The response body, the text information that the server returns to the client.

　　　　　　

Response Status Code

The status code consists of three digits, and the first number defines the category of the response, divided into five categories: 1xx: Indication Information--indicates that the request has been received and continues processing 2xx: Success--indicates that the request has been successfully received, understood, accepted 3xx: redirect--further action is required to complete the request 4xx: Client Error--request syntax error or request cannot be implemented 5XX: server-side error--the server failed to implement a legitimate request for a common status code:OK//Client Request succeededRequest//client requests have syntax errors and cannot be understood by the server401 Unauthorized//request is not authorized, this status code must be used with the Www-authenticate header field403 Forbidden//the server received the request but refused to provide the service404 Not Found//Request resource does not exist, eg: the wrong URL was enteredInternal Server Error//Unexpected error occurred on server503 Server Unavailable//the server is currently unable to process client requests and may return to normal after some time

The difference between get and post requests

 #  get request  Get/books/?sex=man&name =professional http/1.1host:www.wrox.comuser -agent:mozilla/5.0 (Windows; U Windows NT 5.1; En-us; Rv:1.7.6) Gecko /20050225 firefox/1.0.1 Connection:keep -alive Note that the last line is a blank line  #  post request  Post/http/1.1host:www.wrox.comuser -agent:mozilla/5.0 (Windows; U Windows NT 5.1; En-us; Rv:1.7.6) Gecko /20050225 firefox/1.0.1content -type:application/x-www-form-urlencodedcontent -length:40connection:keep -alivename  =professional%20ajax& Publisher=wiley 

1, get commits, the requested data will be appended to the URL (that is, the data placed in the HTTP protocol header), to split the URL and transfer data, multiple parameters with & connection ; For example: LOGIN.ACTION?NAME=HYDDD &password=idontknow&verify=%e4%bd%a0%E5%A5%BD. If the data is an English letter/number, sent as is, if it is a space, converted to +, if it is Chinese/other characters, the string is directly encrypted with BASE64, such as:%E4%BD%A0%E5%A5%BD, where the xx in%xx is the symbol in 16 binary notation ASCII.

Post submission: Place the submitted data in the package of the HTTP packet. In the example above, the red font indicates the actual transfer data

Therefore, the data submitted by get is displayed in the Address bar, and the address bar does not change when the post is submitted.

2, the size of the transmitted data: first of all: the HTTP protocol does not restrict the size of the transmitted data, the HTTP protocol specification does not limit the length of the URL.

The main limitations in the actual development are:

• • GET: Specific browsers and servers have restrictions on URL length, such as IE's limit on URL length is 2083 bytes (2k+35). For other browsers, such as Netscape, Firefox, etc., there is theoretically no length limit, and its limitations depend on the support of the operating system. Therefore, for a get commit, the transmitted data is limited by the URL length.

• • POST: The theoretical data is not limited because it is not transmitted via a URL. However, the actual Web server will be required to limit the size of the post submission data, Apache, IIS6 have their own configuration.

The difference between get and post

1. Get submitted data is placed after the URL, to split the URL and transfer data, the parameters are connected with &, such as editposts.aspx?name=test1&id=123456. The Post method is to put the submitted data in the body of the HTTP packet.
2. The data size for get commits is limited (because the browser has a limit on the length of the URL), and there is no limit to the data submitted by the Post method.
3. The Get method needs to use Request.QueryString to get the value of the variable, and the Post method takes the value of the variable by Request.Form.
4. The Get method submits the data, which brings security problems, such as a login page, when the data is submitted via get, the user name and password will appear on the URL, and if the page can be cached or someone else can access the machine, the user's account and password can be obtained from the history record.

ii. Web application to Web framework

Web Apps

For all Web applications, essentially a socket server, the user's browser is actually a socket client.

ImportSocketdefhandle_request (client): BUF= CLIENT.RECV (1024) Client.send ("http/1.1 ok\r\n\r\n". Encode ("UTF8")) Client.send ("
". Encode ("UTF8"))defMain (): Sock=Socket.socket (socket.af_inet, socket. Sock_stream) Sock.bind (('localhost', 8001)) Sock.listen (5)     whiletrue:connection, Address=sock.accept () handle_request (connection) connection.close ()if __name__=='__main__': Main ()

The simplest Web application is to first save the HTML file, with a ready-made HTTP Server software, to receive user requests, from the file to read HTML, return.

If you want to generate HTML dynamically, you need to implement the above steps yourself. However, accepting HTTP requests, parsing HTTP requests, and sending HTTP responses are all menial jobs, and if we're writing these underlying code ourselves, it's going to take months to read the HTTP specification before we start writing Dynamic HTML.

The correct approach is that the underlying code is implemented by specialized server software, and we use Python to focus on generating HTML documents. Because we don't want to be exposed to TCP connections, HTTP RAW requests, and response formats, we need a unified interface that lets us focus on writing Web services in Python.

This interface is WSGI: Web Server Gateway Interface.

WSGIREF Module

 fromWsgiref.simple_serverImportMake_server
defapplication (environ, start_response): Start_response ('OK', [('Content-type','text/html')])    return[b'']httpd= Make_server ("', 8080, application)Print('serving HTTP on port 8000 ...')#start listening for HTTP requests:Httpd.serve_forever ()

Introduction to the HTTP protocol and web framework