cis5930 internet computing l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CIS5930 Internet Computing PowerPoint Presentation
Download Presentation
CIS5930 Internet Computing

Loading in 2 Seconds...

play fullscreen
1 / 33

CIS5930 Internet Computing - PowerPoint PPT Presentation


  • 188 Views
  • Uploaded on

CIS5930 Internet Computing. HTTP Prof. Robert van Engelen. HyperText Transfer Protocol. HTTP is the World Wide Web protocol HTTP1.1 is defined by RFC2616 HTTP not just for hypertext markup (HTML) anymore

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'CIS5930 Internet Computing' - johana


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
cis5930 internet computing

CIS5930Internet Computing

HTTP

Prof. Robert van Engelen

hypertext transfer protocol
HyperText Transfer Protocol
  • HTTP is the World Wide Web protocol
  • HTTP1.1 is defined by RFC2616
    • HTTP not just for hypertext markup (HTML) anymore
    • Carries data in standard formats identified with MIME (Multipurpose Internet Mail Extensions) media types, e.g.:
      • text/html
      • image/jpeg
      • application/x-shockwave-flash
    • MIME media types are approved and assigned by IANA (Internet Assigned Number Authority)
    • HTTP message header with ASCII control messages
    • Optional HTTP message body contains data

CIS 5930 Fall 2006 - TCP/IP

hypertext over tcp ip
HyperText over TCP/IP
  • HTTP usually over TCP/IP
    • Wide area and possibly large messages: reliable communications needed
  • HTTP1.0 is transaction-based
    • Establish TCP connection
    • Client (user agent) sends HTTP request message with request URL and client info
    • Origin server sends HTTP reply message with status line and data
    • Connection is closed
  • HTTP1.1 keeps connection open by default (strict turn-taking)
    • Establish TCP connection
    • Client sends HTTP request message
    • Server sends HTTP reply message
    • Repeat 2 & 3 until session ends
    • Connection is closed

CIS 5930 Fall 2006 - TCP/IP

a single connection
A Single Connection
  • Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin server
  • Accomplished via a single connection (v) between the user agent (UA) and the origin server (O):

Request chain

UA

v

O

Response chain

CIS 5930 Fall 2006 - TCP/IP

intermediaries
Intermediaries
  • One or more intermediaries are present in the request/response chain
  • Three common forms of intermediaries
    • Proxy, gateway, and tunnel
  • Three intermediaries (A, B, C) between the user agent (UA) and the origin server (O):

Request chain

UA

O

v

A

v

B

v

C

v

Response chain

CIS 5930 Fall 2006 - TCP/IP

proxy
Proxy
  • A proxy is a forwarding agent that acts as a server and client
  • Receives requests for a URI in its absolute form
    • Multiple message exchanges may take place between requestor and proxy
  • A non-transparent proxy rewrites all or part of the message
    • May consume and remove authentication information
    • Apply protocol conversion
  • Forwards the reformatted request toward the server identified by the URI
    • Caching proxies may not forward request at all and send cached response to requestor
  • Receives response from server
  • Rewrites all or part of the message
  • Sends message to requestor

CIS 5930 Fall 2006 - TCP/IP

gateway
Gateway
  • A gateway takes the role of an origin server
  • Requestor may not be aware it is talking to a gateway
  • Acts as a layer above some other server(s)
  • May translate the requests to the underlying server's protocol

CIS 5930 Fall 2006 - TCP/IP

tunnel
Tunnel
  • A tunnel is a “dumb” forwarding agent
  • Once active, the tunnel is not considered to be part of the HTTP communication processing
  • Tunnel ceases to exist when both ends close
  • Tunnels can be useful to bypass firewalls that block all but a few standard ports
    • For example database access (ODBC/JDBC) via stunnel tool over TLS/SSL port (requires ssh deamon on server side)

CIS 5930 Fall 2006 - TCP/IP

http request message format
HTTP Request Message Format

methodrequestURI HTTP/1.1<CR><LF>

[header]*Host:domain[:port]<CR><LF>

[header]*

<CR><LF>

[body]

method:GET retrieve entity data from requestURI (body should be absent)

POST send entity (data in body) and retrieve data from requestURI

HEAD same as GET but no entity data should be returned

PUT save entity (data in body) under requestURI

DELETE delete resource associated with requestURI

