├── 1.PNG ├── 10.PNG ├── 11.PNG ├── 12.PNG ├── 13.PNG ├── 14.PNG ├── 15.PNG ├── 16.PNG ├── 17.PNG ├── 18.PNG ├── 19.PNG ├── 2.PNG ├── 20.PNG ├── 21.PNG ├── 22.PNG ├── 23.PNG ├── 24.PNG ├── 25.PNG ├── 26.PNG ├── 27.PNG ├── 28.PNG ├── 29.PNG ├── 3.PNG ├── 30.PNG ├── 31.PNG ├── 32.PNG ├── 33.PNG ├── 34.PNG ├── 35.PNG ├── 36.PNG ├── 37.PNG ├── 38.PNG ├── 39.PNG ├── 4.PNG ├── 40.PNG ├── 41.PNG ├── 42.PNG ├── 43.PNG ├── 44.webp ├── 5.PNG ├── 6.PNG ├── 8.PNG ├── 9.PNG └── README.md /1.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/1.PNG -------------------------------------------------------------------------------- /10.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/10.PNG -------------------------------------------------------------------------------- /11.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/11.PNG -------------------------------------------------------------------------------- /12.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/12.PNG -------------------------------------------------------------------------------- /13.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/13.PNG -------------------------------------------------------------------------------- /14.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/14.PNG -------------------------------------------------------------------------------- /15.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/15.PNG -------------------------------------------------------------------------------- /16.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/16.PNG -------------------------------------------------------------------------------- /17.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/17.PNG -------------------------------------------------------------------------------- /18.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/18.PNG -------------------------------------------------------------------------------- /19.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/19.PNG -------------------------------------------------------------------------------- /2.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/2.PNG -------------------------------------------------------------------------------- /20.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/20.PNG -------------------------------------------------------------------------------- /21.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/21.PNG -------------------------------------------------------------------------------- /22.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/22.PNG -------------------------------------------------------------------------------- /23.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/23.PNG -------------------------------------------------------------------------------- /24.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/24.PNG -------------------------------------------------------------------------------- /25.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/25.PNG -------------------------------------------------------------------------------- /26.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/26.PNG -------------------------------------------------------------------------------- /27.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/27.PNG -------------------------------------------------------------------------------- /28.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/28.PNG -------------------------------------------------------------------------------- /29.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/29.PNG -------------------------------------------------------------------------------- /3.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/3.PNG -------------------------------------------------------------------------------- /30.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/30.PNG -------------------------------------------------------------------------------- /31.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/31.PNG -------------------------------------------------------------------------------- /32.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/32.PNG -------------------------------------------------------------------------------- /33.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/33.PNG -------------------------------------------------------------------------------- /34.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/34.PNG -------------------------------------------------------------------------------- /35.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/35.PNG -------------------------------------------------------------------------------- /36.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/36.PNG -------------------------------------------------------------------------------- /37.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/37.PNG -------------------------------------------------------------------------------- /38.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/38.PNG -------------------------------------------------------------------------------- /39.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/39.PNG -------------------------------------------------------------------------------- /4.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/4.PNG -------------------------------------------------------------------------------- /40.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/40.PNG -------------------------------------------------------------------------------- /41.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/41.PNG -------------------------------------------------------------------------------- /42.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/42.PNG -------------------------------------------------------------------------------- /43.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/43.PNG -------------------------------------------------------------------------------- /44.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/44.webp -------------------------------------------------------------------------------- /5.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/5.PNG -------------------------------------------------------------------------------- /6.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/6.PNG -------------------------------------------------------------------------------- /8.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/8.PNG -------------------------------------------------------------------------------- /9.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/d8989a7997f950424ee5e397e3af792d78517609/9.PNG -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | # Introduction 5 | **HTTP** is a [protocol](https://developer.mozilla.org/en-US/docs/Glossary/Protocol) for fetching resources such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser. A complete document is reconstructed from the different sub-documents fetched, for instance, text, layout description, images, videos, scripts, and more. 6 | 7 | 8 | # HTTP Versions 9 | 10 | Following lists specify Application protocol for distributed hypermedia 11 | 12 | - First documented in 1991 (HTTP/0.9) 13 | - HTTP/1.0 introduced in 1996 (RFC 1945) 14 | - HTTP/1.1 updated in 1999 (RFC 2616) 15 | - HTTP/2.0 updated in 2015 (RFC 7540) 16 | 17 | # HTTP Protocol Request/Response 18 | Hyper Text Transfer (HTTP) Protocol Request/Response includes Client and server exchange request/response messages, which uses the TCP protocol. For Client and server exchange request/response, the typical port number is 80. 19 | 20 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/1.PNG) 21 | 22 | 23 | **Request structure** 24 | 25 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/37.PNG) 26 | **Example:** 27 | 28 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/43.PNG) 29 | 30 | **Response structure** 31 | 32 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/39.PNG) 33 | 34 | **Example:** 35 | 36 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/42.PNG) 37 | 38 | 39 | 40 | # HTTP Status Codes 41 | An HTTP status code is a server response to a browser’s request. When you visit a website, your browser sends a request to the site’s server, and the server then responds to the browser’s request with a three-digit code: the HTTP status code. 42 | 43 | 44 | **1×× Informational** 45 | 46 | - 100 Continue 47 | - 101 Switching Protocols 48 | - 102 Processing 49 | 50 | **2×× Success** 51 | 52 | - 200 OK 53 | - 201 Created 54 | - 202 Accepted 55 | - 204 No Content 56 | - 206 Partial Content 57 | 58 | **3×× Redirection** 59 | 60 | - 300 Multiple Choices 61 | - 301 Moved Permanently 62 | - 302 Found 63 | - 305 Use Proxy 64 | 65 | 66 | **4×× Client Error** 67 | 68 | - 400 Bad Request 69 | - 401 Unauthorized 70 | - 403 Forbidden 71 | - 404 Not Found 72 | - 405 Method Not Allowed 73 | 74 | **5×× Server Error** 75 | 76 | - 500 Internal Server Error 77 | - 503 Service Unavailable 78 | - 504 Gateway Timeout 79 | 80 | 81 | 82 | # HTTP Methods 83 | 84 | - GET - retrieves whatever information identified by the Request-URL 85 | - POST - sends data to the server for updates. 86 | - PUT - requests that the enclosed entity stored under the supplied Request-URL. 87 | - DELETE - requests the origin server to delete the resource identified by the Request-URL. 88 | - HEAD - Similar to the GET method, except that the server must not return a message-body in the response. 89 | - TRACE - Allows the client to see what received at the other end of the request chain and use that data for testing 90 | 91 | # HTTP/1.1 Header 92 | **HTTP headers** let the client and the server pass additional information with an HTTP request or response. An HTTP header consists of its case-insensitive name followed by a colon (`:`), then by its value. [Whitespace](https://developer.mozilla.org/en-US/docs/Glossary/Whitespace) before the value is ignored. 93 | 94 | ## HTTP/1.1 Request Header Examples 95 | 96 | 97 | - Accept: specify desired media type of response 98 | - Accept-Language: specify the desired language of response 99 | - Accept-Encoding: The encoding algorithm, usually a [compression algorithm] 100 | - Date: date/time at which the message originated 101 | - Host: host and port number of requested resource 102 | - Referrer: URL of the previously visited resource 103 | - User-Agent: identifier string for a Web browser or user agent 104 | 105 | ## HTTP/1.1 Response Header Examples 106 | 107 | - Content-Language: the language of representation 108 | - Content-Type: media type of representation 109 | - Content-Length: length in bytes of representation 110 | - Date: date/time at which the message originated 111 | - Expires: date/time after which response is considered stale 112 | - Last-Modified: date/time at which representation was last change 113 | - Set-Cookie: used to send a cookie from the server to the user agent 114 | 115 | 116 | 117 | # HTTP/1.0 and earlier 118 | Before HTTP/1.1, each HTTP request used a separate TCP connection as shown in the figure below. 119 | 120 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/2.PNG) 121 | 122 | # HTTP Keep-Alive 123 | HTTP/1.1 introduced the keyword “Keep-Alive.” TCP connections reused for multiple HTTP requests. HTTP uses the keyword “Keep-Alive” in the “Connection” header to denote that the connection is open for additional messages. “Keep-Alive” exists default in HTTP/1.1 while in HTTP/1.0, the default is to use a new connection for each request or reply pair. 124 | 125 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/3.PNG) 126 | # HTTP Pipelining 127 | HTTP/1.1 pipelining is a technique in which multiple HTTP requests sent on a single TCP connection without waiting for the corresponding responses. 128 | 129 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/4.PNG) 130 | 131 | 132 | # Cookies 133 | A cookie is a text file stored on the hard drive (more precisely in the browser folder) when visiting a website. 134 | 135 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/44.webp) 136 | 137 | ## Types of Cookies 138 | 139 | - **Session**: They expire when the browser is closed or remained idle. For example, they are used in ecommerce websites to continue browsing without losing chosen items in the cart. 140 | 141 | - **Permanent**: They persist even after the browser exits. They have an expiration date though, as per law that limits lasting more than six months. They assist in remembering passwords and login information to reduce the need of re-entering them every time. 142 | 143 | - **Third party**: Third-party cookies are cookies that are set by a website other than the one you are currently on. For example, you can have a "Like" button on your website which will store a cookie on a visitor's computer, that cookie can later be accessed by Facebook to identify visitors and see which websites they visited. Such a cookie is considered to be a 3rd party cookie. 144 | 145 | The Set-Cookie HTTP response header sends cookies from the server to the user agent. This header from the server tells the client to store a cookie. 146 | 147 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/5.PNG) 148 | 149 | This header from the server tells the client to store a cookie. 150 | 151 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/6.PNG) 152 | Now, with every new request to the server, the browser will send back all previously stored cookies to the server using the Cookie header. 153 | 154 | # Authentication 155 | 156 | HTTP supports the use of several authentication mechanisms to control access to pages and other resources. These mechanisms are all based around the use of the 401-status code and the WWW-Authenticate response header. 157 | 158 | The most widely used HTTP authentication mechanisms are as follows: 159 | - **Basic**: The client sends the user name and password as encrypted base64 encoded text. It should only be used with HTTPS, as the password can be easily captured and reused over HTTP. 160 | - **Digest**: The client sends a hashed form of the password to the server. Though the password cannot catch over HTTP, it may be possible to replay requests using the hashed password. 161 | 162 | **Force Authentication** 163 | If an HTTP receives an anonymous request for a protected resource it can force the use of Basic authentication by rejecting the request with a **401** (Access Denied) status code and setting the **WWW-Authenticate** response header as shown below: 164 | 165 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/8.PNG) 166 | The word **Basic** in the **WWW-Authenticate** selects the authentication mechanism that the HTTP client must use to access the resource. The **realm** string can be set to any value to identify the secure area and may be used by HTTP clients to manage passwords. 167 | 168 | Most web browsers will display a **login** dialog when this response is received, allowing the user to enter a **Username** and **Password**. This information is then used to retry the request with an Authorization request header: 169 | 170 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/9.PNG) 171 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/10.PNG) 172 | # User Agent 173 | In computing, a user agent is a software (a software agent) that is acting on behalf of a user. One common use of the term refers to a web browser telling website information about the browser and operating system. This allows the website to customize content for the capabilities of a particular device, but also raises privacy issues. In HTTP, the User-Agent string often used for content negotiation, where the origin server selects suitable content or operating parameters for the response 174 | 175 | ## sample: 176 | [Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36](https://developers.whatismybrowser.com/useragents/parse/1302411chrome-windows-blink) 177 | 178 | # Content Negotiation 179 | In HTTP, **_content negotiation_** is the mechanism that is used for serving different representations of a resource to the same URI to help the user agent specify which representation is best suited for the user (for example, which document language, which image format, or which content encoding). 180 | 181 | 182 | 183 | ## Principles of content negotiation 184 | 185 | A specific document is called a _resource_. When a client wants to obtain a resource, the client requests it via a URL. The server uses this URL to choose one of the variants available–each variant is called a _representation_–and returns a specific representation to the client. The overall resource, as well as each of the representations, has a specific URL. _Content negotiation_ determines how a specific representation is chosen when the resource is called. There are several ways of negotiating between the client and the server. 186 | 187 | ![enter image description here](https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation/httpnego.png) 188 | 189 | HTTP provides for several different content negotiation mechanisms including: 190 | 191 | - Server-driven 192 | - Agent-driven 193 | 194 | 195 | ## Server-driven content negotiation 196 | 197 | In _server-driven content negotiation_, or proactive content negotiation, the browser (or any other kind of user agent) sends several HTTP headers along with the URL. These headers describe the user's preferred choice. The server uses them as hints and an internal algorithm chooses the best content to serve to the client. 198 | 199 | 200 | **Example Negotiation Headers** 201 | 202 | - **Accept**: Which media types are acceptable for the response, such as “application/json,” “application/xml”. 203 | - **Accept-Charset**: Which character sets are acceptable, such as UTF-8 or ISO 8859-1. 204 | - **Accept-Encoding**: Which content encodings are acceptable, such as gzip. 205 | - **Accept-Language**: The preferred natural language, such as "en-us." 206 | 207 | 208 | 209 | 210 | ![enter image description here](https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation/httpnegoserver.png) 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | ## Agent-driven negotiation 219 | 220 | HTTP allows another negotiation type: _agent-driven negotiation_ or _reactive negotiation_. In this case, the server sends back a page that contains links to the available alternative resources when faced with an ambiguous request. The user is presented the resources and chooses the one to use. 221 | 222 | ![enter image description here](https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation/httpnego3.png) 223 | 224 | 225 | 226 | # MIME Encoding 227 | 228 | HTTP is largely a text-based protocol. Binary content needs some way of transmission. MIME is an acronym for Multipurpose Internet Mail Extension. It is used to describe message content types. MIME messages can contain the text, images, audio, video and other application-specific data (For examples: PDF files, Microsoft Word Documents, and so on). 229 | It assists to make internet messages richer. It allows applications (and users) to exchange rich content other than text. 230 | 231 | ## MIME Format 232 | MIME types are defined using a **<type>/<subtype> [optional parameters]** format. Some typical examples are as follows: 233 | 234 | 235 | |MIME Type | Extension(s) | 236 | |--|--| 237 | | application/json | json| 238 | | application/pdf| pdf| 239 | | text/plain | txt | 240 | | text/html | html ; htm | 241 | | text/css | css | 242 | | text/javascript | javascript | 243 | | video/mp4| mp4| 244 | | video/3gp| 3gp| 245 | 246 | ## How is it used? (MIME) 247 | MIME passes as a part of the content type of the message header. 248 | 249 | - Content-type: text/plain; charset=“us- ascii” 250 | - The following example is a typical HTTP Response header (MIME highlighted) 251 | 252 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/11.PNG) 253 | 254 | ## Sending large Messages (MIME) 255 | When sending large messages, the message client splits them into smaller parts. This type of message is called a multi-part message. Multi-part messages have one of the MIME content types such as **content-type = form-data 256 | 257 | # HTTP Caching 258 | Web pages often contain content that remains unchanged for long periods. For example, an image containing a company logo may be used without modification for many years. It is wasteful in terms of bandwidth and round trips to repeatedly download images or other content that is not regularly updated. 259 | 260 | HTTP supports caching so that content can be stored locally by the browser and reused when required. Of course, some types of data such as stock prices and weather forecasts are frequently changed and it is important that the browser does not display stale versions of these resources. By carefully controlling caching, it is possible to reuse static content and prevent the storage of dynamic data. 261 | 262 | Browser caching is controlled by the use of the Cache-Control, Last-Modified and Expires response headers. 263 | 264 | ## Preventing Caching 265 | 266 | - Servers set the Cache-Control response header to no-cache to indicate that content should not be cached by the browser: 267 | 268 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/16.PNG) 269 | - Also, the Pragma header is also often used to stop caching by HTTP 1.0 proxies as they do not support the Cache-Control header: 270 | 271 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/17.PNG) 272 | ## Allowing Caching 273 | The Cache-Control header can be set to one of the following values to allow caching: 274 | 275 | - >: If the Cache-Control header is not set, then any cache may store the content. 276 | - Private: The content is intended for use by a single user and should only be cached locally in the browser. 277 | - Public: The content may be cached in public caches (e.g. shared proxies) and private browser caches. 278 | 279 | If the browser is to make effective use of cached content, two extra pieces of information should be supplied. The first is the modification date/time of the content. The server supplies this in the **Last-Modified** response header: 280 | 281 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/18.PNG) 282 | The second piece of information is the expiration date that is specified with the **Expires** header: 283 | 284 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/19.PNG) 285 | This header will set the cache expiration to be **31536000** seconds or one year in the future: 286 | 287 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/20.PNG) 288 | ## Cache Validation and the 304 response 289 | There are a number of situations in which Internet Explorer needs to check whether a cached entry is valid: 290 | 291 | - The cached entry has no expiration date and the content is being accessed for the first time in a browser session 292 | - The cached entry has an expiration date but it has expired 293 | - The user has requested a page update by clicking the Refresh button or pressing F5 294 | - If the cached entry has the last modification date, IE sends it in the **If-Modified-Since** header of a GET request message: 295 | 296 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/21.PNG) 297 | - The server checks the **If-Modified-Since** header and responds accordingly. If the content has not been changed since the date/time specified, it replies with a status code of 304 and a response message that just contains headers: 298 | 299 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/22.PNG) 300 | # What is HTTP/2? 301 | HTTP/2 is the first upgrade to the Hypertext Transfer Protocol since 1999. It’s goal is to improve website performance by optimizing how HTTP is expressed “on-the-wire.” It doesn’t change the semantics of HTTP, which means header fields, status codes, and cookies work exactly the same way as in HTTP/1.1. 302 | 303 | 304 | ## Benefits of HTTP/2 305 | HTTP/2 introduces several new features, and they’re all designed to improve page load times for your website visitors. 306 | 307 | ### Multiplexing 308 | Multiplexing is perhaps the most significant benefit of HTTP/2. HTTP/1.1 requires each request to use its own TCP connection. Multiplexing, in contrast, allows a browser to include multiple requests in a single TCP connection. 309 | 310 | The problem is, a browser can only have a limited number of TCP connections open at any given time. For HTTP/1.1, this means a browser can only load a single resource at a time—every asset in a web page is sent back to the browser sequentially. Multiplexing allows a browser to request all these assets in parallel. This results in a dramatic performance gain. 311 | 312 | ![enter image description here](https://www.cloudflare.com/img/products/website-optimization/http2/network-graph-http-1.svg) 313 | 314 | 315 | 316 | ![enter image description here](https://www.cloudflare.com/img/products/website-optimization/http2/network-graph-http-2.svg) 317 | HTTP/1.1 is sort of like buying a single item at a grocery store, taking it back home, going back to the store for the next item you need, and repeating until your pantry is fully stocked. Multiplexing gives you a shopping cart so you can pick up everything you need in one trip. 318 | 319 | 320 | 321 | ### Header Compression 322 | Modern websites rely on a lot of external assets: images, CSS, JavaScript, and fonts, just to name a few. Each time a browser requests one of these assets, it includes an HTTP header with the request. When the server sends the asset back to the browser, it also includes an HTTP response header. That’s a lot of overhead for the typical web page. 323 | 324 | HTTP/2 forces all HTTP headers to be sent in a compressed format, reducing the amount of information that needs to be exchanged between browser and server. HTTP/1.1 does not provide any form of header compression. 325 | 326 | ### Server Push 327 | HTTP/2 Server Push lets our edge network send web assets back to your browser before it even knows it needs them. This speeds up page load times by eliminating unnecessary round trips. For example, when a browser requests an HTML page, you can “push” all of the CSS stylesheets, image resources, and other assets inside of that web page. After the browser parses the HTML and finds all those assets, they’ll already be loaded into the local browser cache. This avoids extra requests back to the server. 328 | 329 | 330 | ### Stream Priority 331 | Stream priority is a mechanism for browsers to specify which assets they would like to receive first. For example, an HTTP/2-aware browser can use stream priority to load the HTML for a page first, followed by CSS, then JavaScript, and finally image assets. This order allows the browser to render the page as quickly as possible. 332 | 333 | You can think of stream priority as an optimization on top of multiplexing. Multiplexing lets you send several requests in a single TCP connection, and stream priority lets you define the order of the responses. While multiplexing eliminates much of the TCP overhead, it does nothing to optimize transfer times from the server to the browser. This is what stream priority is for. 334 | 335 | 336 | 337 | 338 | # REST (Representational State Transfer) 339 | 340 | REST stands for Representational State Transfer. (It is sometimes spelled “ReST.”) It relies on a stateless, client-server, cacheable communications protocol, and in virtually all cases, the HTTP protocol is used. REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines. In many ways, the World Wide Web itself, based on HTTP, viewed as a REST-based architecture. RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations. 341 | 342 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/26.PNG) 343 | 344 | # WebSocket 345 | WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011, and the WebSocket API in Web IDL is being standardized by the W3C. WebSocket is a different TCP protocol from HTTP. 346 | 347 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/32.PNG) 348 | 349 | ## Protocol handshake 350 | To establish a WebSocket connection, the client sends a WebSocket handshake request, for which the server returns a WebSocket handshake response, as shown in the example below. 351 | **Client request** (just like in HTTP, each line ends with \r\n and there must be an extra blank line at the end) 352 | 353 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/33.PNG) 354 | 355 | **Server response** 356 | 357 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/34.PNG) 358 | # HTTP Long Polling 359 | Web app developers can implement a technique called HTTP long polling, where the client polls the server requesting new information. The server holds the request open until new data is available. Once available, the server responds and sends the new information. When the client receives the new information, it immediately sends another request, and the operation is repeated. This effectively emulates a server push feature. 360 | 361 | 362 | ![enter image description here](https://raw.githubusercontent.com/gitmag-group-admin/http_protocol/main/35.PNG) 363 | 364 | # Web DAV 365 | 366 | 367 | WebDAV stands for Web Distributed Authoring and Versioning, which is an extension to HTTP that lets clients edit remote content on the web. In essence, WebDAV enables a web server to act as a file server, allowing authors to collaborate on web content. 368 | 369 | WebDAV enriches the standard set of HTTP headers and methods to let you create, move and edit files, as well as delete or copy files and folders. As an extension to HTTP, Web Distributed Authoring and Versioning usually uses port 80 for plain, unencrypted access and port 443 if you use the [SSL/TLS](https://www.cloudwards.net/ssl-vs-tls/) protocol. 370 | 371 | --------------------------------------------------------------------------------