NAME
    gcloud compute backend-buckets update - update a backend bucket

SYNOPSIS
    gcloud compute backend-buckets update BACKEND_BUCKET_NAME
        [--cache-key-include-http-header=[HEADER_FIELD_NAME,...]]
        [--cache-key-query-string-whitelist=[QUERY_STRING,...]]
        [--cache-mode=CACHE_MODE] [--compression-mode=COMPRESSION_MODE]
        [--description=DESCRIPTION]
        [--edge-security-policy=EDGE_SECURITY_POLICY] [--[no-]enable-cdn]
        [--gcs-bucket-name=GCS_BUCKET_NAME] [--[no-]request-coalescing]
        [--signed-url-cache-max-age=SIGNED_URL_CACHE_MAX_AGE]
        [--bypass-cache-on-request-headers=BYPASS_CACHE_ON_REQUEST_HEADERS
          | --no-bypass-cache-on-request-headers]
        [--client-ttl=CLIENT_TTL | --no-client-ttl]
        [--custom-response-header=CUSTOM_RESPONSE_HEADER
          | --no-custom-response-headers]
        [--default-ttl=DEFAULT_TTL | --no-default-ttl]
        [--global | --region=REGION] [--max-ttl=MAX_TTL | --no-max-ttl]
        [--[no-]negative-caching | --no-negative-caching-policies
          | --negative-caching-policy=[[CODE=TTL],...]]
        [--serve-while-stale=SERVE_WHILE_STALE | --no-serve-while-stale]
        [GCLOUD_WIDE_FLAG ...]

DESCRIPTION
    gcloud compute backend-buckets update is used to update backend buckets.

POSITIONAL ARGUMENTS
     BACKEND_BUCKET_NAME
        Name of the backend bucket to update.

