Sunday, August 2, 2009

RFC 2616-Hypertext Transfer Protocl HTTP 1.1

Hi All , This article is an attempt to explain commonly used protocols in much simple way . Let's start with the most familiar protocol widely used by Netizens while browsing.... that is Http .

Here we go !!...
When you open a browser like IE or Mozilla Firefox , in the address bar you type in http://www.anywebsite.com/ and you will get all the conetnts of the webpage ,but what excactly happens in the background ?...let me try to explain in detail . Setting aside the DNS resolution and the way TCP 3 way handshake takes palce and the way a transport layer virtual circuit established between two programs for the purpose of communication Here we focusing on the way Http works .

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems.

The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a requestmethod, Uniform Resource Identifier (URI)-A network data object or service that can be identified by a URI and protocol version, followed by a MIME-like message containing request modifiers, clientinformation, and possible body content over a connection with a server.
Packet Capture 1:

your browser is asking for the page called "http.html". It wants to use the http1.1 protocol. Your browser is in English-US and is Microsoft Internet Explorer 6.0 under WNT 5.1.Your browser wants the connection (socket) stays opened between you and the destination web server it can ask for further files, like pictures included in this page...

Packet Capture 2:
In response to this , the web server knows the page you want and can send it : code 200 means its all OK!! Then, you have some more infos about the server : Apache on Unix, socket closed after html page, last modification date and so on (see attributs page for more information). And finally, the requested file...And Boom!!..you will get the requested webpage on your screen .

Lets look in to whar Http codes and Http headers are composed of :
In Http Header A first line containing the request statuts.Example : HTTP/1.1 200 OK
1 few line contining some attributes on the request.Example : Content-Type: text/htmlHttp codes sent by the server gives the status on the current http request.Theses codes are
normalized : Informational, request received, continuing process .
















Here are some components in the packet capture detailed ;




The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.If the Request-URI refers to a data-producing process, it is theproduced data which shall be returned as the entityin the response and not the source text of the process, unless that text happens to be the output of the process.


The Referer request-header field allows the client to specify, for the server’s benefit, the address (URI) of the resource from which the Request-URI was obtained.

The Accept request-header field can be used to specify certain media types which are acceptable for the response.Accept headers can be used to indicate that the request is specifically limited to a small set of desired types, as inthe case of a request for an in-line image.The asterisk “*” character is used to group media types into ranges, with “*/*” indicating all media types and“type/*” indicating all subtypes of that type. The media-range MAY include media type parameters that areapplicable to that range.



In a nutshell ;

HTTP uses the client-server model: An HTTP client opens a connection and sends a request message to an HTTP server; the server then returns a response message.

The initial request line is different for the request than for the response. A request line has three parts, separated by spaces: a method name, the local path of the requested resource, and the version of HTTP being used.
A typical request line is:
GET /path/to/file/index.html HTTP/1.0

GET is the most common HTTP method; it says "get me this resource".

Other methods include POST and HEAD.

The HEAD Method HEAD request is just like a GET request, except it asks the server to return the response headers only, and not the actual resource (i.e. no message body). This is useful to check characteristics of a resource without actually downloading it, thus saving bandwidth. Use HEAD when you don't actually need a file's contents.
The response to a HEAD request must never contain a message body, just the status line and headers. A POST request is used to send data to the server to be processed in some way, like by a CGI script.

The path is the part of the URL after the host name, also called the request URI (a URI is like a URL, but more general). The HTTP version always takes the form "HTTP/x.x", uppercase.

Response Line (Status Line)
The initial response line, called the status line, also has three parts separated by spaces: the HTTP version, a response status code that gives the result of the request, and an English reason phrase describing the status code. Typical status lines are:
HTTP/1.0 200 OK
or
HTTP/1.0 404 Not Found
The most common status codes are:
200 OK The request succeeded, and the resulting resource (e.g. file or script output) is returned in the message body.

404 Not Found The requested resource doesn't exist.

301 Moved Permanently

302 Moved Temporarily

303 See Other (HTTP 1.1 only) The resource has moved to another URL (given by the Location: response header), and should be automatically retrieved by the client. This is often used by a CGI script to redirect the browser to an existing file.

500 Server Error An unexpected server error. The most common cause is a server-side
script that has bad syntax, fails, or otherwise can't run correctlyfor HTTP 1.0, and section 10 for HTTP 1.1

How HTTPS works ?



In this section only let me try to describe how the HTTPS communication takes place; Again this is request/protocol . imagaine that you are trying to browse a secure website like https ://anywebsite.com and following process needs to be passed in background ;

1.As we know any browser Like IE 7 or Mozilla firefox will come with the severa l CA issuer certificates .And these certificates will have the Public key for the issuer of the cerfticiate and other information . Its a key used to encrypt the data so that only the reciever is having valid private key will bable to see it .

When anyone wants to use SSL , he needs to purchase a certificate thats signed using the CA's Private key .

2. Once the web browser starts the connection to the secured site allong with the request and other information it will send all supported encryption schemes.

3. The webserver will response the browser client information with the copy of the certificate that is signed using the CA's Private key and information about supported encryption schemes .

4. Once the certificate is downloaded to the browser client , it will be tested against the CA's public key installed on the Web browser ..if everything seems to be okay..then connection will be establiched and data will be downloaded using the secure encryption scheme earier negotiated while SSL handshake .

Let me try explaining the same with the following packet capture ; In this following example connection fails as browser recieves the certificate from server and its tested against the Public key installed in browser and connection won't establish because it turns out be a Bad certificate .









No comments: