Skip to main content

HTTP/1.0 and HTTP/1.1

HTTP is a protocol used to exchange or transfer hypertext. Hypertext is structured text that uses logical links (hyperlinks) between nodes containing text. Tim Berners-Lee and his team at CERN are credited with inventing the original HTTP along with HTML and the associated technology for a web server and a text-based web browser. Berners-Lee first proposed the "WorldWideWeb" project in 1989 — now known as the World Wide Web. The first version of the protocol had only one method, namely GET, which would request a page from a server. The response from the server was always an HTML page.
                                                        Tim Berners-Lee authored/co-authored multiple RFCs (Request for Comment) including RFC 1945 (which was published in 1996 and talks about Hyper Text Transfer 1.0), RFC 2068 (which describes HTTP/1.1 & was published in 1997), RFC 2616 (which obsoletes the RFC 2068 and made HTTP/1.1 official). Because of his extensive work towards HTML, HTTP, and others he is also known as father of World Wide Web.
     Berners-Lee is presently the director of the World Wide Web Consortium (W3C), which oversees the Web's continued development.

In 2007, the HTTPbis (where bis means "repeat" or "twice") Working Group was formed, to revise and clarify the HTTP/1.1 specification. In June 2014, the WG released an updated six-part specification obsoleting RFC 2616 :

RFC 7230 , HTTP/1.1: Message Syntax and Routing
RFC 7231 , HTTP/1.1: Semantics and Content
RFC 7232 , HTTP/1.1: Conditional Requests
RFC 7233 , HTTP/1.1: Range Requests
RFC 7234 , HTTP/1.1: Caching
RFC 7235 , HTTP/1.1: Authentication

HTTP/2 (originally named HTTP/2.0) was published as RFC 7540 in May 2015.



Improvements made in HTTP/1.1 over HTTP/1.0 :-

HTTP/1.0 made a separate connection to the same server for every resource request. HTTP/1.1 can reuse a connection multiple times to download images, scripts, stylesheets, etc after the page has been delivered. HTTP/1.1 communications therefore experience less latency as the establishment of TCP connections presents considerable overhead.


This portion of the article is still incomplete and need some more time for improvements.

For info about differences in HTTP/1.0 and HTTP/1.1, please visit the below link-
http://www2.research.att.com/~bala/papers/h0vh1.html




List of Status Codes in HTTP :-

The first digit of the status code specifies one of five classes of response; the bare minimum for an HTTP client is that it recognises these five classes.

1xx Informational
Request received, continuing process. This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. Since HTTP/1.0 did not define any 1xx status codes, servers must not send a 1xx response to an HTTP/1.0 client except under experimental conditions.

2xx Success
This class of status codes indicates the action requested by the client was received, understood, accepted and processed successfully.

3xx Redirection
This class of status code indicates the client must take additional action to complete the request. Many of these status codes are used in URL redirection. A user agent may carry out the additional action with no user interaction only if the method used in the second request is GET or HEAD. A user agent should not automatically redirect a request more than five times, since such redirections usually indicate an infinite loop.

4xx Client Error
The 4xx class of status code is intended for cases in which the client seems to have erred.
The server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method.

5xx Server Error
The server failed to fulfill an apparently valid request. Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request.
Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition.

Reference -- https://en.wikipedia.org/wiki/List_of_HTTP_status_codes



HTTP and HTML :-

HTML is a description "language" for how to present information that passes via http, HTML stands for Hyper Text Markup Language.
Hyper Text Transfer Protocol, http, is a computer protocol or set of procedures, describing how computers may pass information in an orderly fashion.






Popular posts from this blog

Flaw in ServerKeyExchange messages of TLS Protocol

Here we will discuss the flaw in the ServerKeyExchange messages of the TLS protocol which caused the Logjam attack over TLS while using Diffie-Hellman Key Exchange. Before SSLv3, we don't use to authenticate the ServerKeyExchange messages where server negotiates with client regarding usage of cipersuite and parameters. From onwards SSLv3, TLS send the signed message where it mention about parameters it will use but remain silent over ciphersuite. Or in other words, signed portion contains parameters but not contain information about ciphersuite the server will going to use. Now just to remind you, the difference between DH and DH-EXPORT is the size of parameters only. So how to use this flaw - If the server supports DH-EXPORT, an attacker (Men-in-the-Middle) can edit the negotiation sent by the client (even if client doesn't support DH-EXPORT), and replace the list of client supported ciphersuite with DH-EXPORT only. The server will in turn send back a

Identity PSK ( iPSK)

With the evolution of IoT (Internet of Things), devices that connect wirelessly have increased many folds. From webcams, Smartwatches, fitness bands, firestick, Alexa, Google Home, and many more.., everything is going wireless for connectivity and so does the security threat. The main concern with IoT devices is the unavailability of the full wireless protocol stack (and in the majority of devices, support of 802.1x is not available). So, previously we only have the WPA-PSK option for connecting the IoT devices.  In WPA*-PSK (WPA or WPA2) WLAN, a Pre-Shared Key (PSK) is configured and distributed to all the clients that connect to the WLAN. This leads to PSK leakage, and it can be accessible to unauthorized users (due to the nature of common PSK across all the devices).  Therefore, there was a need to provision unique PSK or Multiple PSK per SSID. Identity-PSKs are unique pre-shared keys created for clients/groups on the same WLAN. Features of iPSK:-   1.Unique PSK for individual Cli