ipptool: Add predicate to do an HTTP GET of a URI

[wifiprintguy]

It would be useful if tools such as ipptool could do an HTTP GET on a resource at a URL provided by IPP attributes that supply URLs, such as "printer-icons" or "printer-icc-profiles" or "printer-strings-uri". This would allow ipptool to implement tests where the content pointed to by the URL could be validated for reachability and other aspects. While it could be that ipptool supports this using libcurl or something, it could also be supported by libcups.

[michaelrsweet]

Proposed change:

EXPECT some-attribute OF-TYPE uri WITH-CONTENT "spec"
EXPECT some-attribute OF-TYPE uri WITH-MIME-TYPE "foo/bar[,...,fooN/barN]"

where "spec" is one of the following keywords:

• available to confirm accessibility (a GET succeeds for http/https URIs and a HEAD succeeds for ipp/ipps URIs)
• valid to confirm accessibility and perform simple format validation/encoding checks
• valid-icon to confirm accessibility, proper format, proper dimensions, and the presence of an alpha channel or transparent pixel in PNG icon images

The tests will apply to all URI values (effectively WITH-ALL-CONTENT/WITH-ALL-MIME-TYPES) since there seems little point in just checking one value in this case.

[michaelrsweet]

Maybe also a SAVE-CONTENT "filename" predicate to save the content to a file?

[wifiprintguy]

Proposed change:

EXPECT some-attribute OF-TYPE uri WITH-CONTENT "spec"
EXPECT some-attribute OF-TYPE uri WITH-MIME-TYPE "foo/bar[,...,fooN/barN]"

where "spec" is one of the following keywords:

• available to confirm accessibility (a GET succeeds for http/https URIs and a HEAD succeeds for ipp/ipps URIs)
• valid to confirm accessibility and perform simple format validation/encoding checks
• valid-icon to confirm accessibility, proper format, proper dimensions, and the presence of an alpha channel or transparent pixel in PNG icon images

The tests will apply to all URI values (effectively WITH-ALL-CONTENT/WITH-ALL-MIME-TYPES) since there seems little point in just checking one value in this case.

That all sounds good. If the semantics of 'WITH-CONTENT' is 'WITH-ALL-CONTENT' then why not be explicit and use 'WITH-ALL-CONTENT' and 'WITH-ALL-MIME-TYPES'?

Maybe also a SAVE-CONTENT "filename" predicate to save the content to a file?

That looks good - if the "filename" bit is optional then use the filename of the resource pointed to by the URL?

[michaelrsweet]

@wifiprintguy WRT the filename for SAVE-CONTENT, it can't be optional but we could define it as "directory or filename" where the directory gets the base name from the URL added for the full filename, and/or some substitution sequences to insert the full filename, the filename without the extension, and the extension, something like:

SAVE-ALL-CONTENT "/path/to/test-%basename%-%index%.%ext%"

to save files named as "test-basename-N.ext".