So only the metadata from a web resource is actually fetched in the form of HTTP response headers.

For instance, these HTTP response headers would be quite handfull for implementing content-based use cases with Witnet:

$ curl --head https://witnet.io/_nuxt/img/dragon_reading.a37f8cb.png
HTTP/1.1 200 OK
Content-Type: image/png
Content-Length: 498219
etag: "632067ee-79a2b"
...

$ curl --head https://ipfs.io/ipfs/QmQqzMTavQgT4f4T5v6PWBp7XNKtoPmC9jvn12WPT3gkSE
HTTP/1.1 200 OK
Content-Type: image/png
Content-Length: 38376
Etag: "QmQqzMTavQgT4f4T5v6PWBp7XNKtoPmC9jvn12WPT3gkSE"
X-Ipfs-Path: /ipfs/QmQqzMTavQgT4f4T5v6PWBp7XNKtoPmC9jvn12WPT3gkSE
X-Ipfs-Roots: QmQqzMTavQgT4f4T5v6PWBp7XNKtoPmC9jvn12WPT3gkSE
...

The implementation of HTTP/HEAD requests should:

• Support addition of HTTP request headers.
• Transform response header lines into a key/value map

Also, it would be nice to support a new String operator in Radon:

• decodeHash(<encoding_type>), as to transform etag literals into properly decoded array of bytes, at least supporting SHA-256 as possible encoding type.

Possible new use-cases for Witnet:

• Verifying a web binary content (i.e. an image, pdf document, ...) is available at the moment the data request is executed, without the nodes actually needing to download the whole file.
• Verifying the content type, length and etag of any given URL.

Javascript DSL usage example:

const token_image_digest = new Witnet.HttpHeadSource(
  "https://api.game.art/images/1.png",  {
    "Transfer-Encoding": "identity"
  }
)
  .parseJSONMap() // perhaps not necessary, as response to HttpHeadSource should always be a key/value map
  .mapGetString("Etag")
  .stringDecode(Witnet.HASHES.SHA256)