WEB Versus Client-Sever systems

The World Wide Web is a special case of the client-server paradigm.Client-Server means one or more centralized server computers that serve data, resources, programs connected to server a number of client computers.Traditionally, this involves a powerful central server connected to remote client computers that are often "dumb" in that they do no actual computation and simply provide an interface to the server. You can think of a dumb terminal as a keyboard and monitor into the remote server.

Many UNIX servers that are connected to thin clients, which means that most applications run on the server, but the clients are capable of local data storage and other small computational tasks.The server does most of the heavy computations.Windows networks are typically just the other way round, with the "fat client" possessing basic Office applications and browsing, with separate servers used for major services requiring either the network (Web server, DNS, and so on) or massive storage requirements (database and file servers).

WEB is a special case of the Client-Server model using fat clients and operating on protocols like HTTP, HTML, XML, and Simple Object Access Protocol (SOAP)...Moreover it adds the interesting problem of "untrusted" users. Whereas traditional networks exist within the firewalled protection of a company's private network. In traditional Client-Server networks it is fairly clear what processing should take place on the client and on the server.Also both of client and the server normally exist within the walls of a corporate ...

But this is not the case with the World Wide Web....The Web is different because the clients exist outside the control of the central server and the network.Unlike a LAN Web has no boundaries to protect.All the clients have to be treated as untrusted which puts additional requirements on how computation is distributed across the client and the server.LANs can be designed to maximize performance. The more computation that can be "pushed" to the client the faster the central server can execute.Perhaps this is one reason why the fat client paradigm has won out over thin clients.The computational burden can be more distributed for speeding up the network for everyone.

But the Web is a different thing altogether... It is essentially a network of untrusted clients and any of those can be hostile.This means that every input that originates at a client must be carefully checked and all security operations must be performed on the server.

World Wide Web

Networked computers are not new for us. We have been connecting computers in a LAN and WAN before Web. Even Web is a specialized version of what is called a client-server network. Client-server networks conserve computing resources by delegating complex and time-consuming computation to powerful, expensive computers called servers. Server machines tend to have large storage and memory capacity and multiple fast processors. Their speed allows them to complete computationally intense processing faster than a typical computer and then serve their results to smaller and less powerful machineswhich are known as clients.

In client-server networks, there are really three things of importance:

1. The server computer
2. One or more client computers
3. A connection between the client and server which is called as Network

At the client, a software must be developed to connect to the network to send and receive requests and data. It's the same for the server. At the network layer, we need protocols to allow the computers to communicate.
We alos need to handle bandwidth issues, lossy transmission of data, collisions, errors, and one or the other computer not being available.But all of this has been figured out for various situations. Protocols like Transmission Control Protocol (TCP), and User Datagram Protocol (UDP) as well as supporting protocols like Internet Protocol (IP), Address Resolution Protocol (ARP), and the Domain Name System (DNS) have been implemented and made easy to use for developers on both the client and server side.

World Wide Web: new network layer protocols, new server software to handle the connections and serve the variety of content demanded by the clients, and new client software to browse remote servers and search through the entire universe of servers for the one that had the required information. World Wide Web arrived as a network of computers that span over whole world and speak the same languages and protocols:

HyperText Transfer Protocol (HTTP),
Hypertext Markup Language (HTML),
eXtensible Markup Language (XML) etc.

The Web began largely as a replacement for the major functionality of the Internet: e-mail and File Transfer Protocol (FTP): ways of communicating and sharing files. Initially there was a method for sharing files between many users was a system called gopher. It was much like the Web we know today. GOPHER allowed users to search for documents using Veronica (the Google of its time) and documents could be linked together and navigated to.Gopher disapeared around 90s.HTML as a language of the Web was much more powerful and expressive than that used by gopher.

The magic behind this was a server-side program called a Web server that allowed remote clients to access certain parts of the server computer's hard drive. The Web changed everything about the way we shared files and communicated information.Web browser was the ultimate tool for a client computer to connect to the growing number of Web pages that were sprouting up on servers everywhere.

After that lot many things came into light for making this more dynamic in nature and flexible in usability.
These days many of us can't imagine life withoout these applicatons of World Wide Web...

What is SOAP (Simple Object Access Protocol)

SOAP is a way to transport XML from one end point to another.

It supports a number of standard transport protocols which includes TCP, HTTP and SMTP. HTTP is most popular among all of these.


Basic idea of SOAP is to provide a mechanism by which an XML information can be wrapped in an envelop and which can be further carried by variety of transport mechanisms.

In a SOAP message, there are two main components:
- Header
- Body

As names signify, Header contains information abou actual SOAP message and body contains the actual message payload.

Filtering Mechanisms in Fiddler: Can we see filtered http calls made through a particular Application?

Yes, Fiddler provide very efficient ways to filter http requests generated through particular application. Here are the steps to achieve this:

- Launch fiddler
- Start your Application
- Launch Fiddler
- Go to Filter tab on right hand side
- Check "Use Filters" option
- Now all filter parameters will be enabled.
- Go to "Client process" section
- Check option : "Show traffic only from"
- Now a dropdown will be enabled >> Select the exe you want to monitor
- This dropdown shows all the processes running on your machine

