HTTP caching and formats¶
Conditional requests¶
GET and HEAD requests on entries, metadata and resources return the headers Last-Modified and ETag. Clients can revalidate a cached response with If-Modified-Since or If-None-Match and are answered with 304 if the entry has not changed.
Last-Modified is the modification date of the entry. The ETag is based on that date as well, except for responses that embed other entries or the caller's access rights and can therefore change without the entry changing: the entry information with includeAll, contexts, and the resources of lists, groups and users, as well as syndication feeds. For these responses (6.x) the ETag is computed from the response body.
Writes (PUT, POST, DELETE) on an entry, its metadata, its cached external metadata or its resource can be made conditional with If-Unmodified-Since. If the data has been modified after the given date, the request is answered with 412 and nothing is written. EntryScape uses this to detect concurrent edits. Since HTTP dates have no milliseconds, a date within one second of the modification date is accepted.
EntryStore 5.x
In 5.x the ETag is always based on the modification date of the entry, so a client may receive a 304 for a list or context whose members or ACL have changed.
Cache-Control (6.x)¶
EntryStore 6.x sets Cache-Control as follows:
| Response | Cache-Control |
|---|---|
| Requests by authenticated users | private, no-cache |
| Anonymous requests on entries and resources | no-cache |
| Responses that carry credentials, a session cookie or a confirmation token, and JSONP responses | private, no-store (no-store for anonymous JSONP) |
no-cache allows caching but requires revalidation, so clients always see current data while benefiting from 304 responses. Responses vary on Accept, Cookie and Authorization.
A reverse proxy that overrides Cache-Control or removes the ETag header disables conditional requests; see Reverse proxy.
Representation formats¶
Entries, metadata and the resources of lists and graphs can be retrieved in several RDF formats, e.g. application/json (EntryStore's JSON representation), application/rdf+xml, text/turtle, application/ld+json, application/n-triples, application/trig or application/rdf+json. The format is selected with the URL parameter format or, if it is not given, with the Accept header. The format parameter takes precedence.
Requests with a wildcard Accept header (as sent by browsers and <script> tags) and without format receive RDF/XML. A String resource is always returned as text/plain.
In 6.x an unsupported format is answered with 406 (400 on a resource if the value cannot be parsed), and so is an Accept header that accepts none of the available representations, e.g. application/json;q=0.
EntryStore 5.x
Instead of 406, 5.x answers an unsupported format of an entry with Turtle (labelled with the requested media type), and an entry Accept header that accepts none of the representations with RDF/XML. 5.x sends no Cache-Control header on anonymous entry and resource responses.