Commit 5f66434d authored by Ivan Vilata-i-Balaguer's avatar Ivan Vilata-i-Balaguer
Browse files

Fix streaming signatures spec for missing previous block signature.

It is needed besides the previous block's chained hash (`ouihash`) for the
first data block's signature string.
parent ce48e1d5
......@@ -114,13 +114,13 @@ If a client got to get and save a complete response from the injector, it may se
## Range requests
If a client sends an HTTP range request to another client, the later aligns it to block boundaries (this is acceptable according to [RFC7233#4.1][] — "a client cannot rely on receiving the same ranges that it requested"). The `Content-Range:` header in the response is not part of the initial nor final signatures. If the range does not start at the beginning of the data, the first block `i` is accompanied with a `ouihash=BASE64(CHASH[i-1])` chunk extension to enable checking its `ouisig`. Please note that to ease serving range requests, a client storing a response may cache all chain hashes along their blocks, so as to avoid having to compute the `ouihash` of the first block in the range.
If a client sends an HTTP range request to another client, the later aligns it to block boundaries (this is acceptable according to [RFC7233#4.1][] — "a client cannot rely on receiving the same ranges that it requested"). The `Content-Range:` header in the response is not part of the initial nor final signatures. If the range does not start at the beginning of the data, the first block `i` is accompanied with `ouipsig=BASE64(SIG[i-1])` and `ouihash=BASE64(CHASH[i-1])` chunk extensions to enable checking its `ouisig`. Please note that to ease serving range requests, a client storing a response may cache all chain hashes along their blocks, so as to avoid having to compute the `ouihash` of the first block in the range.
[RFC7233#4.1]: https://tools.ietf.org/html/rfc7233#section-4.1
Also note that responses to a range request mush have a `206 Partial Content` status, which would break signature verification. To avoid this issue, the original response status code (usually `200`) is saved to the `X-Ouinet-HTTP-Status` header, and head verification should automatically replace the `206` status (if so allowed) with the saved one (only for verification purposes).
HTTP range requests from client to injector may not be supported since the injector would need to download all data from the beginning to compute an initial `ouihash`. This could be abused to make the injector use resources by asking for the last block of a big file. At any rate, in such an injection, `Digest:` and `X-Ouinet-Data-Size:` may be missing in the final response head, if the injector did not have access to the whole body data. Also, the (aligned) `Content-Range:` header would never be signed to allow later sharing of different subranges, which can be validated independently anyway.
HTTP range requests from client to injector may not be supported since the injector would need to download all data from the beginning to compute the initial `ouipsig` and `ouihash`. This could be abused to make the injector use resources by asking for the last block of a big file. At any rate, in such an injection, `Digest:` and `X-Ouinet-Data-Size:` may be missing in the final response head, if the injector did not have access to the whole body data. Also, the (aligned) `Content-Range:` header would never be signed to allow later sharing of different subranges, which can be validated independently anyway.
## HEAD requests
......
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