Most of the communication needed by this standard happens in the HTTP headers of requests and responses.
Additionally, the meaning of relevant HTTP Response codes is explained.
All requests and responses involved in this standard should be made over HTTPS connections with valid certificates. Implementations should decline to follow addresses for insecure HTTP resources, and where possible should redirect HTTP traffic to HTTPS.
A 402 HTTPS response indicates that the request should/may be retried with a (valid, applicable) Receipt as described in the
To the extent possible, 402 should be the “rejection of last resort” in the sense that a 402 response should not be given
if the request would have failed for other reasons in addition to the absence of a suitable
Receipts-Accepts header is mandatory for a 402 response.
If a 402 response has a response body, that body should be used as a placeholder for the requested resource, and must be appropriate for such use. It should contain human-appropreate messaging explaining the nature of the problem.
Receipts-Accepts response header value is
a compressed Receipt Definition XML object.
Any response may have an Accepts header, but they are mandatory for a 402 Response.
In practice it’s advisable for the
Receipts-Accepts header to be constant
for a given resource regardless of the rest of the details of the response.
This decompresses to the following xml:
<definitions xmlns="https://402.TBD"> <definition> <domain>https://www.example.com/</domain> <item>/path/image.png</item> <signers> <signer>https://receipts.dmn.network/path</signer> </signers> <ttl>2720000</ttl> <fresh>60</fresh> <costs> <cost> <units>USD</units> <amount>0.05</amount> </cost> </costs> </definition> </definitions>