After a long testing on local server I finally upgraded my production site. At the moment it's NB 2010-12-14. Everything was fine on my desktop but on line things are often different.

The problem is probably due to server caching or something similar but it was not present with the old version of zenphoto (1.2.5_RC2).

Description:
If I display an image page from an album link the image is in its album context.
Then I make a search that give me the same image as a result and I display that image from the search page link. Now the image is still in his album context. To see it in a serch context I need a refresh in browser. The vice versa is absolutely the same.

Is there something I can do, with htaccess for instance, to solve this problem?
The link to my site is in my forum profile.

Context for searches is stored in either cookies or session variables depending on the setting of "enable gallery sessions". So, if the latter is set, your server is not supporting sessions if not, the browser is not getting/storing the cookie.

I'm not using sessions and the cookies are stored in browser.
They are there, zenphoto_search_params (with the correct search parameters) and zenphoto_last_album, but looking closer it seems that they are not always added and deleted at the proper time.
I'm really lost, any hint about what can be the cause?
Can you check in your browser?
For instance search the word "ricerca" follow the link to the 4th image and then try to display the same image from the album 'fuori catalogo':
http://www.antonioranesi.it/Fuori%20Catalogo/
I've used firefox, IE8 and opera, same behavior

So, I guess the problem is that the search context is actualy NOT being cleared. But unfortunately I think you have come up with a scenerio that cannot be made to work. (I also suspect it is not a common one.)

Zenphoto saves the search context in a cookie. Then when you visit another page it compares the page to see if it is within the search context. If it is, search context is preserved. If not search context is cleared. WEB pages are stateless except for cookies (or sessions) so we really do not know how the link was arrived. We can only make intellegent guesses.

The most strange thing is that this worked whit the old version of zenphoto on the same remote server and it works without problems in my local server with this version of zenphoto.
Of course I'm not pretending to open the link I provided from an external page, but from inside the album 'fuori catalogo'.
That's where it's strange if the cookie is not cleared after the album page is served.

Well, you were on a previous much older version of Zenphoto. There have been issues with search context not being properly preserved. Off hand I would not know which releases have fixed them.

That's where it's strange if the cookie is not cleared after the album page is served.

Well, if it were cleared, then visiting an image within that album would no longer be within the search and thus not have the proper search breadcrumbs.

But the bottom line is that if you are in a search context and link to an album/image that is present in that context the search context will be preserved as the most reasonable assumption is that you got to the new location from a link on the page that was in the search context.

So the links you have placed on the page that proport to be direct album links will not work as you intend if that album is also part of the search results. Sorry, but that is just the way it works.

If you want to change the behavior you would have to add javascript to those non-search album links that cleared the search cookie.

I'm still unsure about the nature of the problem. I have to say again that on my local server with the same version of php, apache and zenphoto everything works as I expect. The only(?) difference is the platform that is windows on local and linux on remote. That's why at the beginning I was wondering if the problem is in some way of caching files by the remote server that is different from the local one (or a different behavior of the browser?). Beside this I've noticed that if I change the main theme for the gallery and then visit a page already visited with the old theme, the old theme is displayed until a manual refresh is done. This behavior is may be normal but again, is not the same on local server.

A thing I don't understand in your explaination is the reason why the cookie is not cleared when you visit the album page. If you are in an album page, called from the menu or from the album thumb link, it means that you are not anymore (or at least that you don't want to be) in search context.

I know that my theme forces a bit the dynamic album behavior, but I made all the tests with the standard zenpage theme and the results are the same. So I still think that the normal zenphoto behavior is more similar to what I expect it to be. I'm sure you don't want that an image clearly called from an album page is then displayed in a search context.

Yes!
It turned out that there is a caching issue on my remote server.
I don't know exactly what are all the conseguences of what I did, but changing the header directive of image.php and album.php in my theme seems to have solved the problem. The new directive, to prevent apache from caching the pages is:

