I'm loading a WMS map using gdal.
Online access works fine, including cache. The cache looks fine, I can see the files and open the images.
When I try to load the same WMS in offline mode it works, but only if I use the same coordinates.
My issue is to open the map in offline mode for different coordinates that overlaps with the cached area. (It's ok if the area outside my cache would be black)
Sample Xml for the request as described in the gdal doc, the problem can be reproduced changing OfflineMode to true and changing the coordinates:
<GDAL_WMS>
<Service name="WMS">
<Version>1.1.1</Version>
<ServerUrl>https://ows.terrestris.de/osm/service?</ServerUrl>
<Layers>OSM-WMS</Layers>
</Service>
<DataWindow>
<SizeX>500</SizeX>
<SizeY>500</SizeY>
<UpperLeftX>9.892920</UpperLeftX>
<UpperLeftY>50.626900</UpperLeftY>
<LowerRightX>13.978200</LowerRightX>
<LowerRightY>47.082800</LowerRightY>
</DataWindow>
<Cache>
<Path>./gdalwmscache</Path>
<Depth>2</Depth>
<Extension>.jpg</Extension>
</Cache>
<OfflineMode>false</OfflineMode>
</GDAL_WMS>
GDal uses a hash of the request URL, internally generated, to create a cache structure.
When making a request with for a different area, the request URL is different from before, so the hash is also different and there is no cache match in most of the cases.
Obs: WMTS has fixed URLs, so it's possible to use the cache even when requesting areas with different bounding boxes.
Related
We use ImageResizer images in a number of places, for example embedded images into pdf Reports, and sometimes users will upload corrupted files or pdf's with passwords. These currently thrown an exception and don't return any image.
Does ImageResizer have some way of returning an alternative fallback image instead? (Ideally with equivalent scaling, and returned immediately, without any 301/302 redirect). In a perfect world we could specify rules for mapping exceptions types to an appropriate fallback image.
We have no control client-side to handle this (e.g. in Telerik/Microsot reporting embedded images)
We currently only do this for 404. Masking 500 errors could be even more problematic.
You could copy/modify this plugin, though: https://imageresizing.net/docs/v4/plugins/image404
I'm using ImageResizer + Diskcache plugin and I'm finding issues to get cache working properly. Either the images are cached forever (regardless how many times I upload a new image) or changing some settings I get the old image in some browsers/computers and the new one in others.
This is what I have now in my web.config:
<add name="AzureReader2" connectionString="blahblahblah" endpoint="http://blahblahblah.blob.core.windows.net/" prefix="~/" redirectToBlobIfUnmodified="false" requireImageExtension="false" checkForModifiedFiles="true" cacheMetadata="true"/>
and:
<diskcache dir="~/imagecache" autoclean="true" hashModifiedDate="true" subfolders="8192" asyncWrites="true" asyncBufferSize="10485760" cacheAccessTimeout="15000" logging="true" />
Not sure if is something I can achieve using the existing parameters. My goal is to invalidate the cache preferably when the new image has been uploaded without having to change the query string serving the image to get the new one.
I was thinking:
Maybe having a blob storage trigger that when a replacement image has
been uploaded, fires a webhook that deletes the cache for that image?
Or a web request to my imageresizer app to preload the new image in
cache so it replaces the old cached image???
I've seen some posts about using IVirtualFileWithModifiedDate but from what I understand that would have a big performance impact? Is probably 5% of our images request that will have someone uploading an image and expecting it to see it right away since most of the images barely change but it's really frustrating if the image doesn't show the new one not even a day after they have uploaded it!
If I can use IVirtualFileWithModifiedDate to invalidate the cache when the image has changed and not in every image request? Would that be possible?
I get the old image in some browsers/computers and the new one in others.
That different browsers are displaying different versions indicates that either browser caching or proxy/CDN caching is at fault.
ImageResizer's DiskCache hashes the modified date, so it is always as correct as the storage provider.
Regarding your expectations around server-side invalidation:
You're using checkForModifiedFiles="true" cacheMetadata="true", which means that Azure is queried for the latest modified date, but that metadata is cached with a sliding expiration window of 1 hour. I.e, if a URL hasn't been accessed in 1 hour, the next request will cause the modified date to be checked. See StandardMetadataCache.
You can change this behavior by implementing IMetadataCache yourself and assigning that cache to the .MetadataCache member of the storage provider you're using.
We had a problem with some of our IE clients failing to download a PDF, even after clicking on the link. We found the answer here resolved our problems: set forcedownload=true for PDF mime types in web.config.
However, that created another problem: we are now unable to render a PDF in a browser when we want to. We used to do this with an iframe. However, as you can see, the PDF just downloads, and does not render in the browser.
I learned that the forcedownload=true setting is actually a default in a subsequent version of Sitecore (v7.2). So, I'm hesitant to revert that.
So, how do I render a PDF in a browser in this situation?
You can leave forceDownload=false on the PDF mime type and instead set the following setting to false:
<setting name="Media.EnableRangeRetrievalRequest" value="false"/>
I faced the same dilema a few months back with the same initial fix. Found out the actual issue last week, I wrote a blog post about it. (In fact, I wrote the answer you linked to, I've updated it with the same information now for future visitors)
The issue is basically a combination of Adobe Reader plugin for IE9, chunked transfer encoding and streaming the file directly from the database. I found if you close your browser and try again, or force refresh with Ctrl+F5 it worked fine. Once Sitecore had cached the file to disk it would continue to work for everyone.
The above setting disables chunked transfer encoding, instead sending the file down to the browser as a single piece. This setting was introduced in Sitecore 6.5+
This is one of the flaws in the MediaRequestHandler and in my opinion; the forceDownload option is pretty useless the way it is designed by default. (Why would ever want to configure this option on media extension only?)
You’ll have to basically turn off the forcedownload option again and replace the MediaRequestHandler with your own one. I usually end up with writing my own anyway because if other issues with the default handler, such as dealing properly with CDN’s etc.
In the ProcessRequest pipeline, you can determine if the item should be “downloaded” or not by setting the Content-Disposition header. You basically need to get rid of the default handling of forceDownload and set your headers based on your own logic.
Personally I prefer to set a query string parameter, such as ?dl=1, and base the Content-Disposition header on this. You could also extend the MediaItem template to contain a default behavior on each item or sub tree (leverage from Sitecore inheritance and standard values), and potentially you could thereby also define (override) a specific filename on each item for the attachment part in the Content-Disposition header.
When rendering the link, you can leverage from the properties collection (write a suitable extension method or similar), so that you can clearly mark your code that the link is meant for download, but still leverage from the built in field render methods. Thereby you eliminate the risk of messing up the page editor etc.
/ Mikael
You have to disable range retrieval request in web.config by setting its value to false.
<setting name="Media.EnableRangeRetrievalRequest" value="false" />
MediaRequestHandler enables Sitecore to download PDF content partially in range using HTTP 206 Status code. You can also overwrite MediaRequestHandler and write your own custom implementation to handle media request.
I am using Apache mod_deflate to return compressed html from a webpage. It has reduced the generated page size from 3k down to 700 bytes.
How do I use HttpConnection in Blackberry to get the compressed page (i.e. only 700bytes instead of 3k)?
P.S. Trying to use the GZIPInputStream(inputStream) keeps returning an incorrect header check error.
As I understood you already tried to download and got non-compressed html page.
If so I think you should add "Accept-Encoding" header to your request (question on forum). Try:
connection.setRequestProperty("Accept-Encoding", "gzip, deflate");
Don't forget that you will get zipped data, so you need to unzip before using.
Also, as mentioned here, gzip/deflate is not so efficient when your traffic is going over BIS-B, BES. Because BB servers will encode/decode data to analyze it and make it more efficient fro transmission.
I have a CherryPy app that dynamically generates images, and those images are re-used a lot but generated each time. The image is generated from a querystring containing the variables, so the same query string will always return the same image (until I rewrite the generation code) and the images are not user-specific.
It occurred to me that I should be aggressively caching those images, but I have no idea how I would go about doing that. Should I be memoizing in CherryPy? Should I do something like this for Apache? Another layer entirely?
Your first attempt should be to use the HTTP cache that comes with CherryPy. See http://docs.cherrypy.org/dev/refman/lib/caching.html for an overview. From there, it's usually a "simple" matter of balancing computational expense versus RAM consumption via cache timeouts.