Jump to content

Release Notes (Website: Reverse Image proxy) - January 24, 2020


Recommended Posts

8 minutes ago, The A-Team said:

I think it's more about whether something is happening automatically or not. In the case of an img, the user doesn't choose to view the image or receive any related cookies; it just happens without their input. With a link, the user has to consciously click on the link. I guess choosing to click a link is implicitly accepting any possible consequences.

 

And the fact that if gc.com allows embedding untrusted/insecure content from another site, that embedding is their responsibility, which is why they're forcefully proxy-filtering 3rd party content. A link is an inferred, manual interaction by a user, which being a typical internet mechanic, is assumed (though sometimes there are even warnings and disclaimers about clicking a link that takes you to an external website, even) that the user understands the 'risk'.  So the issue is with implicit trust implied by gc.com embedding 3rd party content with no obvious disclaimer or user interaction. It's just dumb that this is now a legal issue of liability, which is messing a whole bunch of creative options for geocache listings.

 

Especially since the original image sources or retained in views not on the website, via API data. *sigh*

Link to comment

As seems to be the case for many others, I found this thread only after one of my puzzle caches was broken by this change. In my case, the puzzle relies on a regularly changing image at an externally hosted site. Unfortunately, another undisclosed "feature" of the image proxy is that it appears to cache the images. For a loong (indefinite?) time. This seems like unacceptable behaviour for a proxy, surely it should be checking for updates of the source image?

  • Upvote 1
  • Helpful 1
Link to comment

Hi nykkole.

I think Groundspeak is mixing two different issues: proxying the images and caching them.

I can understand Groundspeak wants now to proxy all images hosted on 3rd party sites in order to avoid 3rd party sites setting cookies at the client thru cache listings, but that doesn't necessarily mean you have to cache them.

In fact, caching them makes many puzzles break: those that rely on returning on-the-fly a different image depending on some circumstances (e.g., some property of the client's request like the preferred language in the client's browser, some external circumstances retrieved by the 3rd party site...).

In fact, I have noticed your imgproxy server is indeed ignoring the no-cache / Expires HTTP headers returned by the 3rd party site. Could you at least honor these headers?

 

  • Upvote 1
  • Helpful 1
Link to comment
On 1/31/2020 at 4:28 PM, alan666notb said:

I've noticed that images on my profile page are also going through the imageproxy.

It's screwed up a couple of stats bars that I used to display.

 

 

True, quite some of my maps will not be shown correctly now. I'm using GSAK/FSG to create my stats and about every map that is using an overlay to show some extras is broken now :( I would be more than happy to get that fixed.

Link to comment
On ‎2‎/‎2‎/‎2020 at 1:13 PM, Boomshanka said:

Can any GCHQ staff confirm if this change is going to be rolled back (like it was the first time it was implemented) or is it permanent now? It's broken one of my puzzles and I'd like to know whether to archive it or try to rejig it.

 

nykkole posted this last week:

 

On ‎1‎/‎29‎/‎2020 at 12:38 PM, nykkole said:

Why

This change was necessary to comply with changes in privacy law in the U.S. (California) and Europe. We do not plan to roll this update back again. However, we are actively working on identifying which of the surfacing issues we can fix.

 

If you're having any issues, maybe contact HQ directly to tell them what aspect isn't working so they can see if they can make it work with the proxy server.

Link to comment

In my profile page I have an image with dynamically generated map of findings from geocaching.cz:

https://www.geocaching.cz/index.php?app=geocaching&module=nalezy&section=mapa&typ=crkrajemesta&uid=80513

index.php?app=geocaching&module=nalezy&s

 

 

But the link is replaced by this mess and image does not work anymore:

https://imgproxy.geocaching.com/ea070d0d76c2f280d137af6220a1e20375a311f8?url=https%3A%2F%2Fwww.geocaching.cz%2Findex.php%3Fapp%3Dgeocaching%26amp%3Bmodule%3Dnalezy%26amp%3Bsection%3Dmapa%26amp%3Btyp%3Dcrkrajemesta%26amp%3Buid%3D80513

 

 

  • Upvote 1
  • Helpful 1
Link to comment

I have a number of puzzle caches, which took huge amounts of effort to design and put in place, that rely on the user's browser directly accessing the image from an external host (no cookies involved, nothing like that, nothing insidious) so that upon subsequent refreshes of the page, they get something different displayed that is specific to them.

 

