Merge branch 'master' into dimitris/subnet-id

README.md

@@ -1,6 +1,7 @@
 # Internet Computer Reference
 
-This repository contains the source files of the [Interface Spec], which describes the externally visible behaviour of the Internet Computer.
+This repository contains the source files of the Interface Spec, which describes the externally visible behaviour of the Internet Computer.
+The language-independent description of this IC interface is available in [ic.did](./spec/_attachments/ic.did).
 
 It used to contain a reference implementation and acceptance test suite; these can now be found at <https://github.com/dfinity/ic-hs>.
 
@@ -52,4 +53,4 @@ in the root directory of this repository. The exported Haskell code can then be
 
 ## Contributing
 
-This repository accepts external contributions, conditioned on acceptance of the [https://github.com/dfinity/cla/](Contributor Lincense Agreement).
+This repository accepts external contributions, conditioned on acceptance of the [Contributor Lincense Agreement](https://github.com/dfinity/cla/).

spec/_attachments/interface-spec-changelog.md

@@ -1,6 +1,13 @@
 ## Changelog {#changelog}
 
 ### ∞ (unreleased)
+* Canister cycle balance cannot decrease below the freezing limit after executing `install_code` on the management canister.
+
+### 0.20.0 (2023-07-11) {#0_20_0}
+* IC Bitcoin API, ECDSA API, canister HTTPS outcalls API, and 128-bit cycles System API are considered stable.
+* Add conditions on requested paths in read state requests.
+* Add composite queries.
+* Specify that the canister version is incremented upon every successful message execution except for successful message execution of a query method.
 
 ### 0.19.0 (2023-06-08) {#0_19_0}
 * canister version can be specified in some management canister calls (canister creation, canister code changes, canister settings changes)

spec/http-gateway-protocol-spec.md

@@ -288,6 +288,7 @@ HEADER = 'IC-CertificateExpression: ', HEADER-VALUE
 The request hash is calculated as follows:
 
 1. Let `request_headers_hash` be the [representation-independent hash](https://internetcomputer.org/docs/current/references/ic-interface-spec#hash-of-map) of the request headers:
+   - The header names are lower-cased.
    - Only include headers listed in the `certified_request_headers` field of [the certificate expression header](#the-certificate-expression-header).
      - If the field is empty or no value was supplied, no headers are included.
      - Headers can be repeated and each repetition should be included.
@@ -305,6 +306,7 @@ The request hash is calculated as follows:
 The response hash is calculated as follows:
 
 1. Let `response_headers_hash` be the [representation-independent hash](https://internetcomputer.org/docs/current/references/ic-interface-spec#hash-of-map) of the response headers:
+   - The header names are lower-cased.
    - The `IC-Certificate` header is always excluded.
    - The `IC-CertificateExpression` header is always included.
    - If the `no_certification` field of [the certificate expression header](#the-certificate-expression-header) is present:
@@ -316,6 +318,7 @@ The response hash is calculated as follows:
      - All headers listed (except for the `IC-CertificateExpression` header) are excluded from the certification
      - All other headers (except for the IC-Certificate header) are included in the certification
    - Headers can be repeated and each repetition should be included.
+   - Include an additional `:ic-cert-status` header that contains the numerical HTTP status code of the response.
 2. Let `response_body_hash` be the sha256 of the response body.
 3. Concatenate `response_headers_hash` and `response_body_hash` and calculate the sha256 of that concatenation.
 
@@ -372,7 +375,7 @@ The steps for response verification are as follows:
 
 ## Response Verification Version Assertion
 
-Canisters can report the versions of response verification that they support using public metadata in the [system state tree](https://internetcomputer.org/docs/current/references/ic-interface-spec/#state-tree-canister-information). This metadata will be read by the HTTP Gateway using a [read_state request](https://internetcomputer.org/docs/current/references/ic-interface-spec/#http-read-state). This metadata is a comma-delimited string of versions under the key "supported_certificate_versions”, for example: "1,2". This is treated as an optional, additional layer of security for canisters supporting multiple versions. If the metadata has not been added, then the HTTP Gateway will allow for whatever version the canister has responded with.
+Canisters can report the versions of response verification that they support using public metadata in the [system state tree](https://internetcomputer.org/docs/current/references/ic-interface-spec/#state-tree-canister-information). This metadata will be read by the HTTP Gateway using a [read_state request](https://internetcomputer.org/docs/current/references/ic-interface-spec/#http-read-state). This metadata is a comma-delimited string of versions under the key "supported_certificate_versions”, for example: "1,2". This is treated as an optional, additional layer of security for canisters supporting multiple versions. If the metadata has not been added (i.e. the lookup of this metadata in the `read_state` response returns `Absent`), then the HTTP Gateway will allow for whatever version the canister has responded with.
 
 The request for the metadata will only be made by the HTTP Gateway if there is a downgrade. If the HTTP Gateway requests v2 and the canister responds with v2, then a request will not be made. If the HTTP Gateway requests v2 and the canister responds with v1, a request will be made. If a request is made, the HTTP Gateway will not accept any response from the canister that is below the max version supported by both the HTTP Gateway and the canister. This will guarantee that a canister supporting both v1 and v2 will always have v2 security when accessed by an HTTP Gateway that supports v2.