Apart from this, there are different type of Filters.

1. Filtering on the basis of Hosts. E.g.- you can opt to see only those calls which are made on www.google.com
2. You can also opt for seeing calls which are failing by selecting option for hiding success calls :)
3. We can filter on the basis on content : Images, Text, HTTP, Scripts...

Explore Filter Menu in details....

HTTP Status Code : 1XX Informational

1xx Informational

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

100 Continue

This means that the server has received the request headers, and that the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). If the request body is large, sending it to a server when a request has already been rejected based upon inappropriate headers is inefficient. To have a server check if the request could be accepted based on the request's headers alone, a client must send Expect: 100-continue as a header in its initial request

101 Switching Protocols

This means the requestor has asked the server to switch protocols and the server is acknowledging that it will do so.

102 Processing

HTTP Status Codes : 2XX for Success

2xx Success

This class of status code indicates that the client's request was successfully received, understood, and accepted

200 OK

Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action.

201 Created

The request has been fulfilled and resulted in a new resource being created.

202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.

203 Non-Authoritative Information

The server successfully processed the request, but is returning information that may be from another source.

204 No Content

The server successfully processed the request, but is not returning any content.

205 Reset Content

The server successfully processed the request, but is not returning any content. Unlike a 204 response, this response requires that the requestor reset the document view.

206 Partial Content

The server is serving only part of the resource due to a range header sent by the client. This is used by tools like wget to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.

207 Multi-statuses

The message body that follows is an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.

HTTP Status Codes: 3xx Redirection

The client must take additional action to complete the request.

This class of status code indicates that further action needs to be taken by the user agent in order to fulfil the request. The action required may be carried out by the user agent without interaction with the user if and 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.

300 Multiple Choices

Indicates multiple options for the resource that the client may follow. It, for instance, could be used to present different format options for video, list files with different extensions, or word sense disambiguation.

301 Moved Permanently

This and all future requests should be directed to the given URI.

302 Found

This is the most popular redirect code, but also an example of industrial practice contradicting the standard. HTTP/1.0 specification (RFC 1945 ) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"), but popular browsers implemented it as a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to disambiguate between the two behaviors. However, the majority of Web applications and frameworks still use the 302 status code as if it were the 303.

303 See Other (since HTTP/1.1)

The response to the request can be found under another URI using a GET method. When received in response to a PUT, it should be assumed that the server has received the data and the redirect should be issued with a separate GET message.

304 Not Modified

Indicates the resource has not been modified since last requested. Typically, the HTTP client provides a header like the If-Modified-Since header to provide a time against which to compare. Utilizing this saves bandwidth and reprocessing on both the server and client.

305 Use Proxies (since HTTP/1.1)

Many HTTP clients do not correctly handle responses with this status code, primarily for security reasons.

307 Temporary Redirect (since HTTP/1.1)

In this occasion, the request should be repeated with another URI, but future requests can still use the original URI. In contrast to 303, the request method should not be changed when reissuing the original request. For instance, a POST request must be repeated using another POST request.

HTTP Status Codes: 4xx Client Error

The request contains bad syntax or cannot be fulfilled.

The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, 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. User agents should display any included entity to the user. These are typically the most common error codes encountered while online.

400 Bad Request: The request contains bad syntax or cannot be fulfilled.

401 Unauthorized: Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided. See Basic access authentication and Digest access authentication.

402 Payment Required: The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, but that has not happened, and this code has never been used.

403 Forbidden: The request was a legal request, but the server is refusing to respond to it. Unlike a 401 unauthorized response, authenticating will make no difference.

404 Not Found: The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.

405 Method Not Allowed: A request was made of a resource using a request method not supported by that resource; for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource.

406 Not Acceptable: The requested resource is only capable of generating content not acceptable according to the Accept headers sent in the request.

407 Proxy Authentication Required

408 Request Timeout: The server timed out waiting for the request.

409 Conflict: Indicates that the request could not be processed because of conflict in the request, such as an edit conflict.

410 Gone: Indicates that the resource requested is no longer available and will not be available again. This should be used when a resource has been intentionally removed; however, it is not necessary to return this code and a 404 Not Found can be issued instead. Upon receiving a 410 status code, the client should not request the resource again in the future. Clients such as search engines should remove the resource from their indexes.

411 Length Required: The request did not specify the length of its content, which is required by the requested resource.

412 Precondition Failed: The server does not meet one of the preconditions that the requestor put on the request.

413 Request Entity Too Large: The resource that was requested is too large to transmit using the current protocol.

414 Request-URI Too Long: The URI provided was too long for the server to process.

415 Unsupported Media Type: The request did not specify any media types that the server or resource supports. For example the client specified that an image resource should be served as image/svg+xml, but the server cannot find a matching version of the image.

416 Requested Range Not Satisfiable: The client has asked for a portion of the file, but the server cannot supply that portion (for example, if the client asked for a part of the file that lies beyond the end of the file).

417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field.

