How Web Servers Work - HTML

A Web server is a patient program that sits on your server (that is, the physical machine dedicated to serving pages and performing other server functions) waiting to receive an HTTP request via TCP/IP.

Any server configured to handle communications via TCP/IP (the Internet’s communications protocol) has ports. These aren’t physical ports, like the serial port and parallel ports on the back of your computer, but they serve the same purpose. All HTTP requests come through port 80 unless the server has been configured differently. Port 80 is the default Web server port. This is how your server, which may be a file server, an applications server, and an FTP server, in addition to being a Web server, keeps it all straight.

When an HTTP request comes through port 80 to the Web server the Web server finds the page requested, checks the permissions of the client making the request, and, if the client has the appropriate permission, serves the page.

The client requests the page. Then the server evaluates the request and serves the page or an error message.

The client requests the page. Then the server evaluates the request and serves the page or an error message

Generally, HTTP requests are anonymous. What this really means is an account has been created on the Web server for HTTP requests. When a request comes through port 80, it is assumed to come from this account. Each file on the Web server has certain permissions associated with it. If the HTTP account has adequate permission to read that page, and the page isn’t otherwise protected, the Web server will serve that page.

Server-side scripting fills many gaps and can be used for the following purposes:

  • Intelligent” page generation. The contents of a page can be determined by the user—via previously established preferences, database queries, and so on.
  • Form verification and handling. You have learned how JavaScript can be used to do basic form validation. However, using server-side scripts the form data can be validated at a much more detailed level—data verified against database content, run through credit card processors, and so on.
  • Dynamic page generation. Because most server-side scripting languages can interface with databases, generating dynamic content is fairly easy using server-side scripting. You can run server-side scripts via several different methods:
  • They can be run by specifying the script in a standard URL format, such as www.example.com/dosomething.cgi.
  • They can be called from another script or static page by using a form action:
  • <form action=“validate.cgi” method=“POST”>
  • They can be called from another script or static page by using a link:
  • The results of the survey can be found
  • <a href=“results.cgi”>here</a>.

In any case, the Web server must know how to handle server-side script requests—calling a CGI page (for example, validate.cgi) via any method will only cause an error in the server unless it knows how to process the request. In the case of most server-side scripts, the Web server simply turns over processing of the script to an interpreter or the operating system. The script is executed in a separate environment, able to draw upon other resources but still have its output sent to the HTTP client.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

HTML Topics