FLAGS
     --cache-key-include-http-header=[HEADER_FIELD_NAME,...]
        Specifies a comma-separated list of HTTP headers, by field name, to
        include in cache keys. Only the request URL is included in the cache
        key by default.

     --cache-key-query-string-whitelist=[QUERY_STRING,...]
        Specifies a comma-separated list of query string parameters to include
        in cache keys. Default parameters are always included. '&' and '=' are
        percent encoded and not treated as delimiters.

     --cache-mode=CACHE_MODE
        Specifies the cache setting for all responses from this backend.
        CACHE_MODE must be one of:

         CACHE_ALL_STATIC
            Automatically cache static content, including common image formats,
            media (video and audio), web assets (JavaScript and CSS). Requests
            and responses that are marked as uncacheable, as well as dynamic
            content (including HTML), aren't cached.
         FORCE_CACHE_ALL
            Cache all content, ignoring any "private", "no-store" or "no-cache"
            directives in Cache-Control response headers. Warning: this may
            result in Cloud CDN caching private, per-user (user identifiable)
            content. You should only enable this on backends that are not
            serving private or dynamic content, such as storage buckets.
         USE_ORIGIN_HEADERS
            Require the origin to set valid caching headers to cache content.
            Responses without these headers aren't cached at Google's edge, and
            require a full trip to the origin on every request, potentially
            impacting performance and increasing load on the origin server.

     --compression-mode=COMPRESSION_MODE
        Compress text responses using Brotli or gzip compression, based on the
        client's Accept-Encoding header. Two modes are supported: AUTOMATIC
        (recommended) - automatically uses the best compression based on the
        Accept-Encoding header sent by the client. In most cases, this will
        result in Brotli compression being favored. DISABLED - disables
        compression. Existing compressed responses cached by Cloud CDN will not
        be served to clients. COMPRESSION_MODE must be one of: DISABLED,
        AUTOMATIC.

     --description=DESCRIPTION
        An optional, textual description for the backend bucket.

     --edge-security-policy=EDGE_SECURITY_POLICY
        The edge security policy that will be set for this backend bucket. To
        remove the policy from this backend bucket set the policy to an empty
        string.

     --[no-]enable-cdn
        Enable Cloud CDN for the backend bucket. Cloud CDN can cache HTTP
        responses from a backend bucket at the edge of the network, close to
        users. Use --enable-cdn to enable and --no-enable-cdn to disable.

     --gcs-bucket-name=GCS_BUCKET_NAME
        The name of the Google Cloud Storage bucket to serve from. The storage
        bucket must be in the same project.

     --[no-]request-coalescing
        Enables request coalescing to the backend (recommended).

        Request coalescing (or collapsing) combines multiple concurrent cache
        fill requests into a small number of requests to the origin. This can
        improve performance by putting less load on the origin and backend
        infrastructure. However, coalescing adds a small amount of latency when
        multiple requests to the same URL are processed, so for
        latency-critical applications it may not be desirable.

        Defaults to true.

        Use --request-coalescing to enable and --no-request-coalescing to
        disable.

     --signed-url-cache-max-age=SIGNED_URL_CACHE_MAX_AGE
        The amount of time up to which the response to a signed URL request
        will be cached in the CDN. After this time period, the Signed URL will
        be revalidated before being served. Cloud CDN will internally act as
        though all responses from this backend had a Cache-Control: public,
        max-age=[TTL] header, regardless of any existing Cache-Control header.
        The actual headers served in responses will not be altered.

        For example, specifying 12h will cause the responses to signed URL
        requests to be cached in the CDN up to 12 hours. See $ gcloud topic
        datetimes for information on duration formats.

        This flag only affects signed URL requests.

     At most one of these can be specified:

       --bypass-cache-on-request-headers=BYPASS_CACHE_ON_REQUEST_HEADERS
          Bypass the cache when the specified request headers are matched -
          e.g. Pragma or Authorization headers. Up to 5 headers can be
          specified.

          The cache is bypassed for all cdnPolicy.cacheMode settings.

          Note that requests that include these headers will always fill from
          origin, and may result in a large number of cache misses if the
          specified headers are common to many requests.

          Values are case-insensitive.

          The header name must be a valid HTTP header field token (per RFC
          7230).

          For the list of restricted headers, see the list of required header
          name properties in How custom headers work
          (https://cloud.google.com/load-balancing/docs/custom-headers#how_custom_headers_work).

          A header name must not appear more than once in the list of added
          headers.

       --no-bypass-cache-on-request-headers
          Remove all bypass cache on request headers for the backend bucket.

     At most one of these can be specified:

       --client-ttl=CLIENT_TTL
          Specifies a separate client (for example, browser client) TTL,
          separate from the TTL for Cloud CDN's edge caches.

          This allows you to set a shorter TTL for browsers/clients, and to
          have those clients revalidate content against Cloud CDN on a more
          regular basis, without requiring revalidation at the origin.

          The value of clientTtl cannot be set to a value greater than that of
          maxTtl, but can be equal.

          Any cacheable response has its max-age/s-maxage directives adjusted
          down to the client TTL value if necessary; an Expires header will be
          replaced with a suitable max-age directive.

          The maximum allowed value is 31,622,400s (1 year).

          When creating a new backend with CACHE_ALL_STATIC and the field is
          unset, or when switching to that mode and the field is unset, a
          default value of 3600 is used.

          When the cache mode is set to "USE_ORIGIN_HEADERS", you must omit
          this field.

       --no-client-ttl
          (DEPRECATED) Clears client TTL value.

          The --no-client-ttl option is deprecated and will be removed in an
          upcoming release. If you're currently using this argument, you should
          remove it from your workflows.

     At most one of these can be specified:

       --custom-response-header=CUSTOM_RESPONSE_HEADER
          Custom headers that the external Application Load Balancer adds to
          proxied responses. For the list of headers, see Creating custom
          headers
          (https://cloud.google.com/load-balancing/docs/custom-headers).

          Variables are not case-sensitive.

       --no-custom-response-headers
          Remove all custom response headers for the backend bucket.

     At most one of these can be specified:

       --default-ttl=DEFAULT_TTL
          Specifies the default TTL for cached content served by this origin
          for responses that do not have an existing valid TTL (max-age or
          s-maxage).

          The default value is 3600s for cache modes that allow a default TTL
          to be defined.

          The value of defaultTtl cannot be set to a value greater than that of
          maxTtl, but can be equal.

          When the cacheMode is set to FORCE_CACHE_ALL, the defaultTtl
          overwrites the TTL set in all responses.

          A TTL of "0" means Always revalidate.

          The maximum allowed value is 31,622,400s (1 year). Infrequently
          accessed objects may be evicted from the cache before the defined
          TTL.

          When creating a new backend with CACHE_ALL_STATIC or FORCE_CACHE_ALL
          and the field is unset, or when updating an existing backend to use
          these modes and the field is unset, a default value of 3600 is used.
          When the cache mode is set to "USE_ORIGIN_HEADERS", you must omit
          this field.

       --no-default-ttl
          Clears default TTL value.

     At most one of these can be specified:

       --global
          If set, the backend bucket is global.

       --region=REGION
          Region of the backend bucket to update. Overrides the default
          compute/region property value for this command invocation.

     At most one of these can be specified:

       --max-ttl=MAX_TTL
          Specifies the maximum allowed TTL for cached content served by this
          origin.

          The default value is 86400 for cache modes that support a max TTL.

          Cache directives that attempt to set a max-age or s-maxage higher
          than this, or an Expires header more than maxTtl seconds in the
          future, are capped at the value of maxTtl, as if it were the value of
          an s-maxage Cache-Control directive.

          A TTL of "0" means Always revalidate.

          The maximum allowed value is 31,622,400s (1 year). Infrequently
          accessed objects may be evicted from the cache before the defined
          TTL.

          When creating a new backend with CACHE_ALL_STATIC and the field is
          unset, or when updating an existing backend to use these modes and
          the field is unset, a default value of 86400 is used. When the cache
          mode is set to "USE_ORIGIN_HEADERS" or "FORCE_CACHE_ALL", you must
          omit this field.

       --no-max-ttl
          (DEPRECATED) Clears max TTL value.

          The --no-max-ttl option is deprecated and will be removed in an
          upcoming release. If you're currently using this argument, you should
          remove it from your workflows.

     At most one of these can be specified:

       --[no-]negative-caching
          Negative caching allows per-status code cache TTLs to be set, in
          order to apply fine-grained caching for common errors or redirects.
          This can reduce the load on your origin and improve the end-user
          experience by reducing response latency.

          Negative caching applies to a set of 3xx, 4xx, and 5xx status codes
          that are typically useful to cache.

          Status codes not listed here cannot have their TTL explicitly set and
          aren't cached, in order to avoid cache poisoning attacks.

          HTTP success codes (HTTP 2xx) are handled by the values of defaultTtl
          and maxTtl.

          When the cache mode is set to CACHE_ALL_STATIC or USE_ORIGIN_HEADERS,
          these values apply to responses with the specified response code that
          lack any cache-control or expires headers.

          When the cache mode is set to FORCE_CACHE_ALL, these values apply to
          all responses with the specified response code, and override any
          caching headers.

          Cloud CDN applies the following default TTLs to these status codes:
          ▸ HTTP 300 (Multiple Choice), 301, 308 (Permanent Redirects): 10m
          ▸ HTTP 404 (Not Found), 410 (Gone), 451 (Unavailable For Legal
            Reasons): 120s
          ▸ HTTP 405 (Method Not Found), 421 (Misdirected Request), 501 (Not
            Implemented): 60s

          These defaults can be overridden in cdnPolicy.negativeCachingPolicy.

          Use --negative-caching to enable and --no-negative-caching to
          disable.

       --no-negative-caching-policies
          Remove all negative caching policies for the backend bucket.

       --negative-caching-policy=[[CODE=TTL],...]
          Sets a cache TTL for the specified HTTP status code.

          NegativeCaching must be enabled to config the negativeCachingPolicy.

          If you omit the policy and leave negativeCaching enabled, Cloud CDN's
          default cache TTLs are used.

          Note that when specifying an explicit negative caching policy, make
          sure that you specify a cache TTL for all response codes that you
          want to cache. Cloud CDN doesn't apply any default negative caching
          when a policy exists.

          CODE is the HTTP status code to define a TTL against. Only HTTP
          status codes 300, 301, 308, 404, 405, 410, 421, 451, and 501 can be
          specified as values, and you cannot specify a status code more than
          once.

          TTL is the time to live (in seconds) for which to cache responses for
          the specified CODE. The maximum allowed value is 1800s (30 minutes),
          noting that infrequently accessed objects may be evicted from the
          cache before the defined TTL.

     At most one of these can be specified:

       --serve-while-stale=SERVE_WHILE_STALE
          Serve existing content from the cache (if available) when
          revalidating content with the origin; this allows content to be
          served more quickly, and also allows content to continue to be served
          if the backend is down or reporting errors.

          This setting defines the default serve-stale duration for any cached
          responses that do not specify a stale-while-revalidate directive.
          Stale responses that exceed the TTL configured here will not be
          served without first being revalidated with the origin. The default
          limit is 86400s (1 day), which will allow stale content to be served
          up to this limit beyond the max-age (or s-max-age) of a cached
          response.

          The maximum allowed value is 604800 (1 week).

          Set this to zero (0) to disable serve-while-stale.

       --no-serve-while-stale
          (DEPRECATED) Clears serve while stale value.

          The --no-serve-while-stale option is deprecated and will be removed
          in an upcoming release. If you're currently using this argument, you
          should remove it from your workflows.

GCLOUD WIDE FLAGS
    These flags are available to all commands: --access-token-file, --account,
    --billing-project, --configuration, --flags-file, --flatten, --format,
    --help, --impersonate-service-account, --log-http, --project, --quiet,
    --trace-token, --user-output-enabled, --verbosity.

    Run $ gcloud help for details.

NOTES
    These variants are also available:

        $ gcloud alpha compute backend-buckets update

        $ gcloud beta compute backend-buckets update

