This document describes how Instart handles headers in HTTP responses for traffic routed through its application delivery platform.
The following headers are inserted into all HTTP responses when traffic is served through the Instart service:
|X-Instart-Request-ID||A unique identifier that identifies the particular request that was made, used to log the request in the service access logs.
|x-instart-cache-id||A unique value that identifies the object's cached representation in the Instart cloud cache (this will not be present if this is the first request for this object).
This header is seen in cache hit instances and indicates that the content is being served from the proxy cache.
Its value encodes information that might be useful to Instart when troubleshooting cache issues.
|Age||The server's estimate of the amount of time since the response (or its revalidation) was generated at the Instart PoP, in integer number of seconds|
|Content-Length||indicates the size of the object body sent to the recipient, in decimal number of OCTETs|
The following headers might also be inserted depending on the Instart performance features that are being used by to serve the object. They contain information about whether the feature was successful in operating on the object.
If there was a cache miss affecting HTML Streaming, for example, the header would include this information along with the reason for the miss.
|x-instart-streaming||Image Transcoding, HTML Streaming,
|Contains some information about the state of the transcoding/streaming feature for this response
means the cached object was found successfully;
means there is no streaming cache (HTML HEAD and HTTP headers) present yet.
We also have the flexibility to add custom response headers by specifying them within the property configuration.
Headers altered or removed
If present, the following headers might be changed by passing through the Instart service:
- set-cookie headers present on objects from the origin are not kept for the cached responses served through Instart. The reason is that a cookie value is not guaranteed to remain the same from request to request when served by the origin. If we sent the set-cookie header for every request for a cached object, we would end up sending the same cookie value for each subsequent request for the object. If you have a use case where you require that your set-cookie header be sent with every response, you would need to disable caching for that object so the request hits the origin each time.
- By default, origin CORS headers are replaced by Instart custom ones. We can preserve your origin CORS headers upon request.
- If an Expires header is present in the response from origin, but no Cache-Control header, we add a Cache-Control header to the response which matches the value in the Expires header