header("Cache-Control: no-store, no-cache, must-revalidate, pre-check=0, post-check=0, max-age=0");

Just found this code googling around, my knowlege is too small to understand it all.

A thing I don't understand in your explaination is the reason why the cookie is not cleared when you visit the album page.

Well, the thing I am failing to communicate to you is that there is no such thing as a link "called from the album menu or from the album thumb link" WEB applications have no state other than cookeis that they store. The have no way of knowing how a link was created unless that information is imbedded somehow in the link.

So when a page loads it examines the search cookie to see if it (the page) is a within that search. If so it presumes that the search context is still valid.

But of course, caching errors make all bets off

No, it was clear to me that the only way in which zenphoto can choose the context is given by the cookies. That's why I tought it was better to clear the search cookie when in an album page. My use of 'called from' was a bad way to say that.

My fault was I didn't get that a given album could be between the search results so the cookie could be still needed when in an album page, because I disabled the option to have albums in search results a long time ago.

Please be aware that is not my intention to be polemic in any way. I'm just trying to be helpfull.

I guessed since the beginning that the main problem was a cache problem, as can be seen looking at the title of this topic.

That said I started looking at cookies behavior because you made me notice that the search cookie is actualy NOT being cleared.
That's not true anymore. Once the cache problems have been solved, if I visit an album page the search cookie IS cleared, unless the album itself belongs to search results (I enabled the option to check). That's perfect!

I'll stop arguing on that, instead I'll make more investigation on the header directive and the chache problems.
If this problem is present in my server setup it can affect many other installations of zenphoto. At least the ones mantained by the same hosting company.
The rough solution I used is also preventing the browser to cache pages for its own navigation history.

I think we did get your intention right, it is just sometimes a little hard to get into other's thoughts.

I know it is hard, expecially because many of us 'users' are not experienced in coding nor in coding slang, so we often use wrong terms. Beside this many people (like me) are not using their native language.
I have to say again that the efforts of all zenphoto staff to follow and understand all the questions in this forum is really higly appreciated.

Just to note, English is not my native language, too, so I can understand that of course.

Now I have a better picture of what happens on the server of my hosting company. The difference with my local installation is that they have expires_module enabled in apache, with a setup that returns the followings in response headers:

Last-Modified: Thu, 23 Dec 2010 06:47:16 GMT
Cache-Control: max-age=172800
Expires: Sat, 25 Dec 2010 06:47:16 GMT

I suppose it means that a browser uses its cached pages for 2 days without ask for a fresh copy, is that so?
As told before I have overrided the cache control, before I knew what it was, adding the header reported a few post above.
That is not a problem for me because my site is mostly a portfolio and I will never have many simultaneous visitors on it.
On the other end Zenphoto can be used by sites with high traffic rate, where a well setted up cache control system can help to have good performances without pay a fortune for web hosting.

Is there something that can be done about it?

Well, execpt for adding hte headers probably not since it is a server configuration. You could try to use the html_meta_tags plugin as that can set the same cache control via html `<meta>` tags. Not sure if these really cause to override the setting of the server, but at least it will override the cache of the browser.

In any case be aware that on some hosting the normal behavior of zenphoto can be totally broken by their Cache-Control settings.
Have you never had similar reports from other users?
Should I think that my hosting company is somehow cheating to decrease server load?

To my knowledge you were the first to report this issue ever (and I am on this project for over 3 years now) and I never encountered myself so far.

I don't think they are "cheating" but maybe a little over optimizing (I am no server expert though). However, you found a way to workaround. But I suggest to talk with them about this issue as well. If they don't know they can't change things. And maybe it even affects others CMS as well.

It would be quite easy to add the header you use via a plugin that attaches to the admin_head and theme_head filters.

Which of course will become available in the coming 1.4 release (or is already in the nightly)..;-)

Great idea sbillard!
Do you know if there is a way to let the browser cache at least his internal navigation? I mean, when you use browser's buttons to navigate in history.