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:
|
| 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:
|
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 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 |