Overview#Etag (Entity-tag) for Hypertext Transfer Protocol as defined in RFC 2616 Etag is useful for checking whether an Entity has changed since you last read. HTTP Header Field is defined in RFC 7232 as, in a HTTP Response provides the current entity-tag for the selected representation, as determined at the conclusion of handling the request. An entity-tag is an opaque validator for differentiating between multiple representations of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the same time, or both. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
An entity-tag can be more reliable for validation than a modification date in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, or where modification dates are not consistently maintained.
ETag: "xyzzy" ETag: W/"xyzzy" ETag: ""
An entity-tag can be either a weak or strong validator, with strong being the default. If an origin server provides an entity-tag for a representation and the generation of that entity-tag does not satisfy all of the characteristics of a strong validator (RFC 7232 Section 2.1), then the origin server MUST mark the entity-tag as weak by prefixing its opaque value with "W/" (case-sensitive).SCIM Resource Operations Directory Operation Virtual Attribute.
Attribute Definition#The Etag AttributeTypes is defined as:
- OID of 126.96.36.199.4.1.367188.8.131.52.59
- NAME: Etag
- EQUALITY: caseExactMatch
- SYNTAX: 184.108.40.206.4.1.14220.127.116.11.44
- USAGE DirectoryOperation
- X-ORIGIN 'OpenDJ Directory Server'
More Information#There might be more information for this subject on one of the following:
- HTTP 204
- HTTP Conditional Request
- SCIM Create Request
- SCIM Read Request
- SCIM Replace Request
- SCIM meta
- Virtual Attribute