slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Back to Cookies! PowerPoint Presentation
Download Presentation
Back to Cookies!

Loading in 2 Seconds...

play fullscreen
1 / 47

Back to Cookies! - PowerPoint PPT Presentation


  • 321 Views
  • Uploaded on

Back to Cookies! “Cookies” Invented by Netscape, included in Netscape version 0.9 β (September, 1994) Patent applied for in 1995, granted 1998. Quote from original Netscape publication: “The state object is called a cookie , for no compelling reason.”

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 'Back to Cookies!' - sherlock_clovis


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
slide2

“Cookies”

Invented by Netscape, included in Netscape version 0.9β (September, 1994)

Patent applied for in 1995, granted 1998.

Quote from original Netscape publication:

“The state object is called a cookie, for no compelling reason.”

Formalized in RFC 2109, February, 1997, which has minor differences from the original Netscape proposal.

slide4

RFC 2109 HTTP State Management Mechanism - continued

2. TERMINOLOGY

► client – an application program that establishes connections for the purpose of sending requests

(could be a proxy)

► user agent – the client that initiates a request, usually a browser.

► server

► proxy

► origin server – the server on which a given resource resides.

► fully-qualified domain name (FQDN)

slide5

2. TERMINOLOGY - continued

► request-host

► request-URI (Universal Resource Identifier)

www.mylab.org/cgi-bin/sampleform

request-host request-URI

URL:

slide6

2. TERMINOLOGY - continued

► domain-match

Host A’s name domain-matches host B’s if

► their names or IP addresses match exactly

► A is a FDQN string and has the form NB,

where N is a non-empty string, B has the form .B́

and B́ is a FQDN

Examples:

► www.amazon.com domain matches .amazon.com

N

B

► www.amazon.com does not domain-match amazon.com

slide7

RFC 2109 HTTP State Management Mechanism

  • Abstract
  • 2. Terminology
  • 3. State and Sessions
slide8

3. STATE AND SESSIONS

Definition of session

1. Each session has a beginning and an end.

2. Each session is relatively short-lived.

3. Session is started by the origin server

4. Either the user-agent or the origin server may terminate a session

5. The session is implicit in the exchange of state information

(there is no special message to start or stop a session).

Informally: a session might include access to a catalog, selection of purchase items into a shopping cart, checkout, and acknowledgement of purchase.

An HTTP session may contain several TCP sessions

slide9

RFC 2109 HTTP State Management Mechanism

  • Abstract
  • 2. Terminology
  • 3. State and Sessions
  • 4. Outline
  • 4.1 Syntax
  • 4.2 Origin Server Role
  • 4.3 User Agent Role
slide10

4. OUTLINE

Origin server sends state information (cookie) to the user agent

User agent returns state information to origin server.

The goal is to have minimal impact on HTTP (i.e. an add-on to HTTP)

Impact will be confined to Common Gateway Interface (CGI) programs.

4.1 Syntax: General

Let’s learn it as we go along!

slide11

4.2 Origin Server Role

4.2.1 General

The origin server (surprising!) initiates a session, if it so desires.

To initiate a session, the origin server returns an extra response header to the client,

Set-Cookie

Servers may return a Set-Cookie header with any response

(not necessarily every response).

The origin server may include multiple Set-Cookie headers in a response.

A user agent returns a Cookie request header to the origin server

(if the user agent chooses to continue the session).

User agents should send Cookie request headers (subject to other rules detailed below) with every request.

slide12

4. OUTLINE – continued

4.2.2 Set-Cookie Syntax

At least one cookie

Zero or more attribute-value pairs

Netscape version had “expires”

If “Version” missing, defaults to Netscape

slide13

Example: Wireshark trace of response to user keying in www.amazon.com (from Lab session 8)

Hypertext Transfer Protocol

HTTP/1.1 302\r\n Response Code: 302

Date: Fri, 08 Oct 2004 18:24:09 GMT\r\n

Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix) amarewrite/0.1 mod_fastcgi/2.2.12\r\n

Set-Cookie: session-id-time=1097827200;

path=/; domain= .amazon.com; expires=Friday, 15-Oct-2004 08:00:00 GMT\r\n

Set-Cookie: session-id=103-3915387-7090229;

path=/;

domain= .amazon.com; expires=Friday, 15-Oct-2004 08:00:00 GMT\r\n

Location: http://www.amazon.com/exec/obidos/subst/home/home.html/103- 3915387-7090229\r\n

Connection: close\r\n

Transfer-Encoding: chunked\r\n

Content-Type: text/html\r\n

\r\n

Netscape version “version” missing

slide14

4. OUTLINE - continued

4.3 User Agent Role

4.3.1 Interpreting the Set-Cookie

The user agent keeps separate track of state information that arrives via Set-Cookie response headers from each origin server.

The user agent applies these defaults for optional attributes that are missing:

► Version – defaults to “old cookie” behavior as originally

specified by Netscape.

► Domain – defaults to the request-host.

► Max-Age – the default behavior is to discard the cookie

when the user-agent exits.

► Path – defaults to the path of the request URL that generated