422 Unprocessable Entity: The request was well-formed but was unable to be followed due to semantic errors.

423 Locked: The resource that is being accessed is locked

424 Failed Dependency: The request failed due to failure of a previous request

425 Unordered Collection

426 Upgrade Required: The client should switch to TLS/1.0.449 Retry With

HTTP Status Codes : 5xx Server Error

As you must be aware that HTTP calls over the internet get different responses. Most common is 404 when you are not connected to Internet of your proxy has blocked a particular host.

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

1xx: Informational
2xx: Success
3xx: Redirection
4xx: Client Errors
5xx: Server Errors

Here we are going to talk about 5xx (Server Errors).

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. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.

So if you are a tester and get 5xx http code, you need to assign the bug to Server Team :)

500 Internal Server Error

A generic error message, given when no more specific message is suitable.

501 Not Implemented

The server either does not recognize the request method, or it lacks the ability to fulfil the request.

502 Bad Gateway

The server was acting as a gateway or proxy and received an invalid response from the upstream server.

503 Service Unavailable

The server is currently unavailable (because it is overloaded or down for maintenance). Generally, this is a temporary state.

504 Gateway Timeout

The server was acting as a gateway or proxy and did not receive a timely request from the upstream server.

505 HTTP Version Not Supported

The server does not support the HTTP protocol version used in the request.

506 Variant Also Negotiates

507 Insufficient Storage

509 Bandwidth Limit Exceeded

510 Not Extended

Further extensions to the request are required for the server to fulfill it.

How to Monitor online traffic on remotes machines on a Network?

Hi All,

For last 2-3 weeks I have been working on configuring Reverse proxy using Tomcat. I spent a lot of time and stuck at a point where my application stops working when it encounters an HTTPS request for logging in. HTTP traffic is working fine.

When checked I found that my proxy is not even getting the request.

Then I started exploring other methods through which I could monitor online traffic on different machines in my Network. I came across this solution. I have been using fiddler for debugging thing on my local machine.

Here are few basic steps:

NOTE : I have Master machine where I want to monitor the traffic.

1. Install Fiddler 2.x version on your machine. (Lower versions do not support this.)
2. Launch Fiddler on master machine
3. Go to Tools > Fiddler Options
4. Under General Tab, select the option "Allow Remote Computers to Connect"
5. Go to Start>Run
6. Type cmd : It will launch command prompt
7. Type ipconfig & Note IP address of your master machine

Now go to the machine which you want to monitor for web traffic.

1. Launch Internet Explorer
2. Go to Tools>Internet Options
3. Go to Connections Tab
4. Click "Lan Settings" button
5. Uncheck "Automatically Detect Settings"
6. Check the option "Use a Proxy Server...."
7. Click Advanced button
8. Add IP address of your master machine under 'Proxy Address to use' and port as 8888
9. Add this for HTTP & Secure
10. Click OK
11. Again click OK
12. Again click OK


Now restart Fiddler on Master machine.

On other machine enter www.google.com in internet explorer. Check what happens in Fiddler on Master machine.

YOU WILL SEE AN ENTRY FOR WWW.GOOGLE.COM

Similarly you can see other calls which are actually made on other machine. Similarly you can monitor traffic from more than one machine. Just enter IP with 8888 port in IE and you are done.

But still I am facing the same problem for HTTPS call for Log-in. I will share more details as I will get the solution.

+ VJ

Apache Tomcat

Apache Tomcat is a servlet container developed by the Apache Software Foundation (ASF). Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for Java code to run.

Tomcat should not be confused with the Apache web server, which is a C implementation of an HTTP web server; these two web servers are not bundled together. Apache Tomcat includes tools for configuration and management, but can also be configured by editing XML configuration files.

Components

Catalina

Catalina is Tomcat's servlet container. Catalina implements Sun Microsystems' specifications for servlet and JavaServer Pages (JSP).

Coyote

Coyote is Tomcat's HTTP Connector component that supports the HTTP 1.1 protocol for the web server or application container. Coyote listens for incoming connections on a specific TCP port on the server and forwards the request to the Tomcat Engine to process the request and send back a response to the requesting client.

Jasper

Jasper is Tomcat's JSP Engine. Tomcat 5.x uses Jasper 2, which is an implementation of the Sun Microsystems's JavaServer Pages 2.0 specification. Jasper parses JSP files to compile them into Java code as servlets (that can be handled by Catalina). At runtime, Jasper is able to automatically detect JSP file changes and recompile them.

Jasper 2

From Jasper to Jasper 2, important features were added :

* JSP Tag library Pooling - Each tag markup in JSP file is handled by a tag handler class. Tag handler class objects can be pooled and reused in the whole JSP servlet.
* Background JSP compilation - While recompiling modified JSP Java code, the older version is still available for server requests. The older JSP servlet is deleted once the new JSP servlet has been recompiled.
* Recompile JSP when included page changes - Pages can be inserted and included into a JSP at compile time. The JSP will not only be automatically recompiled with JSP file changes but also with included page changes.
* JDT Java compiler - Jasper 2 can use the Eclipse JDT Java compiler instead of Ant and javac.