[Nagiosplug-devel] check_http user-agent format

Thomas Guyot-Sionnest dermoth at aei.ca
Tue Dec 21 04:52:15 CET 2010

Hash: SHA1

On 10-12-20 02:17 PM, Bryan Irvine wrote:
>> check_http/1.4.14 (nagios-plugins/1.4.14)
>> Instead of :
>> check_http/v1.4.14 (nagios-plugins 1.4.14)
> The 'standard' is pretty loose.  I believe it follows the standard as-is.

Right, after looking at RFC-2068, the general format is following the
rules. Regarding the "v" in the product token:

   "Although any token character may appear in a product-
   version, this token SHOULD only be used for a version identifier
   (i.e., successive versions of the same product SHOULD only differ in
   the product-version portion of the product value)."

Meaning we're still fairly correct. The "comment" part, within
parenthesis, is pretty much free-for-all** although it seems browsers
have settled for a semicolon+Space-separated list of keywords. The extra
version is redundant but doesn't really matter.

**Only restriction is that a "comment" can only include text without
parenthesis (defined as "ctext"), or other "comments", and can contain
any number of either two. Therefore the number of opening and closing
parenthesis must match.

The exact definition is (taking only the relevant parts of the RFC):

=== Basic constructs ===

name = definition
     The name of a rule is simply the name itself (without any enclosing
     "<" and ">") and is separated from its definition by the equal "="
     character. Whitespace is only significant in that indentation of
     continuation lines is used to indicate a rule definition that spans
     more than one line. Certain basic rules are in uppercase, such as
     SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used
     within definitions whenever their presence will facilitate
     discerning the use of rule names.

     Quotation marks surround literal text. Unless stated otherwise, the
          text is case-insensitive.

rule1 | rule2
     Elements separated by a bar ("|") are alternatives, e.g., "yes |
     no" will accept yes or no.

(rule1 rule2)
     Elements enclosed in parentheses are treated as a single element.
     Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
     foo elem" and "elem bar elem".

     The character "*" preceding an element indicates repetition. The
     full form is "<n>*<m>element" indicating at least <n> and at most
     <m> occurrences of element. Default values are 0 and infinity so
     that "*(element)" allows any number, including zero; "1*element"
     requires at least one; and "1*2element" allows one or two.

     Square brackets enclose optional elements; "[foo bar]" is
     equivalent to "*1(foo bar)".

          CTL            = <any US-ASCII control character
                           (octets 0 - 31) and DEL (127)>
          CR             = <US-ASCII CR, carriage return (13)>
          LF             = <US-ASCII LF, linefeed (10)>
          SP             = <US-ASCII SP, space (32)>
          HT             = <US-ASCII HT, horizontal-tab (9)>

          LWS            = [CRLF] 1*( SP | HT )

          TEXT           = <any OCTET except CTLs,
                           but including LWS>

          token          = 1*<any CHAR except CTLs or tspecials>

          tspecials      = "(" | ")" | "<" | ">" | "@"
                         | "," | ";" | ":" | "\" | <">
                         | "/" | "[" | "]" | "?" | "="
                         | "{" | "}" | SP | HT

=== User-agent construct ===

          User-Agent     = "User-Agent" ":" 1*( product | comment )

          product         = token ["/" product-version]
          product-version = token

          comment        = "(" *( ctext | comment ) ")"
          ctext          = <any TEXT excluding "(" and ")">

That's for the syntax; there are additional non-syntactic rules that I
didn't include, written in plain text in the RFC.

- --
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Devel mailing list