YT YouTube2Text

YouTube2Text → Transcripts → 5. Understanding HTTP for backend engineers, where it all starts

5. Understanding HTTP for backend engineers, where it all starts — Transcript

by Sriniously · 12,458 words · 1,812 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00backend is huge and if we start
0:02discussing every single component that
0:04could be part of it we will be stuck
0:05here for years so what we will do is we
0:08will only discuss those topics which are
0:10used in majority of the code bases let's
0:13say 90% of them with that in mind let's
0:15talk about HTTP protocol the medium
0:18through which our browsers talk to our
0:20servers either to send data or to
0:22receive data from it and as I said there
0:24are a lot of other ways and protocols
0:27which clients and servers use to
0:29communicate with each other and HTTP
0:32being one of the most used ones we will
0:34focus on that now there are two ideas
0:36which are at the heart of HTTP protocol
0:39the first one being tessness what does
0:42it mean tessness basically means it has
0:46no memory of past interactions so each
0:49HTTP request carries all the necessary
0:52information for the server to process it
0:54such as headers or URLs and methods
0:57which we will see in a bit and after the
0:58server responds it forgets about the
1:00request if a client makes another
1:02request the server treats it as a new
1:05and unrelated event and it also means
1:08self-contained requests since the server
1:10does not remember pass requests each
1:12request must include all the necessary
1:15data such as authentication tokens or
1:17session information to handle that
1:20specific interaction for example in the
1:22case of accessing a user profile the
1:24client has to provide credentials like
1:27cookies or tokens on every request for
1:29for the server to know which user is
1:31requesting the data so what are the
1:34benefits of that what are the benefits
1:36of this stateless model the obvious one
1:38being Simplicity stateless design
1:41simplifies server architecture because
1:43the server does not need to store
1:45session information which would
1:46otherwise require additional resources
1:48and complexity and it also means
1:51scalability stateless protocol makes it
1:54easy to distribute request across
1:56multiple servers because no single
1:59server need needs to keep track of a
2:01session and if the server crashes it
2:03does not affect the state of a client
2:05interaction as there is no session or
2:08memory of a request that needs to be
2:09restored and having said that because
2:13HTTP is stateless developers often
2:15Implement State management techniques
2:17like cookies or sessions or tokens to
2:20maintain continuity in interactions
2:23where needed like user logins or
2:26shopping cards and we'll explore those
2:28soon in this series and the second idea
2:31is client server model in a typical HTTP
2:34request flow there is a client and there
2:36is a server always the client typically
2:39is a web browser or an application which
2:42initiates the communication by sending a
2:44request to the server the client is
2:46responsible for for providing all
2:49information needed by the server such as
2:51the URL of the resource or the headers
2:54and
2:55everything and then there is a server
2:59which hosts resources like websites or
3:01apis or other content and waits for
3:04incoming requests from the clients when
3:07the server receives a request it
3:08processes it and sends back the
3:11appropriate response such as a web page
3:13or data or error message or a Json file
3:17or a text file or any other kind of
3:19content now the thing to remember here
3:21is HTTP protocol states that
3:24communication is always initiated by the
3:27client to get some kind of resp response
3:30by the server and throughout our
3:32discussion we can go ahead and safely
3:35assume that HTTP and https are
3:38interchangeable because https to
3:41oversimplify it just a more secure
3:44version of HTTP but the underlying
3:46principles are the same with more
3:48security features like encryption and
3:51security certificates or TLS stuff like
3:54that which boarders too much into the
3:56network engineering domain also to send
3:59some kind of request or receive some
4:01kind of response first the client and
4:04the server need to establish some kind
4:07of connection mechanism right otherwise
4:10how are they going to communicate what
4:11is the medium of the communication and
4:13for that sgtp uses TCP
4:17TCP which is a protocol which is a
4:20transmission protocol essentially HTTP
4:22does not require the underlying
4:24transport protocol to be connection
4:26based it only requires it to be reliable
4:28and not lose message messages at minimum
4:31presenting an error in such cases and
4:33among the two most common transport
4:34protocols on the internet which are TCP
4:37and UDP TCP is considered to be more
4:40reliable HTTP therefore relies on the
4:42TCP standard which is connection based
4:45now this is called an OSI model which is
4:48often referred when we are talking about
4:50sending and receiving data over a
4:52network right and we as backend
4:55Engineers often deal with this layer the
4:58top layer the layer 7even application
5:01layer and so a lot of discussions for
5:05example the recent one which we talked
5:07about the TCP handshake and establishing
5:10connections and TLS encryptions they
5:13often border into these
5:15layers so they are mostly network
5:19engineering concepts of course it's it's
5:22good to know about those but if we start
5:24exploring those it'll be a rabbit hole
5:26and we'll have to cover a lot of
5:28Concepts right so what we'll do is we'll
5:31focus on the application layer with a
5:33brief about you know what happens in the
5:35netor layer like as I said HTTP uses TCP
5:39and TCP uses something like a 3-way
5:42handshake which if you're curious about
5:44you can just look up and study more on
5:47that now throughout the years we had
5:49different versions of HTTP which kept
5:52redefining how clients and servers send
5:54and receive data right in sttp 1.0 each
5:58request opened a new connection this led
6:01to inefficiencies since a connection had
6:03to be established and closed for every
6:05request and response which slowed
6:07performance in HTTP 1.1 they introduced
6:11something called as persistent
6:12connections allowing multiple request
6:15and responses over the same connection
6:17over the same TCP connection that was
6:19established before sending the request
6:21which significantly improved performance
6:23it also added stuff like chunk transfer
6:26encoding and better caching mechanisms
6:29in SCP 2.0 they introduced multiplexing
6:32allowing multiple requests or responses
6:34over a single collection it uses
6:36something called binary framing instead
6:38of text and supports header compression
6:40with Edge pack or and server push
6:43allowing servers to send resources
6:45before the client requests them now in
6:47sttp 3.0 built on quick protocol a
6:51transport layer protocol over UDP right
6:54instead of TCP it is designed over UDP
6:56which improved performance with faster
6:59connection establishment reduce latency
7:01and better handling of packet loss it
7:04also continues to support multiplexing
7:06without head ofline blocking which is
7:08still an issue in HTTP 2.0 now again
7:11that's a rabbit hole if you get too much
7:13into the network stuff all we need to
7:16remember is that from all these
7:18discussions that client and servers
7:21established some kind of network
7:23connection and messages are sent and
7:26received that's all you need to remember
7:29for now now that we mentioned message
7:31let's look at what HTTP messages look
7:34like request messages or response
7:36messages a request message is basically
7:39the one that is sent by the client and a
7:41response message is the one that is
7:43received by the client from the server
7:45so this is what a request message looks
7:47like in HTTP and this is what a response
7:51message looks like I intentionally took
7:53more complex messages which had more
7:56parameters and so that we can cover
7:58different different components one by
8:00one so on a high level I'll just explain
8:02what is what in this right this part
8:05this is called a request method this is
8:07the resource URL the one we are
8:09requesting from the server this is the
8:11HTTP version which says we are using
8:14HTTP version 1.1 which is the currently
8:16the most used one this is the host right
8:21which is our
8:22domain the front ends domain and these
8:26are this all of these things these are
8:29called headers right we will talk about
8:32headers soon there will be a blank line
8:34here after all the headers to signify
8:36that the headers are over and body
8:39starts this is called a request body
8:42some information the client wants to
8:45send to a server right and in the
8:48response message again we have the HTTP
8:51version have the status code and the
8:55value of the status code which basically
8:56means the status code 200 means okay
8:59right and we have again some response
9:02headers after that there is a blank line
9:05and we have the response
9:07body so let's talk about HTTP headers
9:11first this is very important since it's
9:14the major part of the request here and
9:16the responses on a high level what we
9:18can see is headers are basically key
9:20value pairs key value pairs of different
9:22different parameters that is sent over
9:25request or received over a response that
9:28is the first definition and the next
9:30question is why do we need headers why
9:33not send the all these values in the you
9:36know the URL or we have this request
9:39body here why send why create a
9:41different section just for sending more
9:44information or more met data about the
9:46request or the response why create
9:49another level of abstraction and in
9:51order to understand that let's take a
9:53real life example we send Parcels right
9:56ciers and we receive them the address of
9:59about the phone number of the recipient
10:02and different details right the the
10:04state the the PIN code and all of these
10:07things do we keep it inside the package
10:11or do we write it on top and we write it
10:14on top why because the one who is taking
10:19the parcel from the sender and to the
10:22receiver they need to know different
10:24informations in order to
10:26successfully transmit the package
10:29through different modes of transmission
10:32and if we kept all those information
10:35inside the parcel they have to open that
10:38right and which does not make any sense
10:42but just for the sake of the example
10:43they have to open that and they have to
10:45see who is the recipient again and again
10:47so let's say another person wants to see
10:50the address so again they have to open
10:52that so keeping the metadata the address
10:56and the information of the recipient on
10:58top of the parel uh gives a quick way of
11:02checking different metadata about the
11:04package sdtp headers can be thought of
11:06something like that but they have more
11:08uses before we go into the use cases
11:11let's see what are some different kinds
11:13of headers that we see so as you can see
11:16there are a lot of different types of
11:17headers so can we categorize them can we
11:20categorize them and different types of
11:21headers so let's see the first category
11:24can be request headers which are sent by
11:26the client to the server to provide some
11:28kind of information about the request
11:30itself it could be user agent which
11:32identifies what kind of client is that
11:35it is a browser or it is a it is Postman
11:39or it is some kind of server or it's a
11:42mobile app we have authorization which
11:44sends different credentials like bar
11:46token to the server to identify the user
11:49you have accept headers which provides
11:52informations like what kind of content
11:54we are expecting whether it is a Json
11:56whether it is a text whether it is an
11:58HTML file so request headers help server
12:02understand the client's environment its
12:04preferences and its capabilities then we
12:07have General headers which are used in
12:09both request and responses which have
12:12some metadata about the message itself
12:15for example the date of the message and
12:18different caching mechanisms like no
12:20cache or max age and the connection
12:24information whether to keep it alive or
12:26to close it so General header have some
12:29kind of information about the request
12:32message or the response message then we
12:34have representation headers which
12:35primarily deal with the representation
12:37of the resource being transmitted
12:39whether it could be a request body or a
12:42response message the content type
12:44describes the media type of the request
12:47or the response it could be Json or it
12:49could be HTML the content length describ
12:52the size of the resource in bites the
12:54content encoding specifies any encoding
12:57like G or D flare then we have eag a
13:00unique identifier which is mostly used
13:03for caching so representation headers
13:06provides information about the body of
13:08the message or the response ensuring the
13:10clients and servers know how to
13:12interpret and process request or the
13:15response then we have security headers
13:17which are used to enhance the security
13:18of the request and response by
13:20controlling behaviors like content
13:22loading cookies and encryption hsts
13:25ensures that the client only
13:26communicates with the server over https
13:29preventing protocol downgrade attack
13:31content security policy restricts the
13:33sources from which content like
13:35JavaScript or css and images can be
13:37loaded helping prevent cross site
13:39scripting attacks x-frame options
13:41prevents the web page from being
13:43embedded in iframe mitigating
13:44clickjacking attack X content type
13:46options ensures that the browser does
13:49not try to guess the mime type of the
13:51content preventing MIM type sniffing
13:53attack that cookie with HTTP only or
13:55secure Flags secures cookies by making
13:58them inaccessible with JavaScript and
14:00ensuring they are sent over https so
14:02security headers helps protect the
14:05client and server from a variety of
14:07attacks by controlling how the browser
14:09behaves with resources and enforcing
14:12security policies now there are two
14:14ideas that we see here while talking
14:16about HTTP headers one is
14:19extensibility HTTP is highly extensible
14:23because headers can be easily added or
14:25customized without altering the
14:27underlying protocol
14:29right we only have to add some kind of
14:32metadata and the whole flow of the
14:34interaction changes depending on that
14:37now headers can be defined and used for
14:39various purposes making HTTP adaptable
14:42to new technologies and use cases for
14:44instance security enhancements as we
14:46just talked about headers like strict
14:47Transport Security and Force Security
14:49connections custom headers developers
14:51can create custom headers like X custom
14:54header for specific application for
14:57their own use cases content negotiation
14:59the accept and the accept language and
15:02accept encoding headers allows servers
15:04to serve different versions of the
15:05content depending on the client's
15:07preference so the next part is the idea
15:09of remote control sgtp headers act as
15:12kind of a remote control on the server
15:14side they allow the client to send
15:17instructions or preferences to the
15:19server influencing how the server
15:22responds or processes requests for
15:24example content Ty negotiations clients
15:28can request specific formats using
15:30accept header and the server can respond
15:32with the appropriate format if the
15:33client says I want the HTML format the
15:36server sends the HTML and if the client
15:38says they want Json then the server
15:40sends the Json format then caching and
15:43expiration control the server can use
15:46headers like cach control or expires to
15:48control how long a resource should be
15:51cached by the client then authentication
15:54the client can authenticate itself to
15:56the server through authorization header
15:58influencing Access Control decisions
16:00right so these provide more capabilities
16:04on top of our messages which are very
16:07useful in a lot of instances now we have
16:10some kind of idea about the headers in
16:12HTTP and we will explore them in more
16:16depth when we are going through the
16:18demos let's move on to the next
16:19component of a HTTP message right the
16:22HTTP method HTTP methods exist to
16:25represent different kinds of actions
16:28that a CL client like a browser or an
16:30API consumer can request on a server
16:33instead of every request doing the same
16:35thing methods Define the
16:38intent the keyword note here is the
16:42intent the intent of the
16:45interaction this gives clear semantic
16:49meaning to each type of action and it is
16:52pretty intuitive in that sense we use
16:55get request to fetch some kind of data
16:57from the server and it should not modify
17:00anything on the server use post to
17:02create some data in the server and post
17:04request have a body which makes sense
17:07because how else would you send the user
17:08data to the server then we have
17:12patch which is used to update some data
17:15for example you have a users profile
17:17page where they can update their name
17:19and this also has a request body to send
17:22the data to the server we also have put
17:26which is also used to update data but
17:29what sets it apart from patch is
17:31whatever data that comes in request body
17:33should completely replace the previous
17:36instance basically patch can be thought
17:38of as an append action or a selective
17:40replacement while put is a complete
17:43replacement even though a lot of times
17:45developers use put when they should be
17:47using patch and go against the semantics
17:51so the thumb rule is always use patch
17:53unless you have a specific use case for
17:56put then we have delete method and as
17:58the name suggests we use this to delete
18:01some kind of resource from the server
18:03and one prevalent idea that we have in
18:07the context of HTTP methods is the idea
18:10of EMP poent and nonm poent and what the
18:14idea of important means is these HTTP
18:18methods can be called multiple times and
18:21we can expect the same kind of result
18:23for example we generally consider the
18:26methods get or put
18:30or
18:31delete in the category of it poent
18:34methods because just think about it
18:37you're trying to fetch some data from
18:39the server right it does not matter how
18:41many times you fetch it the data should
18:43be same you should not be able to modify
18:46any kind of data in the server so get is
18:49obviously impotent and then we have put
18:52because put completely replaces the
18:54resource in the server so it does not
18:56matter how many times you replace an old
18:59with the new data it will the result
19:02will be the same right so that is also
19:04considered as important then we have
19:06delete you can only delete a resource
19:09from the server once because after that
19:11it is already deleted you cannot perform
19:13the action multiple times and expect
19:15different results right the result will
19:17always be the same the resource can only
19:19be deleted once and then we have the
19:22idea of nonmutant usually we consider
19:26post request to be non important because
19:30once you submit a request to create some
19:33data let's
19:34say uh a user can create a note using
19:37your app right they submitted a post
19:40request to create a new note and the
19:43first time they submit the request the
19:45request goes through the response is
19:46successful and a new note is created and
19:50when they do it a second time we create
19:52a new note right there are two different
19:55results for the same kind of request so
19:58that's why we consider post to be a
20:00non-idempotent method because it
20:03produces different results for the same
20:05kind of request after all the sgtp
20:08methods we have one other method which
20:10is called the options method and this
20:12has a very interesting use case which is
20:15used in the course flow right we
20:18discussed this before in brief the
20:22course flow which is part of the same
20:25origin policy which browsers have now
20:28options method this method you probably
20:31won't use directly as a developer but
20:34you will see them once in a while in
20:35your browser network tab in pre-flight
20:38requests so the options method is used
20:40to fetch the capabilities of the server
20:44for a cross origin request also known as
20:47course which is used because browsers
20:50have same origin policy which means by
20:52default browsers follow the same origin
20:55policy which restricts web pages from
20:58making requests to a domain different
21:01from theirs different from the one
21:03serving the web page and course is a
21:06security mechanism enforced by browsers
21:09to control how web applications interact
21:12with resources hosted on different
21:14domains which are cross
21:16origin and without course browsers block
21:21the request made from a web application
21:23running on one origin like example.com
21:26to a different origin like API another
21:29example.com for security reasons course
21:31allows servers to specify who can access
21:35their resources and how in a cross
21:37origin request there are primarily two
21:40types of flows one is a simple request
21:42flow and another one is a pre-f flighter
21:44request flow first let's look at the
21:46simple request imagine our client our
21:48frontend is at the Domain example.com
21:51and our server is at the Domain api.
21:54example.com and we make a get request
21:57which looks something like like this
21:59this is how the flow looks like the
22:00client sends a request the browser
22:03automatically adds the origin header to
22:05indicate the origin of the request the
22:07request uses a simple method which are
22:09usually get post or head and then it
22:13reaches the server the server checks for
22:16the origin header against it C policy if
22:19the origin is
22:21allowed the server includes the access
22:24control allow origin header in the
22:26response and it sends the response
22:28response the server responds with the
22:30resource and includes the necessary
22:32course headers for example Access
22:34Control allow origin header and this is
22:36what the response looks like it has the
22:38appropriate course header which the
22:40browser looks for while it passes the
22:42response it sees that our domain which
22:45is the example.com is different from the
22:47host domain which is the api. another
22:50domain.com and since these two are
22:53different the browser checks whether the
22:55server's response has this header or not
22:58whether it responds with this particular
23:00header Access Control allow origin if
23:03the server responds with the domain of
23:06the client example.com or it could also
23:09respond with star which means allow all
23:12Origins right if either of those two
23:15conditions are true then the browser
23:17lets the response go through to the
23:20client to whatever the JavaScript client
23:22requesting the resource and imagine
23:25imagine if the response looked like this
23:27the client sent the request the server
23:29got the request and assuming the server
23:32did not add the corresponding course
23:35headers or assuming the server did not
23:37allow this particular domain as the
23:40client then what the server does it
23:43excludes this particular header from the
23:46response so the response looks something
23:48like this and when the browser finally
23:50parses it it sees that it sees the
23:52absence of this header and what it does
23:55it blocks the this particular response
23:58from being passed you will get an error
24:00in our console and we will see the error
24:02in the network tab as a course error and
24:06this is how a simple request flow looks
24:08like next we have a pre-lighted request
24:11flow for a cross origin request and how
24:15does a browser distinguish between a
24:17simple request flow and a pre-lighted
24:20request flow so these are the three
24:22conditions the browser checks before it
24:25decides it has to do a PF flight request
24:28which basically means it has to do a
24:30request before the original request to
24:32inquire some stuff to inquire some
24:35capabilities and to let the server know
24:37about some capabilities right and when
24:39does a request qualify as a pre-lighted
24:42request one is the method is not get
24:46post or head example it is a put request
24:48or a delete request and it is a either
24:51or situation right it either of these
24:54conditions have to be true then it will
24:55be considered as a pre-lighted request
24:58so the first condition is obviously it
25:00has to be cross Surin request which
25:01means our domain and the server domain
25:04has to be different and the second
25:06condition is one of these three and
25:08after that it will be a c request and
25:11inside that it will be a pre-lighted
25:13request so the first condition is it has
25:15to be either a put request or a delete
25:17request or the request includes some
25:20nons simple headers nons simple headers
25:23are basically anything apart from our
25:26general headers or request headers so
25:28one example could be an authorization
25:30header or some custom headers right and
25:33the third one is or the request has a
25:37content type other than application form
25:41URL encoded or multiart or text plan
25:45these are called General content types
25:48or simple content types so if assuming
25:51our application our client request the
25:55data to be in Json
25:58in that case it will be considered as a
26:00pre-lighted request and if you are a
26:02frontend engineer or a backend engineer
26:04you know that mostly we deal with Json
26:06data right so most of our requests are
26:08considered as a pre-lighted requests
26:11these are the three conditions either of
26:13them have to be satisfied before we move
26:16on before the browser moves on to make a
26:18pre-flight request what does a
26:20pre-flight request looks like this is
26:23when we finally see the use of options
26:25method right a pre-flight request is
26:28made with an options method and pre-
26:30flight request looks something like this
26:33it has the method as options it has the
26:36appropriate resource URL and the HTTP
26:39version it has the host header which is
26:42the header of our API the origin the
26:45domain of the front end and this header
26:48Access Control request method so it is
26:51basically asking the server whether this
26:54method is supported for this URL or not
26:57so it is saying I am making a cross
26:59origin request and do you support this
27:02put method for this route right and it
27:06also asks whether you support this
27:08particular header or not if it is needed
27:11and the browser sends the options
27:12request to the server the request does
27:15not include actual data right this does
27:17not include any request body or anything
27:20it is just a general inquiry to the
27:22server about its capabilities and after
27:26that if the server is is properly
27:28handling course flow if the server
27:31supports cross origin requests it
27:34responds something like this and if the
27:36server does not handle cost request then
27:39it won't respond with this and the
27:42request will be automatically blocked by
27:44the browser and if it does handle it it
27:47requests with something like this what
27:49it says is this is the status code of
27:51the response which means there is no
27:52content this is just a general
27:54information we use 204 when there is no
27:57content then these are the four
27:59important headers it responds with the
28:02first one is the access control allow
28:04origin it says yes I allow the client's
28:08domain which is example.com as a cross
28:10origin as a valid cross origin request
28:13right it can either respond with this or
28:17it can respond with a star which
28:19basically means I allow all types of
28:21clients to make request to me this is
28:23the one valid condition it is browser
28:26checks it the next is we asked whether
28:28you allow put request for this resource
28:31or not so the server says yes I allow
28:33these two different kinds of methods it
28:35is the put method and delete method for
28:38this resource for this particular route
28:41right and the browser checks it off the
28:43next one is we asked whether you allow
28:45authorization header and the server says
28:47yes I allow authorization header and
28:49then it is also checked off and the last
28:52one is Access Control maxage what this
28:54means is the server says don't make make
28:58any more pre-flight request to me right
29:01it says these these configs whatever I
29:03responded with these will be the same
29:06for at least the next 24 hours so you
29:08don't have to keep making more
29:10pre-flight requests for every route
29:12before you send the original request so
29:15this saves some bandwidth for both our
29:18servers and clients so this is the
29:19pre-flight request that the browser
29:21makes and the server responds with the
29:24appropriate headers the browser checks
29:25off all these conditions and then the
29:28browser sends the final request which is
29:30the original request that the client
29:32wanted to make and the server responds
29:34according to the original request with
29:36whatever the operations are required
29:39this is how the typical course flow
29:41looks like and now that we understood
29:43the theory let let's look at a real demo
29:46okay now before we start let me make
29:49this clear that we won't be looking at
29:51any code because as I said we are
29:54learning from first principles and the
29:57rule for that is
29:58we try to understand the concepts first
30:01how the underlying mechanism Works
30:03before we dive into code before we
30:06understand the how but first we have to
30:09understand what for all these demos that
30:12we are going to do in this video and and
30:14all the other videos in this series we
30:16won't be looking at any code it does not
30:19matter what language the server is
30:22written in what framework it is written
30:24in I'll explain what I am changing in
30:27the server what I have done in the
30:28server for all it matters it can be
30:30implemented in any language that's that
30:33and this is a tool it's called burp suit
30:38and it is used by ethical hackers if you
30:41may it has a lot of features as you can
30:44see but primarily what we are going to
30:46use it for is HTTP intercepting or
30:50visualizing HTTP traffic and it offers a
30:54quite a nice set of features for that
30:56with that what I have here is I have a
31:00simple front end app again it could be
31:02in any language and what I want to show
31:05is one for our course flow one is the
31:08simple request and one is the pre-light
31:11request and how they look like in actual
31:14browser environment so let's fire the
31:18first simple
31:20request okay so we got this response
31:23that we are rendering here and let's
31:25inspect the request and response for now
31:28right if you go here this is what the
31:32request and response looks like right we
31:35already took a look at all these
31:36components right the method and the URL
31:39and all these headers and the response
31:42the status code and the response headers
31:44the response body so let's focus on the
31:47course here what is the first parameter
31:49for a request to be considered as a
31:51cross origin request by the browser the
31:54first thing is the origin so this is our
31:57local host file
31:58173 and the host right this is our apis
32:04which is running on the port 3,000 of
32:06Local Host since the host and the origin
32:10are running on different ports in Local
32:14Host by the browser this is considered
32:17as a cross origin request and according
32:20to the same origin policy we can only
32:22make request from Local Host 5173 to
32:24Local Host 5173 right since we not it is
32:29considered as a cross origin request the
32:31headers to focus here is origin header
32:34let me minimize
32:37this so the the headers to focus here is
32:40the origin header which is our origin
32:43the front end origin and the host the
32:46domain or the port that you want to
32:49connect to which is the apis right for
32:52the request these are the two important
32:54headers now let's go to the response now
32:57the thing to f Focus here is this header
32:59right as I had explained the browser
33:02makes a cross origin request and when it
33:05gets the response it checks whether it
33:07has the access control allow origin
33:10header or not or whether it has the
33:13appropriate port or the domain so it has
33:16the front ends Port right the
33:195173 or it could also have star so in
33:22that case the browser lets the response
33:25through and and it does not block it
33:27since according to the core sets this
33:31response is now expected right this
33:33response is now allowed and now that's
33:36why we are able to get the response and
33:38now we are able to render it in our
33:40front end right let's see what happens
33:43if you remove this header like this
33:46Access Control allow origin header from
33:48the server for a simple request let me
33:51just go and make this change okay I have
33:53went ahead and made the change in the
33:55server now it won't return the appri
33:57corer Access Control allow origin Let me
34:00refresh
34:01this and let's clear this history so
34:04that we can focus on the particular
34:06request now let's fire the same request
34:08again and before we do let's disable
34:10caching so that we can see what a new
34:14request looks like right so let me fire
34:16this the browser blocked this response
34:19right it says course error and why let's
34:22inspect this request and response so
34:26here if you see we have a cross origin
34:29request because our origin is 5173 and
34:32the host is 3001 and the server does not
34:37return an access control allow origin
34:39header right because we removed it and
34:41for that reason the browser has blocked
34:44the request because of course error so
34:47this is how the simple request flow
34:49looks like and now let's move on to our
34:51pre-lighted request right okay I have
34:53gone ahead and enabled the course again
34:55so that we can test the pre-flight
34:57request flow okay let me fire
35:02this all right as you can see here the
35:06first request that went through was the
35:08options request right the pre-flight
35:11request and then the original request
35:13went through let's look at them one by
35:15one how the whole flow looked like okay
35:18for the pre-flight request as we have
35:20already discussed the method was options
35:23and it is a cross origin request because
35:26the referrer and the origin are
35:29different ports right and for
35:32that what the server responded with it
35:35responded with status code 204 no
35:38content because it is just a general
35:40inquiry right pre-flight requests are
35:42General inquiries they don't have
35:44request bodies or response bodies and
35:47the server responded with Access Control
35:49allow origin with the front ends domain
35:53or Port right this makes the browser
35:56allow the response wants to go through
35:58that is the first condition and before
36:01that let's see why a pre-flight request
36:03was fired right why why this was not
36:05considered a simple request he
36:07investigate the original request what
36:09was the conditions it is not a simple
36:11method which is get post or head right
36:14that is that was one of the conditions
36:16so it is already satisfied but let's
36:18look at others it also has a
36:20authorization header that also counts it
36:22out of a simple request right that is
36:25the second one and the third one is the
36:29content type is application Json and it
36:31is sending a Json request body right all
36:34the three conditions are satisfied but
36:36even if one of them was satisfied it
36:39would have still fired a pre-flight
36:40request for this let's go back to our
36:43options pre-light request analysis the
36:46first one was it allowed the client's
36:49domain so that the browser lets the
36:51response to go through the second
36:54one Access Control allowed methods so
36:57the server says all these methods get
37:00post put delete these methods are
37:02allowed for the server it lets the
37:04client know the capabilities of the
37:06server the third thing is Access Control
37:09allowed headers it says these are the
37:11two headers which are not simple headers
37:14that are supported by the server which
37:16is the content type and authorization
37:19since the client asked for them if you
37:22look at this Access Control request
37:25method put the client is asking with the
37:28pre-flight request whether the put
37:29method is allowed or not and whether the
37:32these two headers authorization and
37:34content type these two headers are
37:37allowed or not so for that the server is
37:39responding with these headers it says
37:42get post put delete is allowed it also
37:44says content type and authorization is
37:46also allowed we have also set the max
37:48age for the access control to zero for
37:51testing purposes right because if you
37:53cach this for let's say 5 minutes then
37:56pre-flight request be fired that's why
37:59this is used for and the content length
38:01is zero because there is no content
38:03since the pre-flight request was
38:05successful it returned 204 it is a
38:08success status code the browser let the
38:10response go through and it fired the
38:13original request it is the put method
38:15and this is the original request it has
38:18put method the resource URL the origin
38:22and the authorization header the host
38:25the request body and it responded with a
38:29response body right and that's how the
38:32pre-flight request flow looks like so
38:34the simple request and the pre-flight
38:36request flow combined they make the
38:39whole course flow and this is all you
38:42have to understand how course Works
38:44behind the scenes and why these headers
38:46are important and how browsers react to
38:50them okay moving on the next component
38:53that I want to cover is response codes
38:55this part this 200 okay what are these
39:00and why are they needed HTTP response
39:03codes exist to communicate the result of
39:05a request in a standardized way know you
39:08can just look at the response code and
39:10see whether the request was successful
39:13or not or what is the state of the
39:15server without looking into the body or
39:18without judging from the response
39:19message that okay so if the request was
39:22successful then I would have expected
39:24this structure if the request was
39:25unsuccessful then I would have expected
39:27this structure if the server crashed
39:29then I would have expected a null object
39:32right we don't have to make those
39:34decisions we can judge by these status
39:37Cotes so they quickly inform the client
39:40whether the request was successful
39:42resulted in an error or requires further
39:45action they also help clients handle
39:47errors by providing specific codes to
39:49identify the problem for example
39:51unauthorized access will return 401 so
39:54now the clients can check whether it is
39:5640 one and it can log the user out
39:59saying you have to log in again right
40:01those kinds of actions they can be
40:03judged with response codes or imagine
40:06let's say it was a bad request error
40:08because of some invalid value through a
40:10form submission then the client can ask
40:13their user to make changes to their form
40:16submission and resubmit right depending
40:18on those status code which was like 400
40:21also standardization HTTP response codes
40:24are standardized across all web services
40:26enabling consistency in how servers
40:29communicate with different clients
40:31regardless of the platform or language
40:34used it does not matter whether you are
40:36making a server in python or golang or
40:38rust or JavaScript or Ruby you have to
40:42follow this standard if the request was
40:44successful you have to return to 200 if
40:46the if you created something you have to
40:48return to1 these are the standards and
40:50you have to follow them now before HTTP
40:53status course clients would have to
40:54guess the outcome of a request based on
40:56the content of the response as I said
40:58leading to inconsistencies and
41:01inefficiencies HTTP status code solve
41:03this by providing a universal language
41:05that all clients and servers understand
41:08streamlining interactions and error
41:10handling on a high level response codes
41:12are three-digit numbers they could
41:14either start with 1 2 3 4 or five and
41:19depending on the starting digit we
41:21categorize them as different level of
41:24errors or different types of errors on a
41:26high level
41:27the digits starting with one are
41:30informational responses two are success
41:33responses three are redirection five are
41:35server errors four are client errors
41:37response codes starting with one this
41:40code is sent by the server to indicate
41:42that it has received the headers and the
41:44client can proceed to send the request
41:46body and when is it used commonly used
41:49in large uploads the client sends the
41:51headers first and if the server is okay
41:54with the request it sends a 100 Contin
41:56so the client can send and the rest of
41:58the body also there is which is which is
42:01used for switching protocols right we
42:03have a use case for that this indicates
42:05that the server is switching protocols
42:07as requested by the client such as
42:09upgrading from HTTP to websocket this is
42:12not the mostly used response codes that
42:15you will encounter on your day-to-day
42:16life so let's focus on these four which
42:19you'll see a lot of times especially 2 4
42:22and 5 200 series as you know are used
42:26for success responses and under that we
42:29have three mostly used ones one is
42:32200 and
42:342011 and 204 200 is the most common code
42:38it indicates that the request was
42:40successful and the server is returning
42:42the requested resource or performing the
42:44requested action for example successful
42:47get request where a resource is
42:48retrieved
42:502011 it indicates that the request has
42:52been fulfilled and resulted in a
42:55creation of a new resource for example
42:57post request or new form submissions
42:59that's where servers use this response
43:02to indicate that the a new resource has
43:04been
43:06created then we have 204 that we just
43:09saw in a course flow when we send
43:11options request a pre-flight request and
43:14the server responds with 204 saying that
43:17there is no content but these are the
43:18information in the form of headers this
43:20also indicates that the request was
43:22successful but there is no content we
43:25also sometimes use it for delete delete
43:27request right the client makes a delete
43:29request you delete the particular
43:31resource but the server says okay I've
43:33deleted it but there is no content to
43:35return right you can just assume that
43:37the request was successful then we have
43:39300 and in 300 the mostly used ones are
43:4331
43:45302 and
43:47304 301 means moved
43:51permanently which means the requested
43:54resource has been permanently moved to a
43:56new UR URL and the future request should
43:59use this new URL for example let's say
44:02initially you had a route called
44:05user and eventually you decided to move
44:09that route to slash person so in order
44:12to maintain backwards compatibility so
44:14that old users or old applications that
44:18are still using this route don't break
44:21what you do is you add a 301 response
44:24for this routes and read direct then to
44:28the/ person route so it is a permanent
44:31redirect the next one is 302 which means
44:34temporary redirect the requested
44:36resource is temporarily located at a
44:38different URL but the client should
44:40continue to use the original URL for
44:42future request so when do we use this
44:44let's imagine you are running a campaign
44:46or something and for those couple of
44:49hours you want to redir redirect a
44:52particular route to a new route for
44:55catching new traffic or showing a
44:57different UI or something like that but
44:59you don't want to stick to that right
45:02you want to revert the changes so you
45:04want to say to the client that for for
45:06now I'm making a redirect but later on
45:09you should use the original route only
45:11and then we have
45:1334 which says not modified it indicates
45:16that the resource has not been modified
45:19since the last time the client requested
45:21it and this we will see soon in a bit in
45:24a uh when we explore our caching demo
45:27and when do we use it this is mostly
45:29used in conjunction with conditional get
45:31request to allow efficient caching right
45:33when we are using e tax to let the
45:35client know that the uh response is not
45:38modified it should use the cached one
45:40only instead of downloading the new
45:42response so it just says that it is not
45:44modified so you should keep using your
45:46old response the cach response then we
45:50have the 400 series errors and as a
45:52backend engineer I think you will mostly
45:55deal with these errors because these are
45:58the client errors or errors that are
46:00triggered because of something some
46:03behavior from client so let's see what
46:06are the common ones the first one is
46:10400 and what this means is it says bad
46:14request and when does it Trigger or when
46:17should we fire it for example when the
46:19client sends invalid data or illogical
46:22data or something related to data right
46:25for example you are expecting a number
46:27and the client sends an array or a
46:30string right you are expecting an email
46:32but the client sends a phone number
46:34something like that it's a bad request
46:37that's what it says and you're letting
46:39the client know that there is something
46:40wrong with your request format so fix it
46:43and make a new request the next one is
46:46401 which is which means unauthorized
46:49when should you fire this when a request
46:51requires authentication but the client
46:53has either failed to provide valid
46:55credentials or is not authenticated at
46:58all so let's say you are expecting a JWT
47:01token and either if the JWT token has
47:05expired or if the client has not send
47:07the token in the first place so in those
47:09scenarios you want to say that you are
47:11unauthorized that's when you respond
47:13with this status code 401 next up we
47:16have
47:17403 and it says forbidden which means
47:21the server understood the request but it
47:24refuses to authorize and this can happen
47:27even if the client is authenticated for
47:29example when a user tries to access a
47:31resource they don't have permission to
47:33access so let's say you are user a and
47:35you are trying to delete a resource of
47:37user B so that's when the server says
47:40you don't have the necessary permissions
47:42to perform this action so you are
47:44forbidden 403 next up we have 404 and it
47:48means not found I think this is the most
47:50famous status code 404 this is fired
47:53when the client requests a resource that
47:55is unavailable
47:57either because the URL is incorrect or
47:59the resource has been deleted so in
48:02those cases the service is 404 it is not
48:04found then we have 405 which means
48:07method not allowed when does it get
48:10fired when an invalid HTTP method is use
48:13such as trying to put to a resource that
48:16only accepts get or post this often
48:18happens because of typos right we are
48:21working on front end and instead of
48:23doing a put request we do a patch
48:25request or instead of doing a post
48:27request we do a put request so in those
48:29scenarios server says 405 which means
48:31method not allowed then we have
48:34409 which means conflict this has a
48:38number of use cases one of which we can
48:41imagine is let's say in your app you are
48:43allowing users to create folders right
48:47and the condition is the folder names
48:50has to be unique they cannot create two
48:52folders with the same name when they try
48:54to create a new folder when they submit
48:56a post request you check whether the
48:58folder is already existing or not if it
49:01is you can respond with this error 409
49:04conflict so the client will understand
49:06that a folder with that name already
49:08exists and it should try with a new
49:11folder name right it means conflict and
49:14at last we have 4 to9 which means too
49:18many requests and this is mostly used
49:21when we are trying to rate limit uh the
49:23client's request rate limit basically
49:25means if client tries to make too many
49:28requests in a particular interval let's
49:31say in your server you have configured
49:33it to allow at most 60 requests for a
49:38client in 1 second and if the client
49:40tries to exceed that you can respond
49:43with this response code which ISS 429
49:46too many requests okay let's move on to
49:49the 500 series and we have the most
49:51famous one which is the 500 which means
49:55internal server error this is often used
49:58for unexpected conditions in server
50:00something some process broke or some
50:03exceptions were raised which were not
50:06handled in the server so something
50:08unexpected happened at the server so
50:11instead of you know just returning a
50:13empty response or just breaking or
50:16hanging the request we respond with 500
50:19internal server errors the client knows
50:21that something went wrong with the
50:22server then we have 501 which means not
50:25implemented for example example when the
50:27server does not support the requested
50:29HTTP method or functionality but it
50:32plans to edit soon so that's when we add
50:35a 501 which means currently it is not
50:37supported it might be in the future
50:40right so we are trying to get that
50:42intention through to the client so that
50:45it is not implemented yet then we have
50:48502 right it means bad gateway we
50:52usually see this in Proxes like NX it
50:55means when a server acts as a proxy like
50:57in a load balance system or reverse
50:59proxy and Upstream server returns an
51:01invalid response so that's when 52 is
51:05returned this is not something we uh
51:08return intentionally this is handled
51:09mostly by Proxes and load balancers then
51:12we have
51:13503s which means service unavailable
51:17when the service is down when the
51:18service is temporarily unable to handle
51:21the request such as during high traffic
51:23or when it is going maintenance so
51:26that's when you return 503 to let the
51:28client know that the service is
51:30unavailable right now and it should try
51:33again later at last we have
51:36504 which means gway time out it is
51:40similar to 502 but this specifically
51:43means that the Upstream server failed to
51:46respond within timeout period let's say
51:49you have you're using enginex and
51:51enginex could not get a response from
51:53our original server which is running
51:55behind it so that's when ninx responds
51:58with 504 Gateway timeout that it did not
52:00receive any response from our original
52:02server that's why it says timeout okay
52:05that's all that's pretty much all the
52:07response codes you need to know to work
52:09with
52:1095% of use cases now in order to
52:13solidify our understanding let's look at
52:16a quick demo where we look at some of
52:18these responses okay now again we have a
52:21friend end app for this demo where we
52:24are trying to emulate some of the
52:26response resp CES and there is a server
52:28running which will respond with
52:29different status codes right okay so
52:33what we'll do is let's just fire all of
52:35these requests then we will examine what
52:37the responses look
52:39like so let me go
52:41ahead
52:44and
52:45okay
52:47created this one one
53:01all right we have fired all these
53:03requests let's go through one by one so
53:05as you can see we have all these options
53:08request before each original request
53:10because because these are cross original
53:12requests the browser need to do
53:14pre-flight request to support those
53:16let's go through all the original
53:17requests one by one to see what are the
53:19responses looks like okay the first one
53:21was 200 okay as I said this is a
53:25successful respon
53:27which means request was successful right
53:29the status code is 200 and the next one
53:33is a post request which says 2011 which
53:37means created and This Server response
53:40even though it is a mock request and a
53:42mock response this is what usually it
53:44looks like the resource was created
53:45successfully and and the status code is
53:472011 then we have 401 bad request says
53:53bad request missing required
53:55data then we have have then we have 401
53:58which means unauthorized which which
54:01typically means either you have not
54:02included the token the JWT token or the
54:06cookie or whatever authentication
54:08mechanism you're using whether you are
54:10not you have not included that or even
54:13if you have it has expired or it is not
54:16valid anymore next we have forbidden
54:19which means you're trying to perform
54:22some action which are not authorized to
54:24do right that's why it says 40 through
54:26forbidden you do not have access next up
54:29we have 404 which means not found and
54:32the server says something like not found
54:34the requested resource could not be
54:36found next we have 409 conflict which is
54:41resource already exists so this could
54:43happen when as our previous example
54:46maybe you already have a folder and
54:47you're trying to create a folder with
54:49with the same name again so that's why
54:51the server says resource already exists
54:53right then we have internal server
54:58error which is 500 and the server just
55:01says internal server error without
55:03letting the client know too much of the
55:05information for security reasons then we
55:08have 503 service unavailable please try
55:11again later right that's pretty much
55:13covers most of the status Cotes that we
55:16have discussed and that we saw in this
55:19demo okay moving on let's explore
55:22another interesting concept HTTP caching
55:24what does http caching mean HTTP caching
55:27is a technique to store copies of
55:29responses for reuse reducing the need to
55:32repeated request to the server this
55:33improves load time reduces uh bandwidth
55:37and decreases server load right because
55:39the client does not need to download a
55:41lot of data and the server does not need
55:42to send a lot of data if the data is not
55:45changed this client can just reuse the
55:47old data right that's what caching means
55:49reusing the old data if the data is not
55:52changed in order to understand this
55:54let's just go through a demo instead of
55:56of going it theoretically how it looks
55:58like practically in a browser
56:00environment okay let's go to the request
56:03cycle and understand how caching works
56:06by following the trail let let me just
56:09do a refresh so when we first render the
56:12page we are doing a fetch operation so
56:14let's start from there okay we fired all
56:17these requests and what you want is the
56:19last one right because these are just uh
56:23JavaScript files and CSS and stuff okay
56:26okay what happened in the last request
56:30Let's see we did a get request to this
56:33endpoint API resource and there is
56:36nothing else in the request headers that
56:38we should focus on right now right let
56:41come let's come to the response what did
56:43the server respond with the first
56:45important thing is this one cache
56:48control what it says is you should
56:51maintain the cash for this resource for
56:55maximum 10 seconds right this is the
56:57first important header the next is e tag
57:01e tag is basically a hash so for the
57:05sake of this example we are using a
57:07random number but eags are usually
57:10hashes which are computed from a
57:12response for example the server might
57:14have taken this response hashed it and
57:17sent us that hash in the form of E tag
57:20right and we will see what is the use of
57:22that in the next request the next
57:24important header is last modified with
57:27this what the server is trying to say is
57:29this is the last time this request was
57:31modified and judging from this time and
57:34date we can decide whether we should use
57:36the old resource the cash resource or
57:39request for a new one these are the
57:41three important headers that we are
57:43going to use for caching okay so that is
57:47the initial request and in this request
57:49the server responded with a 200 along
57:52with the requested resource whatever
57:54that is we won't focus on that we are
57:56just seeing there is a response body all
57:59right what happens when we do a fetch
58:02operation for the same resource right
58:04let's do a
58:09fetch okay what happened here let's look
58:12at the response let's focus on the
58:15request first we are again doing a get
58:18request to this end point and now the
58:21headers to focus in the request is this
58:24these two headers if none match and if
58:28modified since what we are trying to say
58:31to the server is if the E tag the hashed
58:33version of the response object the E tag
58:37of the requested resource is not the
58:39same as this one which we have with us
58:41in the browser or if the request has
58:44been modified after this which means we
58:47have the outdated version right we are
58:49saying if the eag does not match or if
58:53the request has been modified after this
58:55then send us a new resource then send us
58:58the updated resource otherwise I will
59:00just use my cach version which I have
59:03with me in the browser cache and to that
59:05what server says is it responds with 304
59:09not modified and we just talked about
59:12different response codes right and 304
59:14meant the requested resource has not
59:17been modified ever since what the server
59:19did was it checked the if none match
59:21header which is which is the eag and it
59:24also checked the last modified and since
59:27the resource matched either the eag or
59:30the last modified it send the client a
59:34304 response which means the requested
59:37resource has not been modified ever
59:39since from the last time you fetched it
59:41so you can use you can go ahead and use
59:45your cast version let's update the
59:46resource for now let's clear
59:49this and let's fire an update
59:54resource okay what what happened here
59:57let's explore the first request okay
1:00:00ideally we should have done a patch
1:00:02request or put request but for the sake
1:00:05of this example again we just fired a
1:00:08request a post request okay we updated
1:00:10the resource and the server responded
1:00:12with 200 okay and it also sent us a new
1:00:14e tag right 2943 and after that the
1:00:19client did a new get request in this as
1:00:22you can see the client sent the old dag
1:00:25which which was 3141 our cast version so
1:00:29client did a get request with the old
1:00:32eag and the last modified sense to the
1:00:35server and the server responded with 200
1:00:37instead of 304 because the resource has
1:00:40been modified after that right because
1:00:42we did a update resource request and the
1:00:46server responded with 2943 which is the
1:00:50updated e tag the last modified Etc and
1:00:54let's go ahead again do a fet
1:00:59request okay and what do we have here we
1:01:03are again using the eag that was just
1:01:05provided by the server in this request
1:01:08right this was 200 and the server
1:01:12provided as with a new e tag we are
1:01:14using that e tag and the last modified
1:01:17value and we are doing another get
1:01:19request so the server checked it again
1:01:21and since it is the latest version of
1:01:23the resource it again responded with 304
1:01:25for not modified so this is how you
1:01:29handle caching using the HTTP protocol
1:01:31using different headers in server and
1:01:34client even though in a production
1:01:36setting it gets a lot complicated
1:01:38because the server has to manually
1:01:40Implement and manage all these e tags
1:01:43and if by mistake forgot to update an e
1:01:45tag right then the client will continue
1:01:48to use the cast version with the
1:01:50outdated resource which is not a good
1:01:52idea nowadays we have better Solutions
1:01:55for caching right for example react
1:01:58query which is a complete client side
1:02:00caching so the client has the complete
1:02:03power over when it wants to use a cach
1:02:06resource and when it wants to refetch
1:02:09right at what interval and all these
1:02:12powerful capabilities which is in my
1:02:14opinion a much better solution compared
1:02:17to the traditional HTTP based caching
1:02:20but it is good to know that we have this
1:02:23option if our use cases simple enough
1:02:26then we can go ahead and use HTTP based
1:02:29caching moving on another important
1:02:32topic that usually comes up in client
1:02:35server model in HTTP is content
1:02:38negotiation we already looked at some of
1:02:40these headers for example accept the
1:02:43content type application gson Etc so
1:02:47this is an important topic to understand
1:02:49how clients and servers exchange
1:02:52information about different types and
1:02:55and coding and representation of the
1:02:57content this is basically a mechanism
1:03:00using which client and server agree on
1:03:03the best format to exchange data the
1:03:06client can indicate its preferred format
1:03:09like Json or XML or HTML and the server
1:03:13will try to respond with a compatible
1:03:15format or if not available a fallback
1:03:18format that is the whole idea to look at
1:03:20a high level we have generally three
1:03:22types of content negotiation one is a
1:03:25med type which means the client
1:03:27specifies the desired format through the
1:03:29accept header which is application Json
1:03:32or XML then we have the language
1:03:35negotiation the client requests content
1:03:37in a specific language using the accept
1:03:40language header uh it could be English
1:03:43or Spanish then we have encoding
1:03:45negotiation right the client specifies
1:03:49which encoding it supports using the
1:03:51accept encoding header like gz or
1:03:54deflate and the server responds with
1:03:58that compression format we have a topic
1:04:00which is HTTP compression which is also
1:04:03part of this topic only so we will
1:04:05quickly see that also in the demo that's
1:04:07the whole idea and let's just jump into
1:04:09the demo to understand how it works and
1:04:11again there is a server running which
1:04:13will help us understand different types
1:04:15of content negotiation and this is a
1:04:17frontend client through which we will
1:04:19communicate with our server so let's
1:04:21just try out different types of requests
1:04:24and we'll see how the headers differ and
1:04:26how the responses differ depending on
1:04:28the types of headers the client is
1:04:29sending okay let's first just try the
1:04:32default one which is which is a language
1:04:34is English the format is Json and the
1:04:38preferred encoding is jip so let's do F
1:04:41FD source and this is what the request
1:04:43and response looks like okay so it was a
1:04:47get request to this
1:04:50endpoint and what we said is the
1:04:53language we are saying is English we are
1:04:56sending that information using the
1:04:58accept language header that we prefer
1:05:01the English language then what we are
1:05:03saying is the format is Json right we
1:05:06send that with accept application Json
1:05:09and there is the encoding header right
1:05:12that we are saying accept encoding the
1:05:15browser supports these kinds of
1:05:17encodings right JZ defl VR and zsd so we
1:05:21said we are expecting English and in
1:05:23Json format so this how this is how the
1:05:27server responded it it is sending us a
1:05:29Json
1:05:31and it is in English so let's trve one
1:05:34thing let's make it to Spanish and see
1:05:37how the response
1:05:38differs I made it Spanish and add did
1:05:42another
1:05:43fetch okay so let's see how this differs
1:05:46in this the only thing that changed was
1:05:49instead of accept language English in
1:05:51the header the client said accepted
1:05:53language is Spanish so depending on on
1:05:55that the server was able to update the
1:05:58response so instead of sending it in
1:06:00English since the client prefers Spanish
1:06:02the server responded with Spanish and
1:06:05what if we change the format from Json
1:06:08to XML and we do a
1:06:11Fetch and we look at this what change
1:06:14here we are saying we accepted format is
1:06:17XML and the accepted language is Spanish
1:06:21this is the XML format and the language
1:06:24is Spanish and on a high level this
1:06:27these are the benefits of using content
1:06:29negotiation based headers right the
1:06:30client can let the server know what are
1:06:33its preferences whether it is the data
1:06:36format or the language of the data and
1:06:39depending on that the server can decide
1:06:42to send according to that format it can
1:06:45make the life of the client Easier by
1:06:47sticking to the preferences those are
1:06:49the primarily two type of content
1:06:51negotiations while we are discussing
1:06:54content negotiation there is one
1:06:56interesting topic which falls under the
1:06:57same umbrella which is HTTP based
1:07:00compression it could be either gzip
1:07:01deflate or other formats right so let's
1:07:05look at why do we need compression and
1:07:08how does it work so now what I've done
1:07:10is I've gone ahead and replace the Json
1:07:13response with a very large file file of
1:07:1511,000 entries now let's file the
1:07:22request okay this is the response
1:07:25response and the size is 3.8 M since
1:07:28it's a very large file and let's look
1:07:32how the response looks
1:07:35like this is what it looks like because
1:07:38we are compressing the file on the
1:07:40server side with gzip encoding right
1:07:43here it says content encoding is gzip
1:07:46because the client says it accepts
1:07:49encoding of gzip one of the encoding
1:07:52formats now why do we use it to show
1:07:55that let me just go and disable
1:07:58compression in the server side okay and
1:08:01now that I have disabled the compression
1:08:02let's fire the same request
1:08:09again and as you can see the significant
1:08:12increase in the size it's the same file
1:08:15right it's the same file with 11,000
1:08:17entries and because we are using
1:08:19compression the file size was 3.8 MB and
1:08:22now that we have disabled it the file
1:08:25size becomes 26 M that's a huge increase
1:08:29in size and imagine every client having
1:08:32to download that file it it it caes a
1:08:35lot of based of bandwidth and that is
1:08:37why we need compression so that if the
1:08:40response size is very large we can
1:08:43compress it to a format and on the
1:08:46client side the browser can decompress
1:08:48it and it will get the same response and
1:08:51this is another important topic which we
1:08:55won't really work with it's good to know
1:08:58that it exists behind the scenes in the
1:09:00early days of HTTP specifically HTTP 1.0
1:09:04each request response cycle required a
1:09:06separate connection to the server now
1:09:09this created inefficiencies since
1:09:11establishing and closing TCP connections
1:09:14is resource intensive and slow to
1:09:16address this persistent connections were
1:09:19introduced in HTTP 1.1 now with
1:09:21persistent connections a single TCP
1:09:24connection can be reused for for
1:09:25multiple requests and responses avoiding
1:09:28the overhead of opening and closing a
1:09:30collection for every interaction and for
1:09:34achieving that they introduced this
1:09:36header called keep alive keep alive is
1:09:40the mechanism that enables persistent
1:09:42connections it allows the client and
1:09:45server to reuse the same connection for
1:09:47multiple request responses until one of
1:09:50them decides to close it so what are
1:09:51some key points to remember here in sttp
1:09:541.1 connections are persistent by
1:09:57default we won't have to do anything
1:09:59explicitly about them meaning they
1:10:02remain open for further requests unless
1:10:04explicitly closed and multiple SB
1:10:07request and responses can be sent over a
1:10:09single connection this reduces latency
1:10:12and saves resources as fewer connection
1:10:14need to be established now the second
1:10:16thing is the keep alive header while
1:10:19persistent connections are default in
1:10:21HTTP 1.1 the connection keep alive
1:10:24header is it's still sometimes used to
1:10:26explicitly ask the server to keep the
1:10:29connection open this header can also
1:10:32include option like how long the
1:10:33connection should remain open with a
1:10:36timeout or how many requests can be sent
1:10:38before the connection is closed with the
1:10:41max value now the third thing is when
1:10:43connection is set to close and when that
1:10:46is specified the connection is closed
1:10:48after the response is sent this is the
1:10:51behavior in HTTP 1.0 by default and it
1:10:53can still explicitly enforced in HTTP
1:10:561.1 that is some amount of information
1:10:59you just have to understand but you
1:11:01usually won't be working with them the
1:11:03default values work fine one last topic
1:11:05that I want to cover is handling large
1:11:08request and responses how server takes
1:11:12in large request like Files video files
1:11:15image files audio files any kind of file
1:11:17which are very large compared to our
1:11:20typical Json and how client can receive
1:11:23large responses in the same way so let's
1:11:26just jump into the demo and see how it
1:11:29usually works now here we have two
1:11:31examples in one we will see how clients
1:11:35can send large request to the server and
1:11:38in the second one we'll see how servers
1:11:40can send large responses to the client
1:11:43first one is multiart request multiart
1:11:46is usually used for sending large files
1:11:48or any kind of files to the server from
1:11:51the client and the difference between
1:11:53our typical Json request body is in
1:11:55multiart request the file the data of
1:11:59the file the binary data is transferred
1:12:01to the server in Parts in different
1:12:04parts that's why it is called multiart
1:12:06request so let's see how it looks like I
1:12:09have selected a picture and let's click
1:12:13on upload
1:12:15file now let's look at the response of
1:12:18this here is what the request looks like
1:12:20it is a post request and we are
1:12:23specifying a Content length and our
1:12:26content type is multiart form data and
1:12:30this is the important part the boundary
1:12:33and why we need this is since our binary
1:12:37data the binary data of the file is
1:12:40transferred in parts we want to specify
1:12:43what is going to be the delimit what
1:12:46will separate the parts right we need
1:12:48some kind of code that will separate the
1:12:50parts so we are saying this will be our
1:12:53delimiter and if we do a search
1:12:59here we have the delimeter at the start
1:13:02of the binary data and the next
1:13:04occurrence
1:13:05is at the end of it when the all the
1:13:09binary data ends in the request body
1:13:12right that is the use of the boundary
1:13:14parameter and that is how we transfer a
1:13:17large file to the server and the server
1:13:19can read the file responds with the some
1:13:22details of the file in order to say that
1:13:24the upload was successful the idea is
1:13:27whenever we want to transfer large files
1:13:29to the server we should use multiart
1:13:32requests okay now the second thing is
1:13:35receiving large responses from the
1:13:37server for this demo I have used a large
1:13:41text file in the server side and we want
1:13:44to stream the data to the client side in
1:13:47chunks that's what we want to do so
1:13:50let's start the so let's start the
1:13:53request and see how it looks like
1:13:55click on stream
1:13:57data so as you can see this is the first
1:14:03chunk okay so if you go
1:14:09here you can see that we are receiving
1:14:12chunks continuously from the server in
1:14:14different different requests so the
1:14:15request is pretty much a normal request
1:14:18it is a get request let's look at the
1:14:20response what the response looks like
1:14:22these are the three important things
1:14:24that we have to to consider one is
1:14:26content type it is saying that it is not
1:14:29a text content right it is a text event
1:14:31stream which says it will stream the
1:14:34data to the client through different
1:14:36events and the second one is the
1:14:38connection keep alive it says keep the
1:14:40connection alive until all the data is
1:14:42sent and if is here we are still
1:14:44receiving the chunks and we can keep
1:14:47scrolling and scrolling and until the
1:14:49file is completely transferred the
1:14:51server will keep sending the data in
1:14:53chunks and how does it work because of
1:14:56these headers the content type text
1:14:58event stream and the connection keep
1:15:00live right and the client keeps
1:15:03appending all the data that it is
1:15:05receiving from the server and
1:15:06constructing this whole text file and
1:15:10that is how we transfer a large file
1:15:13from a server to the client using chunk
1:15:16transfer or text event stream and the
1:15:18last thing before we end this lesson I
1:15:21just want to give a brief idea about
1:15:23what these terms mean SSL or TLS or
1:15:26https even though we don't explicitly
1:15:28work with them it's good to know what
1:15:30are these SSL was the original protocol
1:15:34for securing Communications between
1:15:36client like a web browser and server it
1:15:39encrypts data so that the sensitive
1:15:42information like passwords or credit
1:15:44card numbers cannot be intercepted by
1:15:46attackers right it was the original
1:15:48encryption mechanism between clients and
1:15:50server now currently SSL is outdated due
1:15:54to some some security vulnerabilities
1:15:56and has been replaced by TLS so this is
1:16:00the modern version of the encryption
1:16:02that client and servers use for data
1:16:04transmission TLS is a modern and more
1:16:07secure version of SSL it encrypts data
1:16:09in transit ensuring that any data sent
1:16:12between the client and server is
1:16:14protected from interception and
1:16:16tampering how it works is TLS uses
1:16:19certificates to authenticate the server
1:16:21and establish an encrypted connection
1:16:23preventing Eve dropping and data bries
1:16:26TLS is continuously updated with newer
1:16:28versions offering better security the
1:16:30current recommended version is TLS 1.
1:16:34and what is https then https is
1:16:37basically HTTP but more secutive
1:16:41features which is which are provided by
1:16:44SSL or TLS initially it was SSL and now
1:16:48it is TLS the underlying mechanism is
1:16:50TLS and https is the one which uses TLS
1:16:56how it works is when you visit a website
1:16:58using
1:16:59https TLS encrypts the communication
1:17:02between your browser and the server this
1:17:05protects sensitive data like login
1:17:07credentials from being intercepted by
1:17:09the attackers and that much information
1:17:11is more than enough on this topic that's
1:17:14all you need to know about TLS and sdps
1:17:16to work on application Level great we
1:17:20talked about a lot of stuff I hope
1:17:22you're able to digest that and I hope
1:17:25you rewatch some of the sections so that
1:17:28you are able to internalize all of them
1:17:30and overally this is all you need to
1:17:33know about HTTP at least of course there
1:17:37are more stuff to read if you want on
1:17:39HTTP or TLS or PCP protocol different
1:17:43different components of HTTP but in
1:17:45order to work on backend systems if you
1:17:48understand this much if you internalize
1:17:51this much and you can visualize the
1:17:53whole flow of all the the components
1:17:55that we talked about today then you're
1:17:57good to go you'll be able to understand
1:17:59all you need to understand and you'll be
1:18:01able to debug most of the stuff now that
1:18:03you understand how the system works
1:18:06behind the scenes and what are the
1:18:07components that come into play in
1:18:09different different flows that's all
1:18:11about http

About this transcript

This page contains the full transcript of 5. Understanding HTTP for backend engineers, where it all starts by Sriniously, generated from the public captions YouTube serves with the video. The transcript has 12,458 words across 1,812 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.