the Set-Cookie response.

slide15

4. OUTLINE – continued

4.3 User Agent Role – continued

4.3.4 Sending Cookies to the Origin server

When the user agent sends a request to an origin server, the user agent includes a Cookie request header if it has applicable cookies, based on:

► the request-host (defined earlier) – Domain Selection

AND

► the request URI (defined earlier) – Path Selection

AND

► the cookie’s age – Max-Age selection

www.mylab.org/cgi-bin/sampleform

request-host request-URI

slide16

4. OUTLINE – continued

4.3.4 Sending Cookies to the Origin Server - continued

Domain selection:

The origin server’s FQDN must domain-match the domain attribute of the cookie

slide17

4. OUTLINE – continued

4.3.4 Sending Cookies to the Origin Server - continued

Path Selection:

The path attribute of the cookie must match a prefix of the request-URI

slide18

4. OUTLINE – continued

4.3.4 Sending Cookies to the Origin Server - continued

Max-Age Selection:

Cookies that have expired should have been discarded and not sent.

slide19

RFC 2109 HTTP State Management Mechanism

  • Abstract
  • 2. Terminology
  • 3. State and Sessions
  • 4. Outline
  • 4.1 Syntax
  • 4.2 Origin Server Role
  • 4.3 User Agent Role
  • 5.Examples
slide20

Example: Wireshark trace of response to user keying in www.amazon.com (from Lab session 8)

Hypertext Transfer Protocol

HTTP/1.1 302\r\n Response Code: 302

Date: Fri, 08 Oct 2004 18:24:09 GMT\r\n

Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix) amarewrite/0.1 mod_fastcgi/2.2.12\r\n

Set-Cookie: session-id-time=1097827200;

path=/; domain= .amazon.com; expires=Friday, 15-Oct-2004 08:00:00 GMT\r\n

Set-Cookie: session-id=103-3915387-7090229;

path=/;

domain= .amazon.com; expires=Friday, 15-Oct-2004 08:00:00 GMT\r\n

Location: http://www.amazon.com/exec/obidos/subst/home/home.html/103- 3915387-7090229\r\n

Connection: close\r\n

Transfer-Encoding: chunked\r\n

Content-Type: text/html\r\n

\r\n

www.amazon.com domain-matches this

Netscape version “version” missing

slide21

trace of next HTTP message client to server www.amazon.com(www.amazon.com domain-matches .amazon.com)

slide22

Server sends “customer” form

User completes form and clicks “submit”

Form data

Server starts HTTP session with Set-Cookie

Server sends “merchandise” form

Consequence of clicking “submit” button

Client returns “customer” cookie

slide23

Server sends “shipping” form

User selects “FedEX” and clicks “submit”

Client sends both cookies

Server sends checkout form

slide24

User could still abort purchase but chooses to proceed

User clicks on “submit” button

Client sends all three cookies

Form data

K

Server sends order acknowledgement

slide25

Background to Chapter 9 - Classless and Subnet Address Extensions (CIDR)

and Chapter 31 – A Next-Generation IP

There are 232 possible IPv4 addresses.

When the predecessor of the Internet started in the 1970s it did not seem possible that this address space would ever be exhausted.

No effort was made to allocate IP addresses carefully.

In particular:

● The classful addressing system is wasteful

(224 addresses to MIT)

● Every physical network had to have a unique network prefix

● Network prefixes were not allocated geographically

(example – 138.26.0.0 is UAB

138.25.0.0 is in Australia)

slide26

Comer: “In the early 1980s, as Ethernet gained popularity, it became apparent that the classful addressing scheme would have insufficient network addresses, especially class B prefixes.”

1985: Subnetting allowed organizations to share a single network prefix over multiple physical networks, which helped conserve the IPv4 address space (Comer, Chapter 9A).

1993: Shortage of IPv4 network addresses threatens, especially class B.

Some geographical allocation of class-C addresses

Supernetting/CIDR comes to the rescue, superseding “classfull” addressing (Comer, Chapter 9B).

Present situation:

● The IPv4 address space is “really” near exhaustion

● Forwarding tables in the Internet backbone are very large

(200,000 entries).

2010? Large-scale adoption of IPv6 (Comer Chapter 31).

slide27

Recall:

Figure 4.1

Figure 9.3

Subnetting class B network

slide28

9.16 Classless Addressing and Supernetting

Under the original “classful” addressing system IPv4 address space was becoming exhausted.

The rigid class scheme made allocation of IP addresses inefficient.

Subnet addressing (1987) helped, but problem remained.

“Temporary” solution (1993) was to abandon classes completely and let the network prefix be any length.

We already had the ability to do this, in the address mask!

This is called classless IP addressing, or supernetting.

slide29

9.16 Classless Addressing and Supernetting - continued

Example:

Organization wants a class-B network address – none available.

256 class-C addresses would have the same total number of addresses.

Problem:

Outsiders would need 256 entries in their routing tables, instead of one

(contrast subnetting, which is invisible to outsiders).

Solution:

Classless Inter-Domain Routingaggregates 256 contiguous class-C networks together by carrying along a netmask of 255.255.0.0

