Commit 5296de48 authored by Ivan Vilata-i-Balaguer's avatar Ivan Vilata-i-Balaguer
Browse files

Refer to RFC and purpose of `Digest` header in content signing doc.

parent 29e7c32b
......@@ -39,9 +39,11 @@ The injector then sends data blocks of the size specified above (the last one ma
When all data blocks have been sent to the client, the injector sends additional headers to build the **final response head** including:
- Content digests for the whole body. SHA2-256 is used as a compromise between security and digest size.
- Content digests for the whole body (as in [RFC3230][]). SHA2-256 is used as a compromise between security and digest size. This digest allows other tools to easily verify body data without needing to implement data block signature verification.
- The final content length.
[RFC3230]: https://tools.ietf.org/html/rfc3230
HTTP chunked transfer encoding is used to enable providing a first set of headers, then a signature (as a chunk extension) after each sent block, then a final set of headers as a trailer.
Please note that neither the initial signature nor framing headers (`Transfer-Encoding:`, `Trailer:`, `Content-Length:`) are part of the final signature, so that the receiving client may serve to other clients the final signature in the initial headers instead of the initial one, or even serve the response with identity transfer encoding (without block signatures nor a trailer) and still enable complete (but not incomplete) response verification. The purpose of the `X-Ouinet-Data-Size:` header is to allow verifying data size without forcing the presence or absence of `Content-Length:`, which would break chunked or identity transfer-encoded messages, respectively.
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment