## Client server interaction ### headers w3.org ### hypertext transfe protocol wikipedia ### Basics ( http protocol wikibookgs) Its an application protocol **HTTP** stands for hypertext transfer protocol and is used to transfer data across the Web. Like most of the Internet protocols it is a **command** and **response** text based protocol using a **client server** communications model. The **HTTP protocol** is also a stateless protocol meaning that the server isn’t required to store session information and each request is independent of the other This means: - All requests originate at the client ( your browser) - The server responds to a request. - The requests(commands) and responses are in readable text. - The requests are independent of each other and the server **doesn’t need to track** the requests. A request consists of: **A command or request** + **optional headers** + **optional body content**. A response consists of: **A status code** + **optional headers** + **optional body content**. HTTP allows for communication between a variety of hosts and clients, and supports a mixture of network configurations. To make this possible, it assumes very little about a particular system, and does not keep state between different message exchanges. This makes HTTP a **stateless** protocol. The communication usually takes place over TCP/IP, but any reliable transport can be used. The default port for TCP/IP is **80**, but other ports can also be used. What this means is that unlike other file transfer protocols such as FTP , the HTTP connection is dropped once the request has been made. Communication between a host and a client occurs, via a **request/response pair** The current version of the protocol is **HTTP/1.1**, which adds a few extra features to the previous 1.0 version. The most important of these, in my opinion, includes _persistent connections_, _chunked transfer-coding_ and _fine-grained caching headers_ ## Status codes **Response Status codes** are split into 5 groups each group has a meaning and a three digit code. - **1xx** – Informational - **2xx** – Successful - **3xx** -Multiple Choice - **4xx**– Client Error - **5xx** -Server Error https://github.com/for-GET/know-your-http-well/blob/master/status-codes.md https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6 ## Request REQUEST LINE **Method** + Resource Path + protocol version **GET /test.htm HTTP/1.1** 1. A relative path doesn’t include the domain name. 2. The web browser uses the URL that we enter to create the **relative URI** of the resource. + HEADER LINE headers + ENTITY BODY For the POST METHOD ## Response STATUS LINE - **STATUS code** And Description - HTTP/1.0 200 OK - 1 or more optional headers - Optional Body message can be many lines including binary data + HEADER LINE + ENTITY BODY ## Methods POST Create 201 (Created), ‘Location’ header with link to /users/{id} containing new ID. Avoid using POST on single resource GET Read 200 (OK), list of users. Use pagination, sorting and filtering to navigate big lists. 200 (OK), single user. 404 (Not Found), if ID not found or invalid. PUT Update/Replace 404 (Not Found), unless you want to update every resource in the entire collection of resource. 200 (OK) or 204 (No Content). Use 404 (Not Found), if ID not found or invalid. PATCH Partial Update/Modify 404 (Not Found), unless you want to modify the collection itself. 200 (OK) or 204 (No Content). Use 404 (Not Found), if ID not found or invalid. DELETE 404 (Not Found), unless you want to delete the whole collection — use with caution. 200 (OK). 404 (Not Found), if ID not found or invalid. CONNECT Some proxy servers might need authority to create a tunnel. See also the Proxy-Authorization header. use with a proxy that can dynamically switch to being a tunnel OPTIONS To find out which request methods a server supports, one can use curl and issue an OPTIONS request TRACE TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information As per HTTP specification, the **GET and HEAD methods should be used only for retrieval of resource representations** – and they do not update/delete the resource on the server. Both methods are said to be considered “**safe**“. The term idempotent is used more comprehensively to describe an **operation that will produce the same results if executed once or multiple times** he methods **GET, HEAD, PUT and DELETE are declared idempotent methods**. Other methods OPTIONS and TRACE SHOULD NOT have side effects so both are also inherently idempotent. ## Cookies The server sends the following in its response header to set a cookie field. `Set-Cookie:`_name_`=`_value_ If there is a cookie set, then the browser sends the following in its request header. `Cookie:`_name_`=`_value_ **Cookies are essentially used to store a session id**. In the past cookies were used to store various types of data, since there was no alternative. But nowadays with the Web Storage API and IndexedDB we have much better alternatives. Are cookies the only way to build authentication and sessions on the Web? No! There is a technology that recently got popular, called **JSON Web Tokens**(**JWT**), which is a **Token-based Authentication**. Web Storage API vs IndexedDB ## User server identification The HTTP Protocol is a stateless protocol. So there should be an mechanism to identify the user using the web server. There are various techniques used: 1. Authentication: HTTP Auth 2. Cookies ## Content negotiation is the mechanism that is used for serving different representations of a resource at the same URI, so that the user agent can specify which is best suited for the user (for example, which language of a document, which image format, or which content encoding). #### Principles of content negotiation  The determination of the best suited representation is made through one of two mechanisms: - Specific [HTTP headers] by the client (_server-driven negotiation_ or _proactive negotiation_) - The [`300`] (Multiple Choices) or [`406`] (Not Acceptable) HTTP response codes by the server (_agent-driven negotiation_ or _reactive negotiation_), that are used as fallback mechanisms. #### Server-driven content negotiation 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 preferred choice of the user.  - `Content-Type:` This header tells about the media type of the body of the request. - `Accept header:` Determine what type of representation required on the client side. Accept: Used to tell the server what media types are okay to send Accept-Language: Used to tell the server what languages are okay to send Accept-Charset: Used to tell the server what charsets are okay to send Accept-Encoding: Used to tell the server what encodings are okay to send #### Agent-driven negotiation Not very used #### Transparent negotiation ## Language detection The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred as a response to the request. ## HTTPS The HTTPS is a secure version of HTTP. It indicates the port 443 should be used instead of port 80. It is widely used in security concern areas such as online payment transaction. The protocol identifier HTTPS tells the server that client is connecting to a secure connection. The HTTPS follows a procedure to follow secure connection in the network. The secure connection is done automatically. The steps are: 1. The client authenticates the server using the server’s digital certificate. 2. The client and server negotiate with the cipher suite ( a set of security protocols) they will use for the connection. 3. The client and server generate session keys for encrypting and decrypting data. 4. The Client and server establish a secure encrypted connection. The HTTPS ends its session whenever the client or server cannot negotiate with the cipher suite. The cipher suite can be based on any of the following: 1. Digest Based – • Message Digest 5 (MD5) • Secure Hash Algorithm 1 (SHA-1) 2. Public Key-Based – • Rivest-Shamir-Adelman (RSA ) encryption/decryption. • Digital Signature Algorithm (DSA) • Diffie-Hellman Key-exchange/Key-generation. 3. X.509 digital certificates. 4. ## Caching Proxy server: Intermediate server The main difference between a GET and POST request is that in the former, the entire request is encoded as part of the URL itself, whereas in the latter, parameters are sent after the header. In addition, in GET request, different browsers will impose different limits on how big the URL can be. Most modern browsers will allow at least 200KB, however Internet Explorer seems to limit the URL size to 2KB. That being said, if you have any suspicion that you will be passing in a large number of parameters which could exceed the limit imposed on GET requests by the receiving web server, you should switch to POST instead.