# HttpBuildCache

API Documentation: | `HttpBuildCache`

Configuration object for the HTTP build cache. Cache entries are loaded via GET and stored via PUT requests.

A successful GET request must return a response with status 200 (cache hit) or 404 (cache miss), with cache hit responses including the cache entry as the response body. A successful PUT request must return any 2xx response.

PUT requests may also return a 413 Payload Too Large response to indicate that the payload is larger than can be accepted. This is useful when `HttpBuildCache.isUseExpectContinue()` is enabled.

Redirecting responses may be issued with 301, 302, 303, 307 or 308 responses. Redirecting responses to PUT requests must use 307 or 308 to have the PUT replayed. Otherwise, the redirect will be followed with a GET request.

Any other type of response will be treated as an error, causing the remote cache to be disabled for the remainder of the build.

When credentials are configured (see `HttpBuildCache.getCredentials()`), they are sent using HTTP Basic Auth.

Requests that fail during request transmission, after having established a TCP connection, will automatically be retried. This includes dropped connections, read or write timeouts, and low level network failures such as a connection resets.

### Properties

Property | Description
`allowInsecureProtocol` | Specifies whether it is acceptable to communicate with a build cache over an insecure HTTP connection.
`allowUntrustedServer` | Specifies whether it is acceptable to communicate with an HTTP build cache backend with an untrusted SSL certificate.
`enabled` | Whether the build cache is enabled.
`push` | Whether a given build can store outputs in the build cache.
`url` | The URI to the cache.
`useExpectContinue` | Specifies whether HTTP expect-continue should be used for store requests. This value defaults to `false`. When enabled, whether or not a store request would succeed is checked with the server before attempting. This is particularly useful when potentially dealing with large artifacts that may be rejected by the server with a 413 Payload Too Large response, as it avoids the overhead of transmitting the large file just to have it rejected. This fail-fast behavior comes at the expense of extra marginal overhead for successful requests, due to the extra network communication required by the initial check. Note: not all HTTP servers support expect-continue.

### Methods

Method | Description
`credentials(configuration)` | Configures the credentials used to access the HTTP cache backend.

### Script blocks

No script blocks

### Property details

#### `boolean` `allowInsecureProtocol`

Specifies whether it is acceptable to communicate with a build cache over an insecure HTTP connection.

For security purposes this intentionally requires a user to opt-in to using insecure protocols on case by case basis.

Gradle intentionally does not offer a global system/gradle property that allows a universal disable of this check.

Allowing communication over insecure protocols allows for a man-in-the-middle to impersonate the intended server, and gives an attacker the ability to serve malicious executable code onto the system.

See also: Want to take over the Java ecosystem? All you need is a MITM!

#### `boolean` `allowUntrustedServer`

Specifies whether it is acceptable to communicate with an HTTP build cache backend with an untrusted SSL certificate.

The SSL certificate for the HTTP build cache backend may be untrusted since it is internally provisioned or a self-signed certificate.

In such a scenario, you can either configure the build JVM environment to trust the certificate, or set this property to `true` to disable verification of the server's identity.

Allowing communication with untrusted servers keeps data encrypted during transmission, but makes it easier for a man-in-the-middle to impersonate the intended server and capture data.

This value has no effect if a server is specified using the HTTP protocol (i.e. has SSL disabled).

#### `boolean` `enabled`

Whether the build cache is enabled.

#### `boolean` `push`

Whether a given build can store outputs in the build cache.

#### `URI` `url`

The URI to the cache.

#### `boolean` `useExpectContinue`

Specifies whether HTTP expect-continue should be used for store requests. This value defaults to `false`. When enabled, whether or not a store request would succeed is checked with the server before attempting. This is particularly useful when potentially dealing with large artifacts that may be rejected by the server with a 413 Payload Too Large response, as it avoids the overhead of transmitting the large file just to have it rejected. This fail-fast behavior comes at the expense of extra marginal overhead for successful requests, due to the extra network communication required by the initial check. Note: not all HTTP servers support expect-continue.

### Method details

#### `void` `credentials`(``Action`<? super `HttpBuildCacheCredentials`>` configuration)

Configures the credentials used to access the HTTP cache backend.