http

[ilyas001]

hi guys i got some questions 

1- how can http be reliable if it's stateless.  i mean reliability is a udp or tcp matter but still how can tcp knows what it most recent if http don't care what's sending 

2- from the first question it's obvious that i don't really understand http if you have time to help me understand what's the purpose of this protocol in the first place it would be great thanks

edit 3-normaly it's the tcp or udp that have headers now i learn that there is a http headers so who is the head and why ?

 

[mariushm]

tcp is at network level, it makes sure data packets are transferred between computers correctly by relying on error correction information inside the data packets to check for errors and request retransmission if needed.

http is a protocol, it's like a language , a method / way, a common language, it's how software talks to servers to retrieve content.  browsers connect to remote web server, request something using specific keywords that are expected by the web server and the web server responds in the same manner by using some keywords and a special formatted text to tell the browser the result of the request, and if the request was successfully processed, that special formatted text (the headers) are followed by the actual content of the page or by the file being downloaded.

There's no communication between user's computer (the browser) and the web server teling the web server to re-send parts of the response because it got corrupted, the TCP underneath does that.  I mean nothing explicit, because http protocol allows clients to request parts of file downloads using specific commands (but they're not in the protocol as a means for error correction)

 

read https://www.w3.org/Protocols/rfc2616/rfc2616.html   have a look at introduction, overall operation (1.4) , chapters 4,5,6 (http message  / request / response)

[ilyas001]

11 hours ago, mariushm said:

tcp is at network level, it makes sure data packets are transferred between computers correctly by relying on error correction information inside the data packets to check for errors and request retransmission if needed.

http is a protocol, it's like a language , a method / way, a common language, it's how software talks to servers to retrieve content.  browsers connect to remote web server, request something using specific keywords that are expected by the web server and the web server responds in the same manner by using some keywords and a special formatted text to tell the browser the result of the request, and if the request was successfully processed, that special formatted text (the headers) are followed by the actual content of the page or by the file being downloaded.

There's no communication between user's computer (the browser) and the web server teling the web server to re-send parts of the response because it got corrupted, the TCP underneath does that.  I mean nothing explicit, because http protocol allows clients to request parts of file downloads using specific commands (but they're not in the protocol as a means for error correction)

 

read https://www.w3.org/Protocols/rfc2616/rfc2616.html   have a look at introduction, overall operation (1.4) , chapters 4,5,6 (http message  / request / response)

thanks for this great answer but still , before i go read your link well tell  me first . http have a header and i know that tcp also have a header so the frame have like 2 headers or what ? also i don't get your talk about redownload missing or corrupt files i mean web pages are always clean i never saw a mistake in a leaded web page it's not possible to no have reliability still why is html stateless if it's the tcp that make the transfer so what does the http even have to do with being stateless or not why mention this in the first place if reliability is forced by tcp ?

[mariushm]

oh man you're thick...

 

When a browser accesses a website it uses the HTTP protocol to retrieve resources like the html page, images on the page, javascript and css files. Each request is a file download. The browser downloads the html page as a file download and as it's being downloaded it parses it (it decodes the content because it knowns how to read html , the scripting language in which the page is written) and automatically detects what CSS and Javascript files and what images have to be downloaded to draw the page nicely on the screen.

Just because you see web pages "always clean" doesn't mean there aren't errors in the rendering of the page .. for example a forum page may reference an avatar image or a picture in a signature that's hosted on a website which no longer exists - in this case the browser simply replaces the missing image with a placeholder and keeps rendering the page.

What I'm saying is that http protocol doesn't have error correction builtin -  as the html is downloaded and parsed by the browser to draw everything nice on the screen, there's no way to check that a specific chunk of that html page, of that stream of bytes (the code that tells the browser how to arrange everything on the screen) was correctly received or to re-send that chunk of html page when an error is detected.

This role is performed  by TCP, which basically works with packets of data, without care of what kind of packet of data is.

 

When user requests a page from a web server, that web server processes the request and prepares the response (the html page) and starts sending the data to the user. This data is split automatically by the network card (drivers) into TCP frames, checksum and error correction information is added to the frames, the frames are pushed towards the ISP of the web server and these packets of data arrive to user's ISP and then are forwarded into the network card of home user's computer which reads the tcp frame contents,  takes out the error correction information from the frame, checks to see if the frame is corrupted or not (if some bits were flipped between network card of server and network card of user) and if there's something wrong, it tries to correct the frame using the error correction information. If that's not possble, it talks back to the network card of the server and requests to resend that frame which ideally is still held in memory on that computer until the user's network card says it received it correctly or some time passes. Only if the frame is OK it's passed along to the software on the user's computer, in our case the web browser.

So even if there were some minor transmissions, tcp takes care of that invisible to the applications running on top of tcp , and the web browser sees everything as a simple file download.

[ilyas001]

16 minutes ago, mariushm said:

oh man you're thick...

 

When a browser accesses a website it uses the HTTP protocol to retrieve resources like the html page, images on the page, javascript and css files. Each request is a file download. The browser downloads the html page as a file download and as it's being downloaded it parses it (it decodes the content because it knowns how to read html , the scripting language in which the page is written) and automatically detects what CSS and Javascript files and what images have to be downloaded to draw the page nicely on the screen.

Just because you see web pages "always clean" doesn't mean there aren't errors in the rendering of the page .. for example a forum page may reference an avatar image or a picture in a signature that's hosted on a website which no longer exists - in this case the browser simply replaces the missing image with a placeholder and keeps rendering the page.

What I'm saying is that http protocol doesn't have error correction builtin -  as the html is downloaded and parsed by the browser to draw everything nice on the screen, there's no way to check that a specific chunk of that html page, of that stream of bytes (the code that tells the browser how to arrange everything on the screen) was correctly received or to re-send that chunk of html page when an error is detected.

This role is performed  by TCP, which basically works with packets of data, without care of what kind of packet of data is.

 

When user requests a page from a web server, that web server processes the request and prepares the response (the html page) and starts sending the data to the user. This data is split automatically by the network card (drivers) into TCP frames, checksum and error correction information is added to the frames, the frames are pushed towards the ISP of the web server and these packets of data arrive to user's ISP and then are forwarded into the network card of home user's computer which reads the tcp frame contents,  takes out the error correction information from the frame, checks to see if the frame is corrupted or not (if some bits were flipped between network card of server and network card of user) and if there's something wrong, it tries to correct the frame using the error correction information. If that's not possble, it talks back to the network card of the server and requests to resend that frame which ideally is still held in memory on that computer until the user's network card says it received it correctly or some time passes. Only if the frame is OK it's passed along to the software on the user's computer, in our case the web browser.

So even if there were some minor transmissions, tcp takes care of that invisible to the applications running on top of tcp , and the web browser sees everything as a simple file download.

thanks bro it's getting clearer and clearer here so tcp is for the correction and http is the way that the clien server communicate between each other . when the informations are asked by the client and  proceeded by the server it takes the requested html files and sent them as fragments by tcp that make sure of the correctness of the information until the download is over ok if i get it right men it's all because of you thanks . and last question why the protocol is named html when you are gonna get css and javascript files also ?

[mariushm]

Because when HTML was invented there was no css and javascript .

 

HTML is short for Hypertext markup language and was invented in 1993 , and it's derived from SGML, a language that first appeared in 1986.

 

CSS is short for cascading style sheets and it's optional (you don't need it to make html pages but it does make things much easier to use it  .. like instead of saying every time you want to show a link on  the page that you want the color of the link to be red, and text bolded and underlined with a line that's two pixel thick, you can just create a "template", a style and then in your html page you say "just apply this style to all links, unless I say otherwise". So it saves you from writing things a lot and repeating yourself in the page and it makes it easier to maintain pages (instead of having to go in 10-20 places to change color from red to green if you change your mind you just make one change in the style sheet. Anyway, the point is that it was invented in 1996, three years after html was invented, and it took more than that for web browsers to all support the majority of the features of CSS.

Javascript popped up around 1995, two years after html showed up, and it wasn't supported by web browsers from the start. If I remember correctly Microsoft was pushing vbscript and other things for browsers through Internet Explorer

[ilyas001]

12 minutes ago, mariushm said:

Because when HTML was invented there was no css and javascript .

 

HTML is short for Hypertext markup language and was invented in 1993 , and it's derived from SGML, a language that first appeared in 1986.

 

CSS is short for cascading style sheets and it's optional (you don't need it to make html pages but it does make things much easier to use it  .. like instead of saying every time you want to show a link on  the page that you want the color of the link to be red, and text bolded and underlined with a line that's two pixel thick, you can just create a "template", a style and then in your html page you say "just apply this style to all links, unless I say otherwise". So it saves you from writing things a lot and repeating yourself in the page and it makes it easier to maintain pages (instead of having to go in 10-20 places to change color from red to green if you change your mind you just make one change in the style sheet. Anyway, the point is that it was invented in 1996, three years after html was invented, and it took more than that for web browsers to all support the majority of the features of CSS.

Javascript popped up around 1995, two years after html showed up, and it wasn't supported by web browsers from the start. If I remember correctly Microsoft was pushing vbscript and other things for browsers through Internet Explorer

thanks bro i also watched a video just now  it's says it stars first with the content then the media then the css then the javascript anyway bro i have the full picture now thanks 

[mariushm]

if you're curious, you can have some fun with  WebPageTest website, it will show what's being downloaded and how the page is built by the browser.

here's for example this page (not sure how long the test result is kept on their servers, link may be broken after some time) : https://www.webpagetest.org/result/161010_JQ_YPY/1/details/