..
..
.. Licensed under the Apache License, Version 2.0 (the "License");
.. you may not use this file except in compliance with the License.
.. You may obtain a copy of the License at
..
..     http://www.apache.org/licenses/LICENSE-2.0
..
.. Unless required by applicable law or agreed to in writing, software
.. distributed under the License is distributed on an "AS IS" BASIS,
.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
.. See the License for the specific language governing permissions and
.. limitations under the License.
..

.. _jobs:

*************************
Content Invalidation Jobs
*************************
:dfn:`Content Invalidation Jobs`, or simply "jobs" as they are sometimes known, are ways of forcing :term:`cache servers` to treat content as no longer valid, bypassing their normal caching policies.

In general, this *should* be unnecessary, because a well-behaved :term:`Origin` *should* be setting its HTTP caching headers properly, so that content is only considered valid for some appropriate time intervals. Occasionally, however, an :term:`Origin` will be too optimistic with its caching instructions, and when content needs to be updated, :term:`cache servers` need to be informed that they must check back with the :term:`Origin`. Content Invalidation Jobs allow this to be done for specific patterns of assets, so that :term:`cache servers` will check back in with the :term:`Origin` and verify that the content they have cached is still valid.

The model for Content Invalidation Job as API objects is given in :ref:`jobs-model`.

.. _jobs-model:

.. code-block:: typescript
	:caption: Content Invalidation Job as a Typescript interface.

	/** This is the form used to create a new Content Invalidation Job */
	interface ContentInvalidationJobCreationRequest {
		deliveryService: string;
		invalidationType: "REFRESH" | "REFETCH";
		regex: `/${string}` | `\\/${string}`; // must also be a valid RegExp
		startTime: Date; // RFC3339 string
		ttlHours: number;
	}

	/**
	 * This is the form used to return representations of Content Invalidation
	 * Requests to clients.
	 */
	interface ContentInvalidationJob {
		assetUrl: string;
		createdBy: string;
		deliveryService: string;
		id: number;
		invalidationType: "REFRESH" | "REFETCH";
		startTime: Date; // RFC3339 string
		ttlHours: number;
	}

.. _job-asset-url:

Asset URL
---------
This property only appears in responses from the :ref:`to-api` (and in the bodies of ``PUT`` requests to :ref:`to-api-jobs`, where the scheme and host/authority sections of the URL is held immutable). The :dfn:`Asset URL` is constructed from the `Regular Expression`_ used in the creation of a Content Invalidation Job and the :ref:`ds-origin-url` of the :term:`Delivery Service` for which it was created. It is a URL that has a valid regular expression as its path (and may not be "percent-encoded" where a normal URL typically would be). Requests from CDN clients for content that matches this pattern will trigger Content Invalidation behavior.

.. _job-created-by:

Created By
----------
The username of the user who created the Content Invalidation Job is stored as the :dfn:`Created By` property of the Content Invalidation Job.

.. _job-ds:

Delivery Service
----------------
A Content Invalidation Job can only act on content for a single :term:`Delivery Service` - invalidating content for multiple :term:`Delivery Services` requires multiple Content Invalidation Jobs. The :dfn:`Delivery Service` property of a Content Invalidation Job holds the :ref:`ds-xmlid` of the :term:`Delivery Service` on which it operates.

.. versionchanged:: 4.0
	In earlier API versions, this property was allowed to be either the integral, unique identifier of the target :term:`Delivery Service`, *or* its :ref:`ds-xmlid` - this is no longer the case, but it should always be safe to use the :ref:`ds-xmlid` in any case.

.. _job-id:

ID
--
The integral, unique identifier for the Content Invalidation Job, assigned to it upon its creation.

.. _job-invalidation-type:

Invalidation Type
-----------------
:dfn:`Invalidation Type` defines how a :term:`cache server` should go about ensuring that its cache is valid.