domain[:port]: a domain name or IP followed by optional port number

requestURI: an absolute URI (/…) or relative URI referring to a resource

body: data content with encoding and type specified by headers

CIS 5930 Fall 2006 - TCP/IP

http request message header
HTTP Request Message Header

header:User-Agent: token/token<CR><LF>

Authorization: credentials<CR><LF>

Connection: connection<CR><LF>

header: (applies to body content or resource identified by requestURI)

Transfer-Encoding:transfer-encoding<CR><LF>

Content-Length: nnnn<CR><LF>

Content-Type: type/subtype[;parameter]*<CR><LF>

Content-Encoding: encoding<CR><LF>

connection:Keep-Alive (keep connection open, note: by default)

Close (end of session)

transfer-encoding:

Chunked (chunked, content-length must be absent)

content-encoding:

Gzip (content is compressed)

CIS 5930 Fall 2006 - TCP/IP

example http get request
Example HTTP GET Request

GET /%7Eengelen/courses/CIS5930/index.html HTTP/1.1

Host: www.cs.fsu.edu

Connection: close

Close is implicit with HTTP/1.0HTTP/1.1 requires explicit close

CIS 5930 Fall 2006 - TCP/IP

example http post request
Example HTTP POST Request

POST /demo/calculator.php HTTP/1.1

Host: www.demo.us

Content-Length: 34

Content-Type: application/x-www-form-urlencoded

Connection: close

val1=1&val2=2&op=add&submit=Submit

Form data generated by browser’s processing of forms:

<form action=“calculator.php” method=“post”>

CIS 5930 Fall 2006 - TCP/IP

http response message format
HTTP Response Message Format

HTTP/1.1 statusreason<CR><LF>

[header]*<CR><LF>

[body]

status: a numeric status code 100<status<600

1xx - informational, request received processing continues

2xx - success: request received, accepted, and processed

3xx - redirection: further action needed to complete request

4xx - client error: request message malformed

5xx - server error: server failed to process a valid request

reason: a textual description of the status

body: data content with encoding and media type specified by headers

CIS 5930 Fall 2006 - TCP/IP

common http status codes
Common HTTP Status Codes

CIS 5930 Fall 2006 - TCP/IP

example http response 1
Example HTTP Response (1)

HTTP/1.1 200 OK

Content-Length: 93

Content-Type: text/html

Connection: close

<html>

<head><title>My HomePage</title></head><body>Welcome to my home page!</body>

</html>

CIS 5930 Fall 2006 - TCP/IP

example http response 2
Example HTTP Response (2)

HTTP/1.1 404 Not Found

Content-Length: 48

Content-Type: text/html

Connection: close

<html>The information could not be found</html>

CIS 5930 Fall 2006 - TCP/IP

example http response 3
Example HTTP Response (3)

HTTP/1.1 404 Not Found

Transfer-Encoding: chunked

Content-Type: text/html

Connection: close

30

<html>The information could not be found</html>

0

Chunk length in hex followed by <CR><LF>, data, and <CR><LF>

Indicates end of data (followed by <CR><LF>)

CIS 5930 Fall 2006 - TCP/IP

persistent connections
Persistent Connections
  • Supported by some HTTP/1.0 implementations explicitly (RFC2068) and HTTP/1.1 by default, using the Connection header:Connection: keep-aliveConnection: close
  • Opens and closes fewer TCP connections
    • CPU time is saved and memory usage is lower in routers and hosts
    • Network congestion is reduced by reducing the number of packets caused by TCP opens
    • Allows sufficient time to determine the congestion state of the network
    • Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake
  • HTTP requests and responses can be pipelined on a connection
    • Pipelining allows a client to make multiple requests without waiting for each response
  • HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection

CIS 5930 Fall 2006 - TCP/IP

server access authentication
Server Access Authentication
  • Origin server may require client authentication (RFC2617)
    • For example, Apache .htaccess file
  • Client request without authentication info is rejected
    • HTTP/1.1 401 Unauthorized
    • Server includes authentication challenge header in responseWWW-Authenticate: challenge
    • The challenge is Basic or Digest followed by a comma-separated list of name=value parameters, usually one of which is realm=“name”, which is shown in the browser’s authentication dialog box for manual login
  • Client resends request with authentication info
    • Authorization: credentials
    • The credentials contain basic authentication info with user name and password (not secure!)
    • Digest authentication info contains a cryptographically hashed password

