Introduction to Web Development

The Internet and the Web

The internet and the Web are two distinct things, although the two are often used synonymously. The internet is a massive network of networks. It is the physical infrastructure that connects users together. This physical infrastructure includes switches, routers and satellite links (to name a few). The internet is a global network that allows any computer on the network to communicate with any other computer. The Web is a way of accessing information that is stored on devices connected to the internet. It is a set of protocols and services that make sharing information easy. For the case of HTML documents, the protocol used is HTTP. This protocol facilitates the requesting of resources stored on devices connected to the internet. HTML supports the linking of documents. One HTML document will link to another and in turn will point to another. This linking structure gives rise to the name "the Web". The structure of the Web can be likened to a spiders web, a huge collection of documents connected together by strands of silk.

While most of the general public primarily use the internet to browse web pages, there is much more to the internet than just the Web. The internet is used to transfer research data, to synchronise clocks, to stream video and audio, and more. In general the internet can be used for any task which involves the communication of data from one computer to another.

The architecture of the internet

As mentioned before, the internet is the physical infrastructure that facilitates the transfer of data from one computer to another. Although this module does not intend to teach networking, it is essential to have a fundamental understanding to be able to understand how the Web works. The internet is made up of links, switching and routing infrastructure and computers. The links that make up the internet can take many different forms. Some are copper - using electric signals, some are glass (fibre optic) - using light, and some use electromagnetic radiation to transfer data. Although the medium used by these links is different, their purpose is the same: to transport data from one endpoint to the next. The endpoints of these links are either computers or switching and routing infrastructures. Let us consider the purpose of switching and routing infrastructure. The transmission of data on the internet can be likened to sending a letter through the post. A message gets written and gets an address written on the envelope. The letter is then posted and enters the mail system. The messages is sent through a series of post offices, and at each step the letter gets closer to its destination. At the post office the letter gets sorted and forwarded to the next post office until eventually the post office can deliver it to the door of the recipient. In this analogy the letter is the packet of data: the roads that carry the letters between post offices are the links, the post offices are switches and routers and the sender and receiver of the letter are computers.

The architecture of the Web

The Web is the interconnected collection of documents available on the internet. The Web is made up of individual web pages which 'cluster' together to form web sites. Between pages there are links which allow users to navigate the web of documents. The type of the documents linked to in the web can be anything. Usually these documents are HTML documents which contain links to other documents. The Web has evolved since its conception, but the principles are mostly the same.

The web uses a client-server model. That is, there are computers on the internet whose sole task is to serve webpages that are requested by other computers. A computer on the internet that serves webpages is called a web server. A machine that requests pages from a web server is called a client, more specifically we refer to the specific application that is running on the client that makes the request for webpages as a web browser. The responsibility of a web browser is to request webpages from the server and to display them for the user. There are also automated clients that request webpages that will not be displayed to users - these are called bots. The purpose of such bots is to perform data mining or indexing.

A history of HTML

As mentioned in the previous section the internet is distinct from the web. Before HTML and the web there was the internet. The internet was originally designed as a defence network to send information between military command centers. The use of the internet was restricted to government agencies and research institutes. In 1969 the internet was open up and universities and other authorised used were able to connect devices together. In 1990 Tim Berners-Lee, while working at CERN, proposed a document that described a way of connecting documents together. This document outlined the foundation of the World wide Web. Along with the proposal Tim -Berners-Lee defined a language for describing these documents and outlined how they should be managed collaboratively. This language was HyperText Markup Language (HTML). When the World Wide Web was proposed the philosophy of the web was very different to the web today. The intent was to have a web of documents that would be edited by anyone, this could be compared to Wiki's. In some ways Wiki's are the closest thing we have that captures the original philosophy of the web, however, the means by which Wiki's achieve this ideal is very different. The developement of HTML is an evolutionary one, mostly different by developers. The evolution is then standardised by a range of different bodies. HTML was not the first of its kind, before HTML there existed a description language called Standard Generalised Markup Language (SGML) which used a similar format to HTML. The first official standard for HTML was HTML version 2, which was written by the Internet Engineering Task Force (IETF). The IETF was later superceeded by the World Wide Web Consortium (W3C). The W3C continued to standardise features into the HTML language which developers had been using. This was until the W3C shifted their focus on to Extensible HyperText Markup Language (XHTML), which was a step towards converting HTML into Extensible Markup Language. This transistion however was not smooth with many of the popular browsers of the time refusing to implement XHTML. While the W3c toiled to encourage the adoption of XHTML a separate group was setup called the Web HyperText Application Technology Working Group (WHATWG). The internal structure of these two groups was slightly different and these differences allowed the WHATWG to move quickly to standardise new features which was essential in the rapidly developing World Wide Web. In 2009 the W3C publicly dropped he development of XHTML and joined forces with the WHATWG to develop HTML5. 