These puzzles are all now broken.

 

@nykkole Are these puzzles now permanently broken?  Is my effort and those of the cachers solving these puzzles now wasted and I should just archive them and walk away?

 

  • Upvote 1
  • Helpful 1
Link to comment

An official statement about the permanent change of the way descriptions are handled would be nice; if only in recognition that this is a significant change that has, can, and will now limit what can be done for puzzles, already existing and in the future. Cache owners should know this. Puzzle owners who've seen the forum are aware, but how many cache pages out there are broken and no one would be the wiser until the caches rack of DNFs or the COs are contacted because they're having problems solving a puzzle?

This isn't the same as external images on say Photobucket breaking. Those are obvious. In many cases there is no way for anyone to know except if the CO knows and re-verifies their puzzle and the image functionality.  They need to know.

  • Helpful 1
  • Love 1
Link to comment
On 2/8/2020 at 1:12 AM, mkyral said:

In my profile page I have an image with dynamically generated map of findings from geocaching.cz:


https://www.geocaching.cz/index.php?app=geocaching&module=nalezy&section=mapa&typ=crkrajemesta&uid=80513

index.php?app=geocaching&module=nalezy&s

 

 

But the link is replaced by this mess and image does not work anymore:

https://imgproxy.geocaching.com/ea070d0d76c2f280d137af6220a1e20375a311f8?url=https%3A%2F%2Fwww.geocaching.cz%2Findex.php%3Fapp%3Dgeocaching%26amp%3Bmodule%3Dnalezy%26amp%3Bsection%3Dmapa%26amp%3Btyp%3Dcrkrajemesta%26amp%3Buid%3D80513

 

 

 

Thanks for reporting this. We will investigate what the cause is and see if we can fix it.

Link to comment
On 2/8/2020 at 4:04 PM, funkymunkyzone said:

I have a number of puzzle caches, which took huge amounts of effort to design and put in place, that rely on the user's browser directly accessing the image from an external host (no cookies involved, nothing like that, nothing insidious) so that upon subsequent refreshes of the page, they get something different displayed that is specific to them.

 

These puzzles are all now broken.

 

@nykkole Are these puzzles now permanently broken?  Is my effort and those of the cachers solving these puzzles now wasted and I should just archive them and walk away?

 

 

@funkymunkyzone Can you let us know the GC codes of the caches that have broken images (either in this forum thread, or in an email to contact@geocaching.com )? This will allow us to investigate what the issue might be.

Link to comment

Well I'll say for sure that in one case, it can't be fixed because it's fundamentally how the image is requested.  An image can no longer incorporate the user's IP address in determining the image content, for example, since the source request is always coming from the proxy server, no longer the user (and it has nothing to do with cookies). That's one example of a concept that's broken by using a proxy server. Now I haven't checked explicitly, but I haven't yet seen any website adjusting to GDPR or CCPA run all their 3rd party image srcs through a localized/trusted proxy server. =/

Edited by thebruce0
  • Helpful 1
Link to comment
On 2/1/2020 at 9:17 AM, GeoCachorros said:

Hi nykkole.

I think Groundspeak is mixing two different issues: proxying the images and caching them.

I can understand Groundspeak wants now to proxy all images hosted on 3rd party sites in order to avoid 3rd party sites setting cookies at the client thru cache listings, but that doesn't necessarily mean you have to cache them.

In fact, caching them makes many puzzles break: those that rely on returning on-the-fly a different image depending on some circumstances (e.g., some property of the client's request like the preferred language in the client's browser, some external circumstances retrieved by the 3rd party site...).

In fact, I have noticed your imgproxy server is indeed ignoring the no-cache / Expires HTTP headers returned by the 3rd party site. Could you at least honor these headers?

 

 

I have checked with the engineers and we are actually not caching images at all.