(“treat these 256 contiguous class-C networks like a class-B network”)

The network address is never mentioned without also stating the netmask.

Problem with implementation of this: software on all external routers had to be modified.

slide30

9.17 CIDR Address Blocks and Bit Masks

The netmask 255.255.0.0 is just one example.

The division between the network part and the host part of the IP address can be placed (almost) anywhere by an appropriate address mask.

CIDR notation:

State number of bits in network part.

e.g. address mask 255.255.255.0 is CIDR /24

slide31

9.17 CIDR Address Blocks and Bit Masks – continued

The revised forwarding algorithm remains unchanged, but is now used both internally and externally.

Figure 9.7

slide32

9.17 CIDR Address Blocks and Bit Masks – continued

CIDR allows allocation of different sizes of address blocks.

It was introduced in the context of privatization of the Internet, which also introduced Internet Service Providers (ISPs).

Using CIDR, large ISPs are allocated large address blocks, which they can then divide (using CIDR) into smaller blocks to allocate to their customers.

slide33

9.17 CIDR Address Blocks and Bit Masks – continued

Example:

Organization is assigned a block of 2048 addresses, based on 128.211.168.0

(notice ambiguous class – under classful system 128.211 is class-B

64K addresses)

Block size is 211 addresses, which would have been 8 class C networks.

Netmask for this block is

11111111 11111111 11111000 00000000

255 . 255 . 248 . 0

CIDR /21

Refer to this allocation as 128.211.168.0 /21

slide35

9.18 Address Blocks and CIDR Notation

Possible address masks:

Class C

Class A

Class B

/31 and /32 useless!

Figure 9.10

slide36

9.19 A Classless Addressing Example

A large ISP has been allocated the entire class-B address 128.211.0.0

i.e. 128.211.0.0 /16

Large ISP has allocated the address block shown previously to a smaller ISP,

i.e. 128.211.168.0 /21

128.211.10101000.00000000

So smaller ISP has available

128.211.168.0

128.211.169.0

128.211.170.0

128.211.171.0

128.211.172.0

128.211.173.0

128.211.174.0

128.211.175.0

slide37

9.19 A Classless Addressing Example - continued

128.211.168.0 /21

Expands to:

3rd octet 4th octet

128.211.168.0 10101 000 00000000

128.211.169.0 10101 001

128.211.170.0 10101 010

128.211.171.0 10101 011

128.211.172.0 10101 100

128.211.173.0 10101 101

128.211.174.0 10101 110

128.211.175.0 10101 111

128.211.168.0/22

128.211.172.0/23

/24

/24

slide38

Smaller ISP has been allocated 128.211.168.0/21 Can allocate partitions to customers:

256 addresses

128.211.175.0/24

256 addresses

128.211.174.0/24

1024 addresses

128.211.168.0/22

512 addresses

128.211.172.0/23

The smaller ISP could further partition 128.211.175.0/24

slide39

9.19 A Classless Addressing Example - continued

An ISP owning 128.211.0.0/16 might assign an individual needing only two IP addresses

128.211.176.212 /30

Figure 9.11

The two IP usable addresses are:

128.211.176.213

and 128.211.176.214

slide40

9.19 A Classless Addressing Example - continued

Classless addressing, which is now used throughout the Internet, treats IP addresses as arbitrary integers, and allows a network administrator to partition addresses into contiguous blocks, where the number of addresses in a block is a power of 2.

slide41

9.21 Longest-Match and Mixtures of Route Types

Consider the smaller ISP’s routers – entry router is R0

From R0 assume that all networks except 128.211.175.0 /24 are reached through router R1 and 128.211.175.0 /24 is reached through R2

3rd octet4th octet

128.211.168.0 10101 000 00000000

128.211.169.0 10101 001

128.211.170.0 10101 010

128.211.171.0 10101 011

128.211.172.0 10101 100

128.211.173.0 10101 101

128.211.174.0 10101 110

128.211.175.0 10101 111

slide42

9.19 A Classless Addressing Example – continued Smaller ISP has been allocated 128.211.168.0/21

256 addresses

128.211.175.0/24

R2

256 addresses

128.211.174.0/24

1024 addresses

128.211.168.0/22

512 addresses

128.211.172.0/23

slide43

9.21 Longest-Match and Mixtures of Route Types – continued

3rd octetR0 table entry

128.211.168.0 10101 000

128.211.169.0 10101 001

128.211.170.0 10101 010

128.211.171.0 10101 011

128.211.172.0 10101 100

128.211.173.0 10101 101

128.211.174.0 10101 110

128.211.168.0/21 to R1

128.211.175.0/24 to R2

128.211.175.0 10101 111

Nothing gets forwarded to R2

slide44

9.21 Longest-Match and Mixtures of Route Types– continued

Figure 9.14

All traffic will be sent to 10.0.0.2

slide45

9.21 Longest-Match and Mixtures of Route Types – continued

Conclusion:

We need another modification to the forwarding algorithm:

Forward on basis of longest match in routing table

Can help by putting the most specific routes first.