Version Year Documentation
HTML 1991
HTML 2.0 1995 RFC1866
HTML 3.2 1997 HTML 3.2
HTML 4 1998 HTML 4.0
HTML 4.01 1999 HTML 4.01
XHTML 2000 XHTML 1
HTML5 2014 HTML 5
HTML5.1 2015 HTML 5.1

HTTP protocol

The hyper text transfer protocol (HTTP) is an application protocol for sharing and editing documents on the Web. HTTP is the fundamental protocol used on the Web for sharing and editing. The initial definition of the HTTP was released in 1997 rfc2068. The developement of the HTTP standard was orchestrated by the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C). The HTTP defines the means of how a client can request a resource from a web server. The HTTP is a request-response protocol - that is, the client requests a resource and the server responds with the resource. It is always the client that initiates the communication. HTTP supports a number of different actions, each action performs a specific task. The action is communicated to the server via a HTTP verb.

HTTP verbs

The verbs are GET, POST, PUT, DELETE, HEAD, TRACE, OPTIONS, CONNECT and PATCH. A breif outline of each of the verbs is provided below.

Verb Action
GET

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 the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.

POST

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

  • Annotation of existing resources;
  • Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles
  • Providing a block of data, such as the result of submitting a form, to a data-handling process;
  • Extending a database through an append operation.

PUT

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

DELETE

The DELETE method requests that the origin server delete the resource identified by the Request-URI.

HEAD

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.

TRACE

The TRACE method is used to invoke a remote, application-layer loop- back of the request message.

OPTION

The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

CONNECT

This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel.

PATCH

The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request- URI.

HTTP response code

When an HTTP request is made to a server the server will reply with a response. The response may contain a body but it will always contain a response code. The response code communicates information about the response. In general there are five types of response codes returned by a web server; Informational, Success, Redirection, Client request errors and Server errors.

Status code Status text Description HTTP version
Informational responses
100 Continue This interim response indicates that everything so far is OK and that the client should continue with the request or ignore it if it is already finished. HTTP/1.1 only
101 Switching Protocol This code is sent in response to an Upgrade: request header by the client, and indicates that the protocol the server is switching too. It was introduced to allow migration to an incompatible protocol version, and is not in common use. HTTP/1.1 only
Successful responses
200

OK

The request has succeeded. The meaning of a success varies depending on the HTTP method:
  • GET: The resource has been fetched and is transmitted in the message body.
  • HEAD: The entity headers are in the message body.
  • POST: The resource describing the result of the action is transmitted in the message body.
  • TRACE: The message body contains the request message as received by the server
HTTP/0.9 and later
201 Created The request has succeeded and a new resource has been created as a result of it. This is typically the response sent after a PUT request. HTTP/0.9 and later
202 Accepted The request has been received but not yet acted upon. It is non-committal, meaning that there is no way in HTTP to later send an asynchronous response indicating the outcome of processing the request. It is intended for cases where another process or server handles the request, or for batch processing. HTTP/0.9 and later
203 Non-Authoritative Information This response code means returned meta-information set is not exact set as available from the origin server, but collected from a local or a third party copy. Except this condition, 200 OK response should be preferred instead of this response. HTTP/0.9 and 1.1
204 No Content There is no content to send for this request, but the headers may be useful. The user-agent may update its cached headers for this resource with the new ones. HTTP/0.9 and later
205 Reset Content This response code is sent after accomplishing request to tell user agent reset document view which sent this request. HTTP/1.1 only
206 Partial Content This response code is used because of range header sent by the client to separate download into multiple streams. HTTP/1.1 only
Redirection messages
300 Multiple Choice The request has more than one possible responses. User-agent or user should choose one of them. There is no standardized way to choose one of the responses. HTTP/1.0 and later
301 Moved Permanently This response code means that URI of requested resource has been changed. Probably, new URI would be given in the response. HTTP/0.9 and later
302 Found This response code means that URI of requested resource has been changed temporarily. New changes in the URI might be made in the future. Therefore, this same URI should be used by the client in future requests. HTTP/0.9 and later
303 See Other Server sent this response to directing client to get requested resource to another URI with an GET request. HTTP/0.9 and 1.1
304 Not Modified This is used for caching purposes. It is telling to client that response has not been modified. So, client can continue to use same cached version of response. HTTP/0.9 and later
305 Use Proxy This means requested response must be accessed by a proxy. This response code is not largely supported because security reasons. HTTP/1.1 only
306 unused This response code is no longer used, it is just reserved currently. It was used in a previous version of the HTTP 1.1 specification. HTTP/1.1 only
307 Temporary Redirect Server sent this response to directing client to get requested resource to another URI with same method that used prior request. This has the same semantic than the 302 Found HTTP response code, with the exception that the user agent must not change the HTTP method used: if a POST was used in the first request, a POST must be used in the second request. HTTP/1.1 only
308 Permanent Redirect

