Web Foundations (URI & HTTP)

Web Architecture [./]
Fall 2009 — INFO 290 (CCN 42593)

Erik WildeUC Berkeley School of Information, UC Berkeley School of Information
2009-11-03

[http://creativecommons.org/licenses/by/3.0/]

This work is licensed under a CC
Attribution 3.0 Unported License [http://creativecommons.org/licenses/by/3.0/]

Contents E. Wilde: Web Foundations (URI & HTTP)

Contents

2Abstract
3Web Server Service
1 Uniform Resource Identifier (URI)
- 5Resource Identification
- 6URI Schemes
2 Hypertext Transfer Protocol (HTTP)
- 8DNS & HTTP
- 9The Web's Protocol
- 2.1 HTTP Basics
  - 11HTTP Messages
  - 12HTTP Header Fields
  - 13HTTP Content Negotiation
  - 14HTTP Requests
  - 15HTTP GET
  - 16HTTP Responses
  - 17HTTP Performance
  - 18HTTP Connection Handling
- 2.2 HTTP Authentication
  - 20HTTP Access Control
  - 21HTTP Authentication
  - 22Basic HTTP Authentication
  - 23Repeated Access
  - 24Login Page
25Conclusions

E. Wilde: Web Foundations (URI & HTTP)

(2) Abstract

The Web's architecture has very simple principles revolving around the ideas of placing a heavy emphasis on a consistent and global identification mechanism for resources, a standardized way of how resource representations can be retrieved, and a standardized way of how resource representations should be usable by using standardized media types. Based on the Internet, the Web's transport protocol transmits representations of resources identified by a Uniform Resource Identifier (URI) between Web servers and clients. The most important protocols for data transfer on the Web is the Hypertext Transfer Protocol (HTTP).

E. Wilde: Web Foundations (URI & HTTP)

(3) Web Server Service

Web servers do more than just deliver files
They receive a request for acting on a resource
- this may be a simple file retrieval
- additional information is available from the request's header fields [HTTP Header Fields (1)]
- the request URI may contain additional query information
- the request may transmit complex data (such as a form submission)
Processing can mean anything, it is transparent for the client
- the result of processing yields a resource representation
- in many cases, a Web server is just part of an application
- the application server is the application-specific logic

Uniform Resource Identifier (URI)

Outline (Uniform Resource Identifier (URI))

Uniform Resource Identifier (URI) [2]
Hypertext Transfer Protocol (HTTP) [15]
1. HTTP Basics [8]
2. HTTP Authentication [5]

Uniform Resource Identifier (URI) E. Wilde: Web Foundations (URI & HTTP)

(5) Resource Identification

The Web is centered around resources
- HTTP has been designed to manipulate resources
- HTTP provides methods for getting, putting, updating, and even deleting resources
Resources are useful abstractions for interfaces
- instead of an API, interaction is built around manipulating resources
- APIs change and bind closely, documents can better withstand change and bind loosely
- the whole Web is built around resources, not APIs

Uniform Resource Identifier (URI) E. Wilde: Web Foundations (URI & HTTP)

(6) URI Schemes

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

http://dret.net/lectures/web-fall09/foundations#uri-schemes

URIs in their general case are very simple
- the scheme identifies how resources are identified
- the identification may be hierarchical or non-hierarchical
Many URI schemes are hierarchical
- it is then possible to use relative URIs such as in a href="../"
- the slash character is not just a character, in URIs it has semantics
Query components specify additional information
- it is non-hierarchical information further identifying the resource
- in most cases, it can be regarded as input to the resource

Hypertext Transfer Protocol (HTTP)

Outline (Hypertext Transfer Protocol (HTTP))

Uniform Resource Identifier (URI) [2]
Hypertext Transfer Protocol (HTTP) [15]
1. HTTP Basics [8]
2. HTTP Authentication [5]

Hypertext Transfer Protocol (HTTP) E. Wilde: Web Foundations (URI & HTTP)

(8) DNS & HTTP

The two basic protocols which every Web browser must implement are DNS [Internet Architecture; Domain Name System (DNS) (1)] access and HTTP [Hypertext Transfer Protocol (HTTP) (1)]. However, most operating systems provide an API for DNS access, so the browser can use this service locally and only has to implement HTTP. TCP [Internet Architecture; Transmission Control Protocol (TCP) (1)] (which is required as the foundation for HTTP) is usually provided by the operating system.

Hypertext Transfer Protocol (HTTP) E. Wilde: Web Foundations (URI & HTTP)

(9) The Web's Protocol

provided by CacheLogic Inc. [http://www.cachelogic.com/]

HTTP Basics

Outline (HTTP Basics)

Uniform Resource Identifier (URI) [2]
Hypertext Transfer Protocol (HTTP) [15]
1. HTTP Basics [8]
2. HTTP Authentication [5]

HTTP Basics E. Wilde: Web Foundations (URI & HTTP)

(11) HTTP Messages

HTTP needs a reliable connection
- the foundation for HTTP is the Transmission Control Protocol (TCP) [Internet Architecture; Transmission Control Protocol (TCP) (1)]
- DNS resolution yields an IP address
- open TCP connection to port 80 or port specified in URI (http://rosetta.ischool.berkeley.edu:8085/)
HTTP is a text-based protocol
- the connection is used to transmit text messages
- all HTTP messages are human-readable (not all entities, though)
- basic HTTP operations can be carried out by hand

start-line
message-header *

message-body ?

HTTP Basics E. Wilde: Web Foundations (URI & HTTP)

(12) HTTP Header Fields

Header fields contain information about the message
- general header: Date as the message origination date
- request header: Accept-Language indicates language preferences
- response header: Server contains system information
- entity header: Content-Type specifies the media type of the entity
HTTP defines a number of header fields [http://www.cs.tut.fi/~jkorpela/http.html]
- unknown fields must be ignored (extensibility)
- unstandardized fields should use a X- prefix
HTTP is about acting on these fields
- HTTP defines what HTTP implementations must or should do

HTTP Basics E. Wilde: Web Foundations (URI & HTTP)

(13) HTTP Content Negotiation

HTTP Header Fields [HTTP Header Fields (1)] have interaction semantics
- depending on the header type they convey different information
HTTP Content Negotiation [http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html] allows representation negotiation
- the client specifies a number of preferred content properties
- the server responds with the representation that fits best
Server-driven negotiation can use a number of request header fields
- Accept uses a list of Media Types [Media Types]
- Accept-Charset uses a list of character sets
- Accept-Encoding uses a list of content encodings
- Accept-Language uses a list of language codes
- User-Agent specifies the client's identification
Client-driven negotiation lets the server send a list of URIs
- two steps are required to get the best alternate representation

HTTP Basics E. Wilde: Web Foundations (URI & HTTP)

(14) HTTP Requests

After opening a connection, the client sends a request
- the method indicates the action to be performed on the resource
- HTTP's most interesting methods are: GET, HEAD, POST
- other interesting methods are: PUT, DELETE
The URI identifies the resource to which the request should be applied
- absolute URIs are required when contacting proxies
- absolute paths are required when contacting a server directly
- the URI may contain query information
The Host header field must be included in every request

Method Request-URI HTTP/Major.Minor
[Header]*

[Entity]?

HTTP Basics E. Wilde: Web Foundations (URI & HTTP)

(15) HTTP GET

Retrieval action based on the URI
- maybe implemented by reading a file
- maybe implemented by processing a file (PHP)
- maybe implemented by invoking a process
Semantics may change based on header fields
- If-*: only reply with the entity if necessary
- Range: only reply with the requested part of the entity
Cacheability depends on header fields of the response

GET / HTTP/1.1
Host: ischool.berkeley.edu

HTTP Basics E. Wilde: Web Foundations (URI & HTTP)

(16) HTTP Responses

The server's response to interpreting a request
- the status code is given numerically and as text
- 2** for variations of ok
- 3** for redirections
- 4** are different client side problems (404: not found)
- 5** are different server side problems
Header fields specify additional information
- information about the server
- information about the entity (media type, encoding, language)

HTTP/Major.Minor Status-Code Text
[Header]*

[Entity]?

HTTP Basics E. Wilde: Web Foundations (URI & HTTP)

(17) HTTP Performance

HTTP/1.0 allowed one transaction per connection
- TCP connection setup and teardown are expensive
- TCP's slow start slows down the initial phase of data transfer
- typical Web pages use between 10-20 resources (HTML + images + CSS + scripts)
- typically, these resources are stored on the same server
HTTP/1.1 introduces persistent connections
- the TCP connection stays open for some time (10 sec is a popular choice)
- additional requests to the same server use the same TCP connection
HTTP/1.1 introduces pipelined connections
- instead of waiting for a response, requests can be queued
- the server responds as fast as possible
- the order may not be changed (there is no sequence number)

HTTP Basics E. Wilde: Web Foundations (URI & HTTP)

(18) HTTP Connection Handling

HTTP Authentication

Outline (HTTP Authentication)

Uniform Resource Identifier (URI) [2]
Hypertext Transfer Protocol (HTTP) [15]
1. HTTP Basics [8]
2. HTTP Authentication [5]

HTTP Authentication E. Wilde: Web Foundations (URI & HTTP)

(20) HTTP Access Control

HTTP servers can deny access [http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error] through access control
- 401 Unauthorized means the resource is access controlled
- 403 Forbidden means the resource is inaccessible
- 405 Method Not Allowed signals a request using the wrong request method [HTTP Requests (1)]
Two different approaches to unauthorized access are possible
- repeat the HTTP request with the proper authentication credentials
- redirect to a Login Page [Login Page (1)] and establish an authenticated Session [State Management; Session (1)]

HTTP Authentication E. Wilde: Web Foundations (URI & HTTP)

(21) HTTP Authentication

HTTP Authentication

HTTP Authentication E. Wilde: Web Foundations (URI & HTTP)

(22) Basic HTTP Authentication

Authentication is based on authentication realms
- a set of resources for which the authentication is required
- an opaque name which is used to signal which login is required
- username/password often is specific for a given realm
Users supply username and password through the client
- sent as Base64 [http://en.wikipedia.org/wiki/Base64] encoded username:password string
- username and password are not transmitted securely [http://www.google.com/search?hl=en&q=base64+decoder]
- basic authentication should always use HTTPS [Security & Privacy; HTTP over SSL (HTTPS) (1)]
Authorization is handled on the server side
```
HTTP/1.0 401 Unauthorized
	WWW-Authenticate: Basic realm="SokEvo"
```
[http://en.wikipedia.org/wiki/Basic_access_authentication]
```
GET /private/index.html HTTP/1.0
	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
```
[http://en.wikipedia.org/wiki/Basic_access_authentication]

HTTP Authentication E. Wilde: Web Foundations (URI & HTTP)

(23) Repeated Access

Clients typically access more than one protected resource
- a perfectly stateless client would always request authentication from the user
- using the realm clients can identify repeated accesses
Web interactions by default are perfectly stateless
- each request is completely independent from other requests
- stateless interactions make the Web loosely coupled and scalable
- concepts like the realm or Cookies [State Management; Cookies (1)] introduce state
Clients remember the authentication and replay it automatically
- browsers provide little control over this feature
- logging out of HTTP authenticated sessions is hard

HTTP Authentication E. Wilde: Web Foundations (URI & HTTP)

(24) Login Page

Basic HTTP Authentication [Basic HTTP Authentication (1)] works with browser controls (including the window)
- no possibility to log out without using browser-specific controls
- client side security depends on browser security measures
Using HTML Forms [HTML Forms] gives more freedom in session management
- Authentication [Security & Privacy; Authentication (1)] and Authorization [Security & Privacy; Authorization (1)] are completely application-based
- if there were secure personal browsers this would not work very well

E. Wilde: Web Foundations (URI & HTTP)

(25) Conclusions

HTTP is much more than file transfer
- it is a protocol for the concept of resource manipulation
- it is a distinct step away from the API approach to building distributed systems
HTTP servers can be configured to deliver good or bad service
- this is a question of how well they are configured on the HTTP level
- it is also a question of how good the Web design is
- both issues together are required to set up a good Web server

2009-11-03 Web Architecture [./]
Fall 2009 — INFO 290 (CCN 42593)