HTTP: Hypertext Transfer Protocol

• HTTP is a modern approach to sharing data that relies on speed and efficiency
• HTTP has been used in the World-Wide Web since 1990
• HTTP/1.0 describes established features of HTTP clients and servers
• HTTP is suitable for search, updates, and annotations
• HTTP builds its location and addressing structure on top of URIs

Terminology

• Connection: a link made between two applications for communicating
• Message: A string of bytes in a specific order during HTTP
• Request: An HTTP request message
• Response: An HTTP response message
• Resource: A network object or service identifiable through a URI
• Entity: A version of a data resource with meta information and content
• Client: An application that connects to servers to send requests
• User agent: Initiates a request, like browsers, editors or web robots
• Server: Accepts connections and responds
• Origin server: Hosts or creates the resource
• Proxy: A go-between server used to make requests on behalf of other clients
• Gateway: Intermediary server that receives gateway requests as an original server would
• Tunnel: A blind relay between two connections that is not a part of HTTP communication
• Cache: A local store of messages that controls what to save, retrieve, and delete

Operation

• HTTP follows a request/response model
• Clients connect with servers to send a request that includes a method, URI and protocol version
• Requests resemble MIME messages and might contain modifiers, client info and body content
• Servers respond with a status line, protocol version, success/error code and MIME-like data

Caching

• User agents start most HTTP communications
• Cases include connections between user agents and origin servers
• Proxies, gateways, and tunnels can be used to mediate connections
• Intermediaries can act as proxies, gateways or tunnels
• Proxies forward and rewrite requests to other servers
• Gateways receive and translate requests for underlying servers
• Tunnels relay communication
• Caching can shorten request/response chains.

HTTP and MIME

• HTTP/1.0 relies on constructs from MIME, defined in RFC 1521
• Appendix C outlines how HTTP changes Internet Media Types

Notational Conventions and Generic Grammar

• Includes rules and constructs for: Augmented BNF

Protocol Parameters

• HTTP uses a major.minor numbering scheme for protocol versions
• HTTP version indicates the message format and communication capabilities
• Minor number increments with feature additions
• Major number increments with format changes
• The "HTTP-Version" field indicates the version
• Recipients assume messages follow HTTP/1.0 standards if no version is specified

HTTP 1.0 Requirements

• HTTP/1.0 servers have certain requirements
• Recognize the formats for HTTP/0.9 & HTTP/1.0 request lines
• Understand legitimate requests in the formats HTTP/0.9 or HTTP/1.0
• Respond appropriately using the client's protocol version
• HTTP/1.0 clients must recognize the Status-Line for HTTP/1.0 responses
• They must understand valid responses from HTTP/0.9 or HTTP/1.0

Proxies and Gateways

• Proxy and gateway applications should carefully forward requests
• Protocol version shows sender ability, so a proxy/gateway must not send higher versions than its native version
• Upon receiving high version requests the proxy/gateway may downgrade the request or respond with an error
• Upgrade requests with lower versions, before forwarding
• The proxy or gateways response must follow server requirements

Uniform Resource Identifiers (URIs)

• URIs have been referred to by various names like WWW addresses, Universal Document Identifiers, Universal Resource Identifiers, and Uniform Resource Locators (URL)
• In HTTP, Uniform Resource Identifiers are simply formatted strings identifying network resources via name, location, or other characteristics

General Syntax

• URIs in HTTP appear in absolute or relative form based on context
• Absolute URIs always begin with a scheme name and a colon
• BNF-style syntax is used to define URI components

HTTP URLs

• The "http" scheme is used to located network resources through HTTP
• This scheme defines a specific syntax and semantics for HTTP URLs
• If port is empty or absent, port 80 is assumed
• Identified resource is on the server listening for TCP connections through identified host port
• "Request-URI" for the resource is the absolute path
• Absence of absolute path implies root ("/") when used as "Request-URI"

Representations

• Canonical form refers to converting UPALPHA chars to LOALPHA equivs
• Omitting [ ":" port ] if port is 80, and replaces empty absolute path with "/"
• HTTP URLs only identify TCP resources
• Non-TCP resources are identified by another URI scheme

Date/Time Formats

• HTTP/1.0 supports three ways to represent date/time stamps: RFC 822, RFC 850, and ANSI C's asctime() format
• The RFC 1123 format: should be used as preferred Internet standard and fixed-length subset
• Three acceptable formats for parsing
• The third "asctime" format: clients and servers should not generate.
• Ensure robustness when interpreting date values
• All HTTP/1.0 date/time stamps in Universal Time (UT) also known as Greenwich Mean Time (GMT)

Prefixes

• GMT indicates with first two formats
• The third, "asctime" format it should be assumed when reading
• BNF grammar represents these formats
• HTTP date/time requirements apply usage within the protocol stream
• Clients/servers don't have to use these formats in user presentation, request logging, etc

Character Sets

• HTTP uses the same "character set" definition described for MIME
• "character set" converts octets to characters
• Doesn't require unconditional conversion the other way
• A character set provides multiple octet sequences to represent one character
• MIME character set name must describe octets-to-characters mapping
• Use external information to know the exact mapping is not permitted

Nomenclature

