text: 1992
  These header lines are sent by the client in a HTTP protocol transaction. All lines are RFC822 format headers. The list of headers is terminated by an empty line.
  From
  Accept
  Accept-Encoding
  Accept-Language
  User-Agent
  Referer
  Authorization
  Charge-To
  If-Modified-Since
  Pragma.
  The set given may of course vary from request to request from the same user.
  This field may be wrapped onto several lines according to RCFC822, and also more than one occurence of the field is allowed with the signifiance being the same as if all the entries has been in one field. The format of each entry in the list is (/ meaning "or")
  <field> = Accept: <entry> *[ , <entry> ] <entry> = <content type> *[ ; <param> ] <param> = <attr> = <float> <attr> = q / mxs / mxb <float> = <ANSI-C floating point text represntation>
  See the appendix on the negotiation algorithm as a function and penalty model. Note that a semicolon has a higher precedence than a comma in this syntax, to conform to MIME use.
  If no Accept: field is present, then it is assumed that text/plain and text/html are accepted.
  Accept: text/plain, text/html Accept: text/x-dvi; q=.8; mxb=100000; mxt=5.0, text/x-c
  In order to save time, and also allow clients to receive content types of which they may not be aware, an asterisk "*" may be used in place of either the second half of the content-type value, or both halves. This only applies to the Accept: filed, and not to the content-type field of course.
  Accept: *.*, q=0.1 Accept: audio/*, q=0.2 Accept: audio/basic q=1
  may be interpreted as "if you have basic audio, send it; otherwise send me some other audio, or failing that, just give me what you've got.".
  These parameters are to be specified when types are registered.. @@ TBS.
  Sugestions include the following. Please feed back any references to existing improved abreviations for these:
  Similar to Accept, but lists the Content-Encoding types which are acceptable in the response.
  <field> = Accept-Encoding: <entry> *[ , <entry> ] <entry> = <content transfer encoding> *[ , <param> ]
  Accept-Encoding: x-compress; x-zip
  Similar to Accept, but lists the Language values which are preferable in the response. A response in an unspecifies language is not illegal. See also: Language .
  Language coding TBS. (ISO standard xxxx.)
  This line if present gives the software program used by the original client. This is for statistical purposes and the tracing of protocol violations. It should be included. The first white space delimited word must be the software product name, with an optional slash and version designator. Other products which form part of the user agent may be put as separate words.
  <field> = User-Agent: <product>+ <product> = <word> [/<version>] <version> = <word>
  User-Agent: LII-Cello/1.0 libwww/2.5
  This optional header field.
  If a partial URI is given, then it should be parsed relative to the URI of the object of the request.
  Referer:
  If this line is present it contains authorization information. The format is To Be Specified (TBS). The format of this field is in extensible form. The first word is a specification of the authorisation system in use.
  Specification for current one implemented by AL Sep 1993.
  People at NCSA are designing a PGP/PEM based protection system.
  Authorization: user fred:mypassword
  The scheme name is "user". The second word is a user name (typically derived from a USER environment variable or prompted for), with an optional password separated by a colon (as in the URL syntax for FTP). Without a password, this povides very low level security. With the password, it provides a low-level security as used by unmodified FTP, Telnet, etc.
  Authorization: kerberos kerberosauthenticationsparameters
  The format of the kerberosauthenticationsparameters is to be specified.
  This line if present contains account information for the costs of the application of the method requested. The format is TBS. The format of this field must be in extensible form. The first word starts with a specification of the namespace in which the account is . (This is similar to extensible URL definition.) No namespaces are currently defined. Namespaces will be registered with the registration authority .
  The format of the rest of the line is a function of the charging system, but it is recommended that this include a maximum cost whose payment is authorized by the client for this transaction, and a cost unit.
  This request header is used with GET method to make it conditional: if the
  requested document has not changed since the time specified in this field the
  document will not be sent, but instead a
  Not Modified 304
  reply.
  Format of this field is the same as for
  Date:.
  Syntax is the same as for other multiple-value fields in HTTP, like the Accept: field, namely, a comma-separated list of entries, for which the optional parameters are separated by semicolons.
  Pragma directives should be understood by servers to which they are relevant, e.g. a proxy server; currently only one pragma is defined:
  no-cache
  Pragmas should be passed through by proxies even though they might have significance to the proxy itself. This is necessary in cases when the request has to go through many proxies, and the pragma should affect all of them.