CS 596: HTTP part 2

CS 596 Client-Server Programming
HTTP part 2

[To Lecture Notes Index]
San Diego State University -- This page last updated May 2, 1996

Contents of HTTP part 2 Lecture

Review

Protocol Requirements

Well defined ( Protocol can not be vague )

BNF
HTTP Document is 44 pages long
FTP RFC 959 is 65 pages long

Are they understandable?

Complete ( All situation must be addressed )

HTTP Document is 44 pages long
FTP RFC 959 is 65 pages long

How to insure?

Computer program must be able to parse protocol

State machines - three ways to implement
BNF

Extendible

Name-Value pairs help here

Basic HTTP Server-Client Interaction
Client: Open connection

Server: Accept/Reject connection

Client: Send request

Server: Send response to request

Connection closed

Full-Request   =	Request-Line 
	*( General-Header   | Request-Header  | Entity-Header ) 
	CRLF
	[ Entity-Body ]


Full-Response  = 	Status-Line      
	*( General-Header   | Request-Header   | Entity-Header ) 
	CRLF
	[ Entity-Body ]

Request Methods

Method         = "GET" | "HEAD" | "PUT" | "POST"
	| "DELETE" | "LINK" | "UNLINK"
	| extension-method

GET and HEAD must be supported by all HTTP/1.0 servers

Servers should return the Status-Code

"501 Not Implemented"

if the method is unknown.
GET
Retrieves whatever item is identified by the URI.

The URI can refer to a data-producing process, or a script

The produced data which shall be returned as the Entity-Body

HEAD
Identical to GET except that the server must not return any Entity-Body in the response POST

Request that the origin server accept the item enclosed in the request as a new subordinate of the resource identified by the URI

Allows a uniform function to:

Annotation of existing documents;

Posting a message to a bulletin board topic, newsgroup, mailing list, or similar group of articles;

Providing a block of data (usually a form) to a data-handling process, or a script which can be run by such a process;

Extending a document during authorship

These are not always supported
Why?
PUT
The enclosed item in the request is to be stored under the supplied URI DELETE
Requests that the server delete the resource identified by the given URI

LINK
Establishes one or more Link relationships between the existing resource identified by the URI and other existing resources

UNLINK
UNLINK method removes one or more Link relationships from the existing resource identified by the URI

General Message Header Fields

General-Header = Connection
	| Date
	| Forwarded
	| Mandatory
	| Message-ID
	| MIME-Version

Connection

Connection     = "Connection" ":" 1#connect-option

connect-option = token [ "=" word ]

Example: Connection: keep-alive

Date
Formats accepted
Preferred:

Sun, 06 Nov 1994 08:49:37 GMT

RFC 822, updated by RFC 1123

Others:

Sunday, 06-Nov-94 08:49:37 GMT
Sun Nov 6 08:49:37 1994

Forwarded
Used by proxies to indicate the intermediate steps between the user agent and the server

Forwarded      = "Forwarded" ":" "by" URI [ "(" product ")" ]
				[ "for" FQDN ]

FQDN           = <Fully-Qualified Domain Name>

Example:

Forwarded: by http://info.cern.ch:8000/ for ptsun00.cern.ch
Proxy
An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients.

Uses:


client-side portals of through network fire walls

Helper applications for handling requests via protocols not implemented by client

Mandatory
The Mandatory header is used to indicate a list of other header field names which must be understood by the receiver

This header is used to alert the receiver that, unlike the default behavior, it cannot safely ignore the semantics of the listed field-names if they are not understood.

It is anticipated that the field names correspond to conditions that must be met by the receiver in order to abide by the sender's licensing, copyright, payment, or other fair-usage constraints.

Mandatory = "Mandatory" ":" 1#field-name Message-ID
The Message-ID field in HTTP is identical to that used by Internet Mail and USENET messages

A single, unique identifier which can be used for identifying the message (not its contents) for "much longer" than the expected lifetime of that message.

Message-ID     = "Message-ID" ":" "<" addr-spec ">"
addr-spec      = unique-string "@" FQDN
unique-string  = <1*CHAR, not including whitespace, "@", or ">">

Message-ID: <9411151630.4256@info.cern.ch>
MIME-Version
HTTP/1.0 messages may include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message.

Unfortunately, current versions of HTTP/1.0 clients and servers use this field indiscriminately, and thus receivers must not take it for granted that the message is indeed in full compliance with MIME.

MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

Request-Header

Request    = Simple-Request | Full-Request

Full-Request   =	Request-Line 
	*General-Header 
	*Request-Header 
	*Entity-Header    
	CRLF
	[ Entity-Body ]

Request-Header = User-Agent
	| If-Modified-Since
	| Pragma
	| Authorization
	| Proxy-Authorization
	| Referer
	| From
	| Accept
	| Accept-Encoding
	| Accept-Language

Response-Header

Full-Response  = Status-Line
	*General-Header         
	*Response-Header      
	*Entity-Header      
	CRLF
	[ Entity-Body ]

Response-Header= Server
	| WWW-Authenticate
	| Proxy-Authenticate
	| Retry-After

Unknown header fields should be considered Entity-Header fields.

Entity Header Fields

Big Issue: In-line data
If we send binary data or data of unknown format how does receiver knowwhen the data ends?

POP solution
Use termination sequence

Insure that termination sequence does not occur in data

HTTP Solution

Full-Response  = Status-Line
	*General-Header         
	*Response-Header      
	*Entity-Header      
	CRLF
	[ Entity-Body ]

Send length of data to be sent

Negotiation Algorithm

(From Old Version of HTTP Doc)

q (quality)

Level of degradation when rendering in the client.

q [[propersubset]]E[0,1], the default value is q=1

qs (quality server)

q factor for the server in when it performs media-type conversions

Default value is qs=1

mxb

The maximum number of bytes accepted by the client
Default value is mxb=undefined (i.e. infinity)

bs
The actual number of bytes

	{ if mxb=undefined,	then (qs * q) }
Q(q,qs,mxb,bs) = 	{ if mxb >= bs,	then (qs * q) }
	{ if mxb <  bs,	then 0        }

The maximum of the Q function represents the preferred media-type Examples of Using Accept

Telnet:	saturn 8080
Server:	accepts connection
Telnet:	GET /cs/cs596_3/ HTTP/1.0	
	Accept: audio/*; q=0.2, 
		audio/basic

Accept: text/plain; q=0.5, 
	text/html,
	text/x-dvi; q=0.8; mxb=100000, 
	text/x-c

CS 596 Client-Server Programming HTTP part 2