cobusc / imagerl Goto Github PK

For some use-cases [1] it is unnecessary or not desirable to do source image caching. The configuration should contain a setting to control this.

[1] Most notably when images are served "as is" (without width/height/annotation options), caching the source and rendition (which will be exactly the same as the source) leads to duplication in the cache.

http://code.google.com/p/erlmagic/

http://erldocs.com/R15B/os_mon/memsup.html

The canonical URL of the request can be provided when:
[1] wurfl is NOT used as width/height specifier,
[2] wurfl IS used as width/height specifier AND the useragent is provided as part of the query.

Ref:

14.14 Content-Location

The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has multiple entities associated with it, and those entities actually have separate locations by which they might be individually accessed, the server SHOULD provide a Content-Location for the particular variant which is returned.

   Content-Location = "Content-Location" ":"
                     ( absoluteURI | relativeURI )

The value of Content-Location also defines the base URI for the entity.

The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of the resource corresponding to this particular entity at the time of the request. Future requests MAY specify the Content-Location URI as the request- URI if the desire is to identify the source of that particular entity.

A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond to later requests on that Content-Location URI. However, the Content- Location can be used to differentiate between multiple entities retrieved from a single requested resource, as described in section 13.6.

If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.

The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases.