We will discuss various HTTP parameters in this section, and their syntax. For example, format the date and time, set the character, etc. These parameters are used when writing the client or server's HTTP software when building our request and response message.
This chapter will mention only a few of the essential HTTP Protocol Parameters and their syntax as used in communication. For instance, date format, URL format ... etc. This will help you create request and answer messages when writing HTTP clients or server programmes.
HTTP uses the numbering scheme < major>.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
HTTP/1.0 or HTTP/1.1
Uniform resource identifiers (URI) are formatted simply, case-insensitive string containing name, location, etc. to define a resource, such as a website, a web service, etc. A general URI syntax used for HTTP shall be as follows:
URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
If the port is empty or not specified, port 80 is assumed for HTTP and an empty abs path equals an abs path of '/.' Characters other than those in the reserved and unsafe sets are equivalent to their encoding of"% ""HEX HEX."
The following three URIs are equivalent:
http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html
Without exception all HTTP date / time stamps MUST be represented in Greenwich Mean Time (GMT). HTTP applications may use any of the following three Date / Time stamp representations:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
We use character sets to define the sets of characters the client prefers. You can list several sets of characters separated by commas. If a value is not defined, then the US-ASCII is the default.
Following are the valid character sets:
US-ASCII or ISO-8859-1 or ISO-8859-7
An encoding value for content means that an encoding algorithm was used to encode the content before passing it over the network. Content coding is mainly used to permit the encoding or otherwise useful conversion of a document without losing its identity
All values that represent content are case-insensitive. HTTP/1.1 uses content coding values in the fields of the Accept-Encoding and Content-Encoding headers which we can see in the following chapters.
Following are the valid encoding schemes:
Accept-encoding: gzip or Accept-encoding: compress
In the Content-Type and Approve header fields HTTP uses Internet Media Forms to provide open and extensible data typing and negotiation of type. The Internet Assigned Number Authority (IANA) records all Media-type values. The general syntax for defining type of media is as follows:
media-type = type "/" subtype *( ";" parameter )
The type, subtype, and parameter attribute names are case-insensitive.
HTTP uses tag language within the fields Accept-Language and Content-Language. A language tag consists of one or more parts: a primary language tag, and a probably empty subtag series:
language-tag = primary-tag *( "-" subtag )
White spaces are not allowed within the tag and all tags are case-insensitive.
Example tags include:
en, en-US, en-cockney, i-cherokee, x-pig-latin
Where any two-letter primary-tag is an ISO-639 language abbreviation and any initial two-letter subtag is a country code ISO-3166.