The normal operating mode for a Content Invalidation Job is to force the :term:`cache server` to send a request to the :term:`Origin` to verify that its cache is valid. If that is the case, no extra work is done and business as usual resumes. However, some :term:`Origins` are misconfigured and do not respond as required by HTTP specification. In this case, it is strongly advised to fix the :term:`Origin` so that it properly implements HTTP. However, if an :term:`Origin` is sending cache-able responses to requests, and cannot be trusted to verify the validity of cached content based on cache-controlling HTTP headers (e.g. :mailheader:`If-Modified-Since`) instead returning responses like ``304 Not Modified`` *even when the content has in fact been modified*, **and** if correcting this behavior is not an option, then the :term:`cache server` may be forced to pretend that the content it has was actually invalidated by the :term:`Origin` and must be completely re-fetched.

The two values allowed for a Content Invalidation Job's Invalidation Type are:

REFRESH
	A :dfn:`REFRESH` Content Invalidation Job instructs :term:`cache servers` to behave normally - when matching content is requested, send an upstream request to (eventually) the :term:`Origin` with cache-controlling HTTP headers, and trust the :term:`Origin`'s response. The vast majority of all Content Invalidation Jobs should most likely use this Invalidation Type.
REFETCH
	Rather than treating the cached content as "stale", the :term:`cache servers` processing a :dfn:`REFETCH` Content Invalidation Job should fetch the cached content again, regardless of what the :term:`Origin` has to say about the validity of their caches. These types of Content Invalidation Jobs cannot be created without a proper "semi-global" :ref:`refetch_enabled Parameter <parameter-name-refetch_enabled>`.

.. caution:: A "REFETCH" Content Invalidation Job should be used **only** when the :term:`Origin` is not properly configured to support HTTP caching, and will return invalid or incorrect responses to conditional requests  as described in section 4.3.2 of :rfc:`7234`. In any other case, this will cause undo load on both the :term:`Origin` and the requesting :term:`cache servers`, and "REFRESH" should be used instead.

.. _job-regex:

Regular Expression
------------------
The :dfn:`Regular Expression` of a Content Invalidation Job defines the content on which it acts. It is used to match URL *paths* (including the query string - but **not** including document fragments, which are not sent in HTTP requests) of content to be invalidated, and is combined with the :ref:`ds-origin-url` of the :term:`Delivery Service` for which the Content Invalidation Job was created to obtain a final pattern that is made available as the `Asset URL`_.

.. note:: While the :ref:`to-api` and :ref:`tp-overview` both require the Regular Expression to begin with ``/`` (so that it matches URL paths), the :ref:`to-api` allows optionally escaping this leading character with a "backslash" :kbd:`\\`, while :ref:`tp-overview` does not. As ``/`` is not syntactically important to regular expressions, the use of a leading :kbd:`\\` should be avoided where possible, and is only allowed for legacy compatibility reasons.

.. table:: Aliases/Synonyms

	+------------+--------------------------------------------------------------------------------+-------------------------------+
	| Name       | Use(s)                                                                         | Type                          |
	+============+================================================================================+===============================+
	| Path Regex | In Traffic Portal forms                                                        | unchanged (String, str, etc.) |
	+------------+--------------------------------------------------------------------------------+-------------------------------+
	| regex      | In raw :ref:`to-api` requests and responses, internally in multiple components | unchanged (String, str, etc.) |
	+------------+--------------------------------------------------------------------------------+-------------------------------+

.. _job-start-time:

Start Time
----------
Content Invalidation Jobs are planned in advance, by setting their :dfn:`Start Time` to some point in the future (the :ref:`to-api` will refuse to create Content Invalidation Jobs with a Start Time in the past). Content Invalidation Jobs will have no effect until their Start Time.

.. _job-ttl:

TTL
---
The :dfn:`TTL` of a Content Invalidation Job defines how long a Content Invalidation Job should remain in effect. This is generally expressed as an integer number of hours.

.. table:: Aliases/Synonyms

	+------------+-----------------------------------------+----------------------------------------------------------------------+
	| Name       | Use(s)                                  | Type                                                                 |
	+============+=========================================+======================================================================+
	| parameters | In legacy :ref:`to-api` versions        | A string, containing the TTL in the format :samp:`TTL:{Actual TTL}h` |
	+------------+-----------------------------------------+----------------------------------------------------------------------+
	| ttlHours   | In :ref:`to-api` requests and responses | Unchanged (unsigned integer number of hours)                         |
	+------------+-----------------------------------------+----------------------------------------------------------------------+