CIS 5930 Fall 2006 - TCP/IP

proxy access authentication
Proxy Access Authentication
  • Similar to server access authentication, but:
    • Proxy includes authentication challenge header to responseProxy-Authenticate: challenge
  • Client (re)sends request with authentication info
    • Proxy-Authorization: credentials
  • A browser has to be configured to include proxy authentication with each HTTP request message
    • Connection settings for HTTP proxy host (IP) and port needed

CIS 5930 Fall 2006 - TCP/IP

basic authentication
Basic Authentication
  • Authorization credentials contain UID and password encoded in base64, which is effectively plain textAuthorization: Basiccodecode = base64(UID “:” password)
  • Base64 is a common encoding format for raw data
    • Uses ASCII (7-bit) range, messages are only 33% larger
    • Splits byte stream into triples of 3 bytes (24 bits) and maps these to 4 bytes containing only 6 bits of information (4*6=24) usingA-Za-z0-9+/
  • Never use basic authentication over non-encrypted channels

CIS 5930 Fall 2006 - TCP/IP

digest authentication
Digest Authentication
  • Avoids sending password in the clear
  • Both parties know a shared secret (password)
  • Uses a common cryptographic hashing scheme to verify secret:
    • Client computes the MD5 hash of the textual concatenation of the HTTP method (GET/POST), requestURI, UID, realm, password, nonce
    • Server also computes the MD5 hash and compares it to the client’s hash value in the request message Authorization header
    • If they match, access is granted
    • Quality of protection: can also hash with body entity, to ensure integrity of entire message (qop=auth-int)
  • A nonce is used to prevent replay attacks
    • A nonce is a unique (random) value to identify a transaction
    • Nonce and nonce counts are used to prevent replay attacks
  • A man-in-the-middle only sees the hash value and cannot deduce the password

CIS 5930 Fall 2006 - TCP/IP

digest authentication example
Digest Authentication Example

Server

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Digest

realm="testrealm@host.com",

qop="auth,auth-int",

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

opaque="5ccc069c403ebaf9f0171e9517f40e41"

Client

Authorization: Digest username="Mufasa",

realm="testrealm@host.com",

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

uri="/dir/index.html",

qop=auth,

nc=00000001,

cnonce="0a4f113b",

response="6629fae49393a05397450978507c4ef1",

opaque="5ccc069c403ebaf9f0171e9517f40e41"

CIS 5930 Fall 2006 - TCP/IP

content negotiation
Content Negotiation
  • How to prevent a server from sending data in a format a user agent cannot handle?
  • User agent need indicate the content encodings and media types it accepts
  • Actually, there are two types of negotiation
    • Server-driven: server decides the best representation for a response
    • Agent-driven: client decides the representation after receiving an initial response from the server
  • These are orthogonal and may be used in combination

CIS 5930 Fall 2006 - TCP/IP