What might be happening is that you expect a different image depending on the circumstances (e.g. language in client's browser). But since we are accessing the image via the proxy server without revealing any information about the user who is viewing the image on Geocaching.com, the hosting server will receive the same information from the proxy server every time the image is accessed.

  • Helpful 1
Link to comment
30 minutes ago, ecanderson said:

Which is to say, no parameters may be passed?

 

I would think the URL querystring would be retained through the proxy server (though I haven't tested it), but that url would of course be static in the cache description, so it wouldn't provide a dynamic image that might be different for different users.  Any dynamic image generation would be dynamic only at a universal level (ie only dynamic in that a querystring can alter the base url past the file extension, but no data related to the user viewing can be utilized, unless viewed on a platform other than the website, or unless the image is directly linked instead of embedded with an IMG SRC)

Link to comment
9 hours ago, nykkole said:

 

@funkymunkyzone Can you let us know the GC codes of the caches that have broken images (either in this forum thread, or in an email to contact@geocaching.com )? This will allow us to investigate what the issue might be.

 

The images aren't broken.  But because all requests for the image come from your proxy, the puzzles no longer function.  These were my more interesting and more favourited puzzles, so it's a real bummer all round.

Link to comment
10 hours ago, thebruce0 said:

 

I would think the URL querystring would be retained through the proxy server (though I haven't tested it), but that url would of course be static in the cache description, so it wouldn't provide a dynamic image that might be different for different users. 

Indeed - that's what I meant.  I don't see any tidy mechanism for doing that now.  Something like language selection would have to be done with a whole series of links.

Link to comment
34 minutes ago, ecanderson said:
11 hours ago, thebruce0 said:

 

I would think the URL querystring would be retained through the proxy server (though I haven't tested it), but that url would of course be static in the cache description, so it wouldn't provide a dynamic image that might be different for different users. 

Indeed - that's what I meant.  I don't see any tidy mechanism for doing that now.  Something like language selection would have to be done with a whole series of links.

 

Oh, I hadn't thought of that - a real practical and useful application of reverse IP lookup to automatically provide a most appropriate version of the image. Not 100% guaranteed, but regionally relative.  And all lost, because the source IP is no longer accessible (and has nothing to do, ultimately, with privacy, let alone cookies)

  • Helpful 1
Link to comment
22 hours ago, nykkole said:

 

I have checked with the engineers and we are actually not caching images at all.

What might be happening is that you expect a different image depending on the circumstances (e.g. language in client's browser). But since we are accessing the image via the proxy server without revealing any information about the user who is viewing the image on Geocaching.com, the hosting server will receive the same information from the proxy server every time the image is accessed.

 

@nykkole  You may not cache but seems that you certainly do not obey 3rd party server HTTP headers and send your own headers with cache-control so that browsers do cache images. Strangely this seems to vary depending on the url so that some urls get Cache-control: no-cache. If there is some logic behind this it would be good to know.

  • Upvote 1
  • Helpful 1
Link to comment
2 hours ago, p44v0 said:

 

@nykkole  You may not cache but seems that you certainly do not obey 3rd party server HTTP headers and send your own headers with cache-control so that browsers do cache images. Strangely this seems to vary depending on the url so that some urls get Cache-control: no-cache. If there is some logic behind this it would be good to know.

 

I think it is browser/device dependent. I noticed when testing one of my puzzle series that have been steamrolled by this change, that the image changes upon refresh on firefox/windows but never changes on Samsung internet/android.

 

Unfortunately for me, this international series of caches around the world relies on the individual ip address coming through, so they are destroyed beyond a caching issue, but still, the observation stands.

 

@nykkole GC6XEFE has been kind of broken by this - as above, the image is not changing on my Samsung phone upon refresh, but does change upon refresh on my PC, windows/firefox.

Edited by funkymunkyzone
Link to comment
6 hours ago, thebruce0 said:

 

Oh, I hadn't thought of that - a real practical and useful application of reverse IP lookup to automatically provide a most appropriate version of the image. Not 100% guaranteed, but regionally relative.  And all lost, because the source IP is no longer accessible (and has nothing to do, ultimately, with privacy, let alone cookies)

 

My use for the ip address coming through to my external host was so that each "player" would play their way through the puzzle separately. In some cases, they would make choices and/or go offsite and when they came back to the cache page they would see the result of what they've done.  There were never any cookies involved, never any personal identification, just ip address.

 

Example: GC54KCH where players guess coordinates, and they are redirected back to the cache page and shown which creature they have the brain of from a humpback whale down to a goldfish, the aim being to get the goldfish. Now the images are proxied, up on redirect back to the cache page you only ever see the initial page and never the result, because no coordinate guess ever comes from the proxy ip address.

  • Helpful 1
Link to comment
On 2/11/2020 at 8:49 AM, funkymunkyzone said:

The images aren't broken.  But because all requests for the image come from your proxy, the puzzles no longer function.

Hi.

I know this wouldn't be perfect, but here is a suggestion.

In the geocache listing, put a downgraded / scrambled version of the image. Then add just under it a link to your real image hosted on your server with a text saying something like "to ensure a better quality of image, please follow this link".

It is a workaround I would consider for my own mysteries if I had such a problem.

Link to comment
4 hours ago, Tungstène said:

Hi.

I know this wouldn't be perfect, but here is a suggestion.

In the geocache listing, put a downgraded / scrambled version of the image. Then add just under it a link to your real image hosted on your server with a text saying something like "to ensure a better quality of image, please follow this link".

It is a workaround I would consider for my own mysteries if I had such a problem.

 

Yes I had thought of this.  The cache pages rather lose a lot of their effect, but it is a workaround of sorts.  Some of my puzzles though really rely on the actual image being in the cache page (such as the Icons of the World series, eg GC54KBR) but others I will be able to rework and link off to another page, such as The Streets are Paved with Cache GC6BAEG, although even it loses part of the puzzle by people having to click out to an external page (and since it's part of the puzzle I can't elaborate on that).  And of course even then these puzzles will only survive until Groundspeak stops us from having any external links...

  • Upvote 1
  • Helpful 1
Link to comment
15 hours ago, funkymunkyzone said:

My use for the ip address coming through to my external host was so that each "player" would play their way through the puzzle separately. In some cases, they would make choices and/or go offsite and when they came back to the cache page they would see the result of what they've done.  There were never any cookies involved, never any personal identification, just ip address.

 

Example: GC54KCH where players guess coordinates, and they are redirected back to the cache page and shown which creature they have the brain of from a humpback whale down to a goldfish, the aim being to get the goldfish. Now the images are proxied, up on redirect back to the cache page you only ever see the initial page and never the result, because no coordinate guess ever comes from the proxy ip address.

 

A previous puzzle of mine used an image that was "broken" on the cache listing. Likewise, it used IP and a bit of cookie session tracking so the user would need to interact with the depicted exposed circuitry to navigate a virtual drone and 'fix' nodes by flying around the region. Each button loaded an image, and the act of loading the appropriate image also issued a command. In theory, loading the URL for N/E/S/W/etc would always display the drone's status. Once it had fixed each of the nodes, the user would have to realize that they need to refresh the listing to see to the 'fixed' image with the coordinates.

It was a pain testing sufficiently to get image caching working (as in forcefully not caching at all) for every browser, but eventually I got it working.

That one's archived though, so I don't need to worry about this update breaking that. But it would have.

 

My latest broken puzzle incorporated the user's IP address into a barcode by encoding the difference between each number and the next stage lat/lon.  It's high difficulty, technical in nature, because the user would need to grok the mechanics of IPv4, the 4 byte setup, and the obscure hints that were instructions to determine the digits of the coordinates. Mainly, by "working with a friend" to notice that their image was different, that would be a hint; or viewing the barcode at different locations (funnily enough, some people printed or saved the image and never considered loading the cache listing at different locations, heh).  In any case, that puzzle is also broken, and it didn't use cookies at all.

 

 

The former would have worked linking to the image in a new tab, but the 'twist' of realizing the image in the description would be fixed would have been lost.

 

The latter would work linking to the image in a new tab but the image is just a barcode. Seeing that it's loaded external would be a big spoiler that it's dynamically generated.

  • Helpful 2
Link to comment
On 2/10/2020 at 11:48 PM, nykkole said:

 

I have checked with the engineers and we are actually not caching images at all.

What might be happening is that you expect a different image depending on the circumstances (e.g. language in client's browser). But since we are accessing the image via the proxy server without revealing any information about the user who is viewing the image on Geocaching.com, the hosting server will receive the same information from the proxy server every time the image is accessed.

Hi  nykkole,

Thanks for your answer. 

You are right that most puzzles are broken because the third-party's response depends on some client request's characteristic (that it is not getting now to it thru imgproxy), but this is not my case.

And you are right that you are not expressly caching, but the effect is the same.

My website returns HTTP header "Pragma: no-cache", but imgproxy is stripping it and returning instead to the client "cache-control: public, max-age=31536000". The effect is that the browser is reusing its cached (incorrect version) copy of the image instead of retrieving every time the new (correct version) from my server (thru imgproxy).

imgproxy should respect HTTP headers returned by the third-party site (at least those related to caching).

  • Upvote 1
  • Helpful 1
Link to comment

I ran into the imgproxy issue with some of my cache listings as well... I have a file extension in the url, my web server sends the content-type header... It would be good to know what the imgproxy expects from the remote web server so I can adjust that. I keep getting "not found" from the proxy for this url: https://www.muggelfrei.at/caches/schlaflos/N2.png

 

imgproxy rewrote it to: https://imgproxy.geocaching.com/ea8bc1cb2deb3a8fa89698870b452f8d77abb9fe?url=https%3A%2F%2Fwww.muggelfrei.at%2Fcaches%2Fschlaflos%2FN2.png

 

What am I doing wrong and how can I fix that?

Edited by SpeedCore
  • Helpful 1
Link to comment

Today, I received a quite devastating reply from Groundspeak:

 

Quote

Thank you for contacting Geocaching HQ.

Moving forward we only allow for dropbox and Google drive as hosts. If you are hosting an image anywhere else it will no longer function with geocaching.com. 

Best regards,

Andrew

 

This must be a joke. "Moving forward"?! This feels like moving backwards not only one step. It is not expected that they will revert the change, so it is highly likely that all of my "non-standard" puzzle caches will disappear because of this Groundspeak change. Sadly, it looks like the community will lose interesting puzzles because of this unreasonable move from Groundspeak. Let's all throw some 1/1 micros under a lamppost. Yay. Welcome to Geocaching 2.0 :angry:

  • Upvote 4
  • Surprised 2
  • Helpful 1
Link to comment
17 hours ago, SpeedCore said:

Today, I received a quite devastating reply from Groundspeak:

 

Quote

Thank you for contacting Geocaching HQ.

Moving forward we only allow for dropbox and Google drive as hosts. If you are hosting an image anywhere else it will no longer function with geocaching.com. 

Best regards,

Andrew

 

 

Could the Lackey monitoring this thread please confirm this? I have a number of mysteries and multis that use images hosted on my personal website and I'd like to be able to give warning of their imminent archival to those in the local community who have them on their to-do list.

 

Edit to add: We've all seen the ongoing debacle with Photobucket, how do we know the same thing won't happen with Dropbox or Google Drive?

Edited by barefootjeff
  • Upvote 3
  • Love 1
Link to comment
On 1/24/2020 at 7:38 PM, Geocaching HQ said:

(...) With this recent release, any third-party cookies attached to those images are removed before the images are displayed on the website. (...) We are aware this release may break some images that are entirely dependent upon third-party cookies. (...)

 

The original statement above differs a lot from what Andrew told me in his reply. Actually, for me it's not possible to display any images - with or without attached cookies - if they're hosted outside geocaching.com, Dropbox or Google Drive. Furthermore, it doesn't only break images that are "entirely dependent upon third-party cookies" but it break all images hosted outside of the mentioned platforms. Groundspeak, please clarify! Who's right? Erin or Andrew? :sunsure:

  • Upvote 1
Link to comment

Wait so the implication is now that the proxy server isn't even funnelling through images NOT hosted on those servers? At all? (or won't be?)

Other listings I have still display images (preproxy-)hosted on my site.

 

I can't fathom them making a decision to actively blacklist all but two image servers.  If only because this proxy issue only happens on the website, on desktop (which makes me think there is someone in power at hq who despised desktop browsing).  Mobile apps and 3rd party apps that display the description via API retrieval still get the html source with the original URL.  I can't see that interpretation being feasible or reasonable at all... way too drastic a change!

 

ETA: scratched the desktop only part; it's the same for the website on mobile of course, were a mobile user to view the cache listing on the web (technically, which is still in its original desktop display layout) but on a mobile device. =P

Edited by thebruce0
  • Upvote 1
Link to comment
Quote

Moving forward we only allow for dropbox and Google drive as hosts. If you are hosting an image anywhere else it will no longer function with geocaching.com. 

This would break the hits/misses image of external coordinate checkers (Certitudes, geocache.fi which is extremely popular in Finland). No, the built-in coordinate checker can’t replace them.

  • Helpful 1
Link to comment
On 2/19/2020 at 2:51 AM, SpeedCore said:

Today, I received a quite devastating reply from Groundspeak:

 

Quote

Thank you for contacting Geocaching HQ.

Moving forward we only allow for dropbox and Google drive as hosts. If you are hosting an image anywhere else it will no longer function with geocaching.com. 

Best regards,

Andrew

 

"Moving forward" ... does that mean that those images I currently have on my ouwn server will no longer be shown?  So far my cache pages seem to be OK, as long as I don't try to edit any images.  Moving forward I will have to upload them to GS servers.  How then, will Google drive and/or Dropbox function as hosts?  I am confused.

1 hour ago, mustakorppi said:

This would break the hits/misses image of external coordinate checkers (Certitudes, geocache.fi which is extremely popular in Finland). No, the built-in coordinate checker can’t replace them.

Completely agree - I use Certitudes.org for my puzzles, I like the options it gives me as a checker (keyword, stages, extra hints for solvers, etc)  However, this is coded into the cache page itself, not as a background image, so wouldn't it still work?  My Certitudes checkers still seem ok?

  • Helpful 1
Link to comment

I understood the meaning of "moving forward" like "as an enhancement" or "to progress, modernize" but as I'm not a native speaker I maybe misinterpreted that. I'm quite confused that your externally hosted pictures seem to be okay, because it broke all my external hosted pictures without me editing anything in the listings. Maybe the pictures just SEEM to be okay on your side and they're cached locally on your computer? You can try to open a listing in "private browsing" mode to see if they're still displayed correctly.

Link to comment
5 hours ago, SpeedCore said:

Maybe the pictures just SEEM to be okay on your side and they're cached locally on your computer? You can try to open a listing in "private browsing" mode to see if they're still displayed correctly.


Mine do seem to be ok ... at the moment.  Here’s an example; let me know if you see a problem:

 

https://coord.info/GC5NGNH

 

This includes two images hosted on my own website (one generated by a php script) plus one generated image from GeoCheck.org.

 

If the checker images are to be blocked, then puzzle caching would practically be finished at a stroke.  (Ok, a bit of hyperbole!)

 

Edited by IceColdUK
Hyperbole
Link to comment

Just to be clear, this should be tested on basic images hosted on 3rd party servers, not 'special' images where the proxy server itself may break it due to content modification or http request filtering.

 

As of right now, all of my 'basic' 3rd party hosted images are still working (via their proxy).  (note that's not me giving my approval of this change, just to be clear :P)

Link to comment
On 2/16/2020 at 4:46 AM, SpeedCore said:

I ran into the imgproxy issue with some of my cache listings as well... I have a file extension in the url, my web server sends the content-type header... It would be good to know what the imgproxy expects from the remote web server so I can adjust that. I keep getting "not found" from the proxy for this url: https://www.muggelfrei.at/caches/schlaflos/N2.png

 

imgproxy rewrote it to: https://imgproxy.geocaching.com/ea8bc1cb2deb3a8fa89698870b452f8d77abb9fe?url=https%3A%2F%2Fwww.muggelfrei.at%2Fcaches%2Fschlaflos%2FN2.png

 

What am I doing wrong and how can I fix that?

On 2/19/2020 at 2:51 AM, SpeedCore said:

Today, I received a quite devastating reply from Groundspeak:

 

 

This must be a joke. "Moving forward"?! This feels like moving backwards not only one step. It is not expected that they will revert the change, so it is highly likely that all of my "non-standard" puzzle caches will disappear because of this Groundspeak change. Sadly, it looks like the community will lose interesting puzzles because of this unreasonable move from Groundspeak. Let's all throw some 1/1 micros under a lamppost. Yay. Welcome to Geocaching 2.0 :angry:

 

It looks like this reply was due to a misunderstanding. 

Images that are hosted on 3rd party websites are all run through the image proxy server. This can result in unexpected behavior that leads to issues with the image being displayed. 

 

I will look into the content-type header to see if this is something that can be addressed.

  • Upvote 1
  • Helpful 1
Link to comment

The imageproxy is either caching images, or telling my browser to cache images, they're not getting updated on the page I view when they change on the server.

 

I have several stats badges on my profile page, one is Church micro stats, its source is here - http://www.15ddv.me.uk/geo/cm/awards/cm_award.php?name=alan666notb

 

When I view it on my profile page, it is served from here - https://imgproxy.geocaching.com/767082877b3748779959eb636013e39128bbd422?url=http%3A%2F%2Fwww.15ddv.me.uk%2Fgeo%2Fcm%2Fawards%2Fcm_award.php%3Fname%3Dalan666notb

 

However, the second image doesn't change when the original does. I discovered this when I noticed the number of finds shown wasn't increasing. 

 

I tried opening the image in a separate tab (it showed the 'old' number), I then reloaded that tab (Now the 'latest' number showed).

 

When I reloaded my profile page the latest image was now shown (This didn't happen when I just reloaded my profile page).

 

 

  • Upvote 2
  • Helpful 1
Link to comment

The main issue has nothing to do with cookies.  It's that the proxy server is transcoding all image files into JPEGs.  EXIF may be preserved, but png files are destroyed by the transcoding.

 

I have long recommended that COs keep their images on the GC servers, but I can no longer do that.  Transcoding images is used to save bandwidth for many sites, but for geocaches it is a disaster.

  • Upvote 3
  • Helpful 2
Link to comment
22 hours ago, fizzymagic said:

The main issue has nothing to do with cookies.  It's that the proxy server is transcoding all image files into JPEGs.  EXIF may be preserved, but png files are destroyed by the transcoding.

 

I have long recommended that COs keep their images on the GC servers, but I can no longer do that.  Transcoding images is used to save bandwidth for many sites, but for geocaches it is a disaster.

I agree completely. Also the compression is so severe that there are significant artifacts appearing in the images. File size is simply not as important as it used to be and severely compressing file is completely unnecessary. In certain cases, i.e. puzzles,  it can lead to the loss of key information. 

  • Helpful 1
Link to comment
On 3/1/2020 at 10:29 AM, fizzymagic said:

The main issue has nothing to do with cookies.  It's that the proxy server is transcoding all image files into JPEGs.  EXIF may be preserved, but png files are destroyed by the transcoding.

 

I have long recommended that COs keep their images on the GC servers, but I can no longer do that.  Transcoding images is used to save bandwidth for many sites, but for geocaches it is a disaster.

 

I was surprised when I saw this brand new cache description using an animated GIF

 

https://coord.info/GC8H6Y5

 

It seems that not all images are transcoded to JPEG.

Link to comment
On 2/22/2020 at 6:26 AM, alan666notb said:

The imageproxy is either caching images, or telling my browser to cache images, they're not getting updated on the page I view when they change on the server.

 

I have several stats badges on my profile page, one is Church micro stats, its source is here - http://www.15ddv.me.uk/geo/cm/awards/cm_award.php?name=alan666notb

 

When I view it on my profile page, it is served from here - https://imgproxy.geocaching.com/767082877b3748779959eb636013e39128bbd422?url=http%3A%2F%2Fwww.15ddv.me.uk%2Fgeo%2Fcm%2Fawards%2Fcm_award.php%3Fname%3Dalan666notb

 

However, the second image doesn't change when the original does. I discovered this when I noticed the number of finds shown wasn't increasing. 

 

I tried opening the image in a separate tab (it showed the 'old' number), I then reloaded that tab (Now the 'latest' number showed).

 

When I reloaded my profile page the latest image was now shown (This didn't happen when I just reloaded my profile page).

 

 

 

The reason the image is not updating is because it's being pulled from the browser cache instead of retrieving the updated version from the server.

 

The image proxy will preserve the cache-control headers from the source image. If there is no cache-control header specified at all, the image proxy adds one. The way to fix this would be for the hosting server to send a "Cache-Control: no-cache" response header.

Link to comment
58 minutes ago, nykkole said:

The reason the image is not updating is because it's being pulled from the browser cache instead of retrieving the updated version from the server.

 

The image proxy will preserve the cache-control headers from the source image. If there is no cache-control header specified at all, the image proxy adds one. The way to fix this would be for the hosting server to send a "Cache-Control: no-cache" response header.

I understand what you're saying is happening, but I'm not sure whether you're conceding that this results in different behavior than before this change when the image was being accessed directly. I can't really tell, but I'm assuming alan66notb is complaining because the behavior he's seeing is different than what he used to see. Is that what you'd expect? Or is your claim that the added Cache-Control header should result in exactly the same behavior as when the image was delivered directly with no header? I have to admit, the questions that pop into my mind when reading your response are, "Why does the proxy add a cache control header? And what difference does the added header make?"

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...