• "character set": commonly becomes "character encoding"
• HTTP/MIME share registry, terminology, maintaining consistency
• HTTP character sets are identified by case-insensitive tokens
• Defines preferred names for charsets likely to used with HTTP entities
• Set includes registered RFC 1521 charsets, US-ASCII & ISO-8859
• Register all character sets defined in IANA
• Applications should limit usage to the IANA-defined registries
• Label the entity body character set, the lowest common denominator of used character codes
• Don't label is preferred over labels US-ASCII or ISO-8859-1.

Content Coding

• Indicate encoding transformation with content coding values
• Main use to compress/encrypt docs yet retain the media type indentity
• Resource stored and decoded before rendering/analogous usage
• Content-coding = "x-gzip" | "x-compress" | token
• Applications should view "gzip" and "compress" as equiv to "x-gzip" & "x-compress"
• Content-coding: values: case-insensitive.
• HTTP/1.0's Content-Encoding value, describes mechanism needed to remove the encoding
• Single programs may be able to decode several content-coding formats

Types

• "x-gzip" is made through "gzip": a Lempel-Ziv coding (LZ77) with 32 bit CRC
• The "compress" program produces "x-compress": an adaptive Lempel-Ziv-Welch coding (LZW)
• Discourage to identify encoding formats by program names for future. Use here demonstrates bad "historical practice"

Media Types

• HTTP uses Internet Media Types in the Content-Type header field to provide open and extensible data typing
• media-type = type "/" subtype *(";" parameter)
• type = token, subtype = token
• Parameters may follow type and subtype with attribute/value pairs
• Parameter = attribute "=" value, attribute/value = token
• Parameter = attribute "=" value where the value is, a "quoted-string"
• Type/subtype parameter and attribute names are case-insensitive
• Parameter values might be case dependent, on "parameter name semantics"
• Don't make LWS between type/subtype, nor attribute and value
• Upon receiving media type with unknown parameter, a user agent should treat media type as its not shown

Processing Media Type

• Many old HTTP apps do not process media type parameters
• HTTP/1.0 clients should only do so when needed to define message content
• Media-type values, register in Internet Assigned Number Authority", IANA
• Media type registration process in RFC 1590. Discourage non-registered media types
• Register Internet media types with "canonical form"
• In general, HTTP-transferred "Entity-Body" must be there before transmission
• Encode body with Content-Encoding = underlying data, canonical form before encoded

Line Breaks

• Media subtypes of "text" use/use CRLF breaks
• plain CR or LF alone = consistent line breaks
• HTTP applications must accept
• CRLF Line Break Bare
• CR or LINE breaks
• if TEXT media in "Entity-Body"

Header Fields and Message Types

• The charset parameter - some media uses types to define their character set
• When transmitter provides no explicit charset, it is considered to have, "ISO-8859-1"
• Label those other than "ISO-8859-1" (or subset)
• Many HTTP servers offer data: using "ISO-8859-1" or similar
• This lowers interoperability: thus, some HTTP user agents can config option, allow user toggle

Other protocols

• MIME offers "multipart", multiple entities inside single message body
• Multipart types registered by (IANA = irrelevant to HTTP/1.0
• User agents might need to understand in order to read body part purposes
• Multipart types share common syntax- including"boundary parameter as part of media data type
• Message body * IS * a protocol and should always use CRLF", linebreaks

Headers

• Include the header files and is significant
• Product Tokens
• Communicate to identify token products, slash, or version identifier
• More fields apply tokens: subproducts are vital part of product to
• BNF grammar for the field follows.

HTTP Messages

• HTTP messages have requests and responses
• Message - Simple-Request: HTTP/0.9 messages or Full-Request HTTP/1.0 messages
• "Full-Request" and "Full-Response": generic from RFC 822 to transmission
• Both messages: include optional header fields/headers + entity body
• Body gets separated from headers by a null line (CRLF)
• "Simple-Request" and "Simple-Response": don't used any header info or used a single request method (GET).
• Simple-Request = "GET" SP Request-URI CRLF
• Simple-Response
• Use of "Simple-Request" form: discouraged = since stops server " from identifying the returned entity's media.

Headers

• HTTP header fields includes General Request/Response and entity
• They come under identical format in section 3.1", RFC 822
• header": field comes from ""name"", a single space, to the ""field value
• ""Header fields: extend over lines: at /least/ one space or (Not Recommended)
• HTTP-header
• text from each of field value are the combinations.

Order

• Not important to order the fields
• Sending General-Header's + subsequent Request- or followed the "Request / ""Response -header" and is GOOD PRACTICE

"Multiple HTTP- Header-fields":

• With same field -name may occur in msg ONLY IF each whole field- value for THAT header is defined.
• Must combine into one ""field. name, and field value"" with no semantics - to then add subsequent.

General Headers

• Some Headers have common request applicability/ answer data, or applies to entity data being transmitted
• Headers apply to message transmissions only
• "General Headers" headers" + date & pragma
• "Good only with protocol General Header"", unrecognised means entity header
• "Re: request msg: from client-Server, includes,
• 1): method for resource
• 2): identifier for resource
• 3):""protocol versions in use.""
• backward compatibility: and ""HTTP / 0.9"" protocol only.
• "Request
• ==: 1. simple request and + 2 Full-Request
• === Get request ""
• Full-requests "" are (headers) + (entity body)/ headers/crlf =4.7.1 sections

First Line

• Line includes: = request method header or request-URIs, as its also called