server driven content negotiation
Server-Driven Content Negotiation
  • Pro: server’s best guess often suffices
  • Cons: server may not be able to guess the best representation and user agent must describe all of its capabilities which adds message overhead
  • User-agent indicates accepted representations with HTTP headers:
    • Accept:mediaRangewhere mediaRange is a list of type/subtype[; q=x.y]example: Accept: */*example: Accept: audio/*;q=0.2, audio/basic“prefer audio/basic but send any audio type after 80% mark down in quality”example: Accept: text/plain;q=0.3, text/html
    • Accept-Charset:charsets
    • Accept-Encoding:codingswhere codings is a list of compression encodingsexample: Accept-Encoding: compress, gzip
    • Accept-Language:languageswhere languages is a list of language abbreviations, e.g. da, en-us, nl

CIS 5930 Fall 2006 - TCP/IP

state management
State Management
  • HTTP is inherently stateless
    • Persistent connections are meant to optimize for speed and can be terminated at any time
  • How to encode client state so server can deliver content based on client state when the client reconnects?
  • URL query strings: www.example.com/demo?session=123
    • But URL may be limited in size (256 bytes)
    • URLs are stored in logs, possible privacy concerns
  • Browser-based interaction: HTTP POST with HTML forms that have hidden state values
  • Cookies (RFC2965)
    • But cookies may have been disabled at the client side

CIS 5930 Fall 2006 - TCP/IP

cookies
Cookies
  • Server sends one or more Set-Cookie (or Set-Cookie2) HTTP headers to the user agent
  • Set-Cookie: name=“value”;path=“path”;domain=“domain”where domain and path are the target domain and request URL the user agent has to send cookies to
  • Domain is optional, when absent the user agent must use the server domain name
  • Path is optional, when absent the user agent must use the current request URI
  • Cookie lifetime determined by max-age=seconds
  • Upon receipt, the user agent stores the cookies in a local repository, that may be discarded then the user agent exits
  • Proxies must not set or return cookies

CIS 5930 Fall 2006 - TCP/IP

cookies cont d
Cookies (cont’d)
  • Before the user agent sends a request, it searches the repository for matching domain/path and includes all the matching cookies in the request header:Cookie: name=“value”; $path=“path”
  • Cookie domain matching by client for returning cookies:
    • Match if origin server domain name matches a domain name in repository that has leading . (dot) and tail-part of strings match
    • a.b.com matches .b.com and a.b.c.com matches .c.com
  • Cookie path matching:
    • The path of the cookie must match a prefix of the request URI
  • User agent may need to limit the number of cookies it stores
    • Should be at least 300, at least 20 per host name, and should accommodate at least 4096 bytes per cookie value

CIS 5930 Fall 2006 - TCP/IP

example
Example

1. User Agent -> Server (user identifies self via a form):POST /acme/login HTTP/1.1[form data]

2. Server -> User Agent (cookie reflects user's identity):HTTP/1.1 200 OKSet-Cookie2: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme”[data]

3. User Agent -> Server (user selects an item for "shopping basket"):POST /acme/pickitem HTTP/1.1Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme”[form data]

4. Server -> User Agent (shopping basket contains an item):HTTP/1.1 200 OKSet-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1"; Path="/acme”[data]

CIS 5930 Fall 2006 - TCP/IP

example cont d
Example (cont’d)

5. User Agent -> Server (user selects shipping method from form):POST /acme/shipping HTTP/1.1Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"; Part_Number="Rocket_Launcher_0001"; $Path="/acme”[form data]

6. Server -> User Agent (new cookie reflects shipping method):HTTP/1.1 200 OKSet-Cookie2: Shipping="FedEx"; Version="1"; Path="/acme”[data]

7. User Agent -> Server (user chooses to process order):POST /acme/process HTTP/1.1Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"; Part_Number="Rocket_Launcher_0001"; $Path="/acme"; Shipping="FedEx"; $Path="/acme”[form data]

8. Server -> User Agent (transaction is complete):HTTP/1.1 200 OK[data]

CIS 5930 Fall 2006 - TCP/IP

http upgrade header
HTTP Upgrade Header
  • When a client or server uses HTTP1.0, the other side must downgrade to HTTP1.0 as well
  • A client or server may require the other end to upgrade to another protocol, usually HTTPS (HTTP+SSL/TLS)
  • For example, client attempt to connect to a secure site but sends a clear-text request message:GET /encrypted-area HTTP/1.1Host: www.example.com
  • Server refuses, insisting that client uses HTTPS:HTTP/1.1 426 Upgrade RequiredUpgrade: TLS/1.0, HTTP/1.1Connection: Upgrade
  • Client reconnects, this time using HTTPS

CIS 5930 Fall 2006 - TCP/IP

http applications
HTTP Applications
  • Web servers and Browsers (of course) and related technologies such as RSS and Ajax
  • wget
  • HTTP virtual filesystems
  • WebDAV
  • XML Web services
  • Application servers
  • Caches (optimization)
  • Tunneling (e.g. SOCKS and Java RMI over HTTP)

CIS 5930 Fall 2006 - TCP/IP

a simple http 1 1 web server for browser based access
A Simple HTTP 1.1 Web Server for Browser-based Access
  • Must support at least:
    • GET method
  • Either support or disable:
    • To support POST method must also support chunked transfers
    • If keep-alive connection not supported: always use close response
  • For GET method header parser should extract at least
    • GET, RequestURI, and HTTP versioning info
    • Host header
  • For POST method header parser should extract at least
    • POST, RequestURI, and HTTP versioning info
    • Host header
    • Transfer-Encoding
    • Content-Length
    • Content-Type

CIS 5930 Fall 2006 - TCP/IP