Closed GoogleCodeExporter closed 9 years ago
I was able to temporarily "tame" this cache (by writing a note, running GeoToad
- which showed a single log entry, and deleting the log again).
This means that for some reason the whole series of log entries got lost for
this particular cache, setting a counter to zero, and confusing the server
routines.
Please DO NOT WRITE ANY LOGS for this particular cache as it's a welcome test
case.
If you have to work around it (or a similar one):
- Write the GCxxxx code to a text file
- Use GeoToad 3.17.0 or later (from the development series), and add an option
to your command line "-E skipcache=filename" - the username can be chosen
randomly, and filename should be the name/path to the text file of the previous
step
- This should skip the cache (by faking it as "found") and let you proceed.
Again, please don't write log entries for GCN17F, thank you.
Original comment by Steve8x8
on 3 Nov 2012 at 3:34
Quick hack to handle the "500" case by trying to use the "no logs" page instead.
This isn't foolproof yet (what if there's a 500 error triggered by another
cause?), and hasn't been checked against bad cookies, wrong login data, etc.
At least it makes GCN17F accessible again.
To be applied from the geotoad "root" using "patch -p1", as always.
Original comment by Steve8x8
on 3 Nov 2012 at 3:50
Attachments:
Another patch trying to match this case more strictly.
I'm not sure yet how to handle other 500 errors - just return an empty page?
Original comment by Steve8x8
on 3 Nov 2012 at 4:01
Attachments:
Yet another version, addressing the cdpf issue by removing the log request
(&lc=nn), and returning an empty string otherwise.
Original comment by Steve8x8
on 3 Nov 2012 at 6:05
Attachments:
Merged into branch - please test. I hope the fix won't affect other error
handling (expired cookies, wrong passwords, etc.) - will do some testing myself
later
Original comment by Steve8x8
on 5 Nov 2012 at 11:12
Some background for this particular cache:
GCN17F has been created back in 2005 when there were no reviewer "Publish" logs
yet (at least that's what the hamsters say), and obviously nobody has ever
found this cache. Actually nobody knows whether it's still there. (I will ask
the owner.)
I know that there are a few caches in extraordinary locations (polar areas,
Siberia, ocean depths) which might never have been found, but this is the first
one which turned up in a GeoToad search. You may estimate when the next similar
incident happens... Nevertheless, it's good to have reviewed the http
redirection handling, so this fix will go into trunk soon.
If you find similar caches without logs, please drop me a note.
Original comment by Steve8x8
on 10 Nov 2012 at 3:38
Not having found any side-effects, I merged the patch (which also fixes a
misleading debug message if a redirect goes to a https page) into trunk.
Original comment by Steve8x8
on 21 Nov 2012 at 10:46
In released version 3.16.3
Original comment by Steve8x8
on 30 Dec 2012 at 2:55
Original issue reported on code.google.com by
Steve8x8
on 3 Nov 2012 at 3:25