This means that the resource is now permanently located at another URI, specified by the Location: HTTP Response header. This has the same semantics as the 301 Moved Permanently HTTP response code, with the exception that the user agent must not change the HTTP method used: if a POST was used in the first request, a POST must be used in the second request.

Note: This is an experimental response code whose specification is currently in draft form.
draft-reschke-http-status-308
Client error responses
400 Bad Request This response means that server could not understand the request due to invalid syntax. HTTP/0.9 and later
401 Unauthorized Authentication is needed to get requested response. This is similar to 403, but in this case, authentication is possible. HTTP/0.9 and later
402 Payment Required This response code is reserved for future use. Initial aim for creating this code was using it for digital payment systems however this is not used currently. HTTP/0.9 and 1.1
403 Forbidden Client does not have access rights to the content so server is rejecting to give proper response. HTTP/0.9 and later
404 Not Found Server can not find requested resource. This response code probably is most famous one due to its frequency to occur in web. HTTP/0.9 and later
405 Method Not Allowed The request method is known by the server but has been disabled and cannot be used. The two mandatory methods, GET and HEAD, must never be disabled and should not return this error code. HTTP/1.1 only
406 Not Acceptable This response is sent when the web server, after performing server-driven content negotiation, doesn't find any content following the criteria given by the user agent. HTTP/1.1 only
407 Proxy Authentication Required This is similar to 401 but authentication is needed to be done by a proxy. HTTP/1.1 only
408 Request Timeout This response is sent on an idle connection by some servers, even without any previous request by the client. It means that the server would like to shut down this unused connection. This response is used much more since some browsers, like Chrome or IE9, use HTTP preconnection mechanisms to speed up surfing. Also note that some servers merely shut down the connection without sending this message. HTTP/1.1 only
409 Conflict This response would be sent when a request conflict with current state of server. HTTP/1.1 only
410 Gone This response would be sent when requested content has been deleted from server. HTTP/1.1 only
411 Length Required Server rejected the request because the Content-Length header field is not defined and the server requires it. HTTP/1.1 only
412 Precondition Failed The client has indicated preconditions in its headers which the server does not meet. HTTP/1.1 only
413 Payload Too Large Request entity is larger than limits defined by server; the server might close the connection or return an Retry-After header field. HTTP/1.1 only
414 URI Too Long The URI requested by the client is longer than the server is willing to interpret. HTTP/1.1 only
415 Unsupported Media Type The media format of the requested data is not supported by the server, so the server is rejecting the request. HTTP/1.1 only
416 Requested Range Not Satisfiable The range specified by the Range header field in the request can't be fulfilled; it's possible that the range is outside the size of the target URI's data. HTTP/1.1 only
417 Expectation Failed This response code means the expectation indicated by the Expect request header field can't be met by the server. HTTP/1.1 only
418 I'm a teapot Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. HTCPCP/1.0
421 Misdirected Request The request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI. HTTP/2.0
426 Upgrade Required The server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s). HTTP/1.1 and newer
428 Precondition Required The origin server requires the request to be conditional. Intended to prevent "the 'lost update' problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict." HTTP/1.1 and newer
429 Too Many Requests The user has sent too many requests in a given amount of time ("rate limiting"). HTTP/1.1 and newer
431 Request Header Fields Too Large The server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields. HTTP/1.1 and newer
Server error responses
500 Internal Server Error The server has encountered a situation it doesn't know how to handle. HTTP/0.9 and later
501 Not Implemented The request method is not supported by the server and cannot be handled. The only methods that servers are required to support (and therefore that must not return this code) are GET and HEAD. HTTP/0.9 and later
502 Bad Gateway This error response means that the server, while working as a gateway to get a response needed to handle the request, got an invalid response. HTTP/0.9 and later
503 Service Unavailable The server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded. Note that together with this response, a user-friendly page explaining the problem should be sent. This responses should be used for temporary conditions and the Retry-After: HTTP header should, if possible, contain the estimated time before the recovery of the service. The webmaster must also take care about the caching-related headers that are sent along with this response, as these temporary condition responses should usually not be cached. HTTP/0.9 and later
504 Gateway Timeout This error response is given when the server is acting as a gateway and cannot get a response in time. HTTP/1.1 only
505 HTTP Version Not Supported The HTTP version used in the request is not supported by the server. HTTP/1.1 only
506 Variant Also Negotiates The server has an internal configuration error: transparent content negotiation for the request results in a circular reference. HTTP/1.1
507 Variant Also Negotiates The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process. HTTP/1.1
511 Network Authentication Required The 511 status code indicates that the client needs to authenticate to gain network access. HTTP/1.1