Podcast 2: Server

Server-side development: LAMP stack (linux, apache, mysql, php), scripting languages, etc.

Systems (sys admin)

  • Linux, Windows Server 2003, BSD

Server Software (services)

  • web servers
  • database servers
  • mail servers
  • revision
  • control servers
  • *ports

Web Server Configuration

  • apache, IIS

Database (dba)

  • MySql, SQL Server, Oracle, Postgres

Server-side Scripting

  • Script runs on web server, generates dynamic web page
  • (vs client-side, which generates dynamic content in the browser)
  • CGI

Web server extension modules

  • CGI Languages: *Perl, Python, Ruby

  • Web server extension modules: *PHP, ASP, ASP.NET
  • Java servlets

Audio File: 

0 Comments

Good cast, I just wanted to

Good cast, I just wanted to add a couple notes.

First, GET requests are displayed in the url. GET requests have a limit of 100 characters. The main purpose of using the GET method is to allow users to bookmark their location with the variable values that generated the page they are seeing. GET requests should not contain sensitive information because it is displayed to the screen and in the url so various spywares can obtain this information rather easily. GET requests are typically not used with forms, usually the developer dynamically includes values for the GET variables in the href attribute of various anchor tags.

POST requests are sent in the background. They can not be bookmarked or otherwise saved. At best, the developer would have to store and recreate a form with the POST data manually. POST requests are commonly associated with forms. The idea of POST variables being more secure is an area of confusion and misconception. POST requests are more secure because they can not be obtained by spyware through stealing browser history or taking screenshots. However, anyone with experience developing HTML can make their own HTML form that mimics yours and allows them to pass invalid values. Malicious users can even develop programs that will create sockets with dynamic requests and evaluate the server's response and response time to determine weak points for future Denial Of Service attacks, or attempts to acquire sensitive information.

The point, Server Side Validation should always be done. Regardless of how you obtain the data, it is always in your best interest to have your server validate as much of the input as possible before you do your sensitive or complex computations and SQL requests from your database.