Random URLs for pages with dynamic content .. better way?

locked_user sundialsvc4 has asked for the wisdom of the Perl Monks concerning the following question:

I am dealing with a legacy application that always issues URLs with a pure-random string as part of the URL. The purpose of this, obviously, is to defeat client-side caching of those pages, which contain dynamic content. But I am trying to judiciously increase the ability of browsers to use their local caches, because the pipes between are sometimes very narrow. (There is no advertising or any other such web-garbage...)

Using Apache directives, the site now specifies an expiration-date for the content (an hour or so), and it includes an ETag using the FileETag directive.

I would like to hear opinions of whether the random string can be removed from the URL, and what the positive and negative implications of doing such a thing might be. I want the client-side cache behavior to be as efficient as it is possible to be now (you may assume “fairly recent browsers...”), but of course, not stale. The code is many, many years old, and I think that it is still using very out-of-date practices ... “intentionally caching nothing, and paying a dear price.” But I seek the wisdom of the Monks.

Replies are listed 'Best First'.
Re: Random URLs for pages with dynamic content .. better way? by JavaFan (Canon) on Jul 18, 2011 at 13:51 UTC
....but of course, not stale. Unless you are more detailed on what you consider stale, no sensible answer can be given here. Any person giving you advice would just be posting personal preference - as your post does not give enough information to give even a remotely sane advice. But pray me, what has this to do with Perl? Surely, your question is utterly devoid on any dependency of the language in which you've written the business logic of your site?	[reply]
Re: Random URLs for pages with dynamic content .. better way? by flexvault (Monsignor) on Jul 18, 2011 at 14:20 UTC
There is a lot about your problem that isn't provided! But here goes . . . I would change the 'random' number to a positive incrementing number. I keep a variable ($Account{"UPDATE"}) as part of the persistent information about each user. Each time you send information to the server/browser, increment the $Account{"UPDATE"} by 1. Periodically you can reset the value to the start value(like once a year). This seems to work on most browsers. If you don't keep persistent data about the user, then keep a site counter ($Site{"UPDATE"}). (Note: Some browsers treat a lower(random) number different than a higher sequential number) Also set the expiration-date for about 10 seconds in the future. If a user is trying to get new information and the information is available, you want the user to get the newest information. On some browsers, I have hit the 'refresh' button without getting the new info. If you can tell that no new information is available, you can send a response to indicate that: `## Next line tells the server/browser that nothing has changed! print "Status: 304 No response\r\nContent-Type: text/html\r\n\r\n";` [download] That is a great way to improve bandwidth utilization! You may want to look at the Memoize Module (it's core on later releases of perl) to help reuse content that doesn't change. For HTML, I compress the data to be saved. 40KB easily reduces to less than 1KB. If I answered everything but your problem, maybe an example would help. Good Luck! "Well done is better than well said." - Benjamin Franklin	[reply] [d/l]
Re: Random URLs for pages with dynamic content .. better way? by locked_user sundialsvc4 (Abbot) on Jul 18, 2011 at 17:37 UTC
Let me elaborate a little on my post and the reasons for posting it. And, if the consensus is that the query is not appropriate, then let it be withdrawn forthwith with no objections from me. This site will be visited by 3,000 to 5,000 users simultaneously, and, right now, it serves every shred of information to every request every time ... using the random string in the URL specifically to ensure that no page is ever cached. I regard the “random string in a URL” trick as being unnecessary, given the now-introduced use of `Cache-Control` and `ETag` headers. But I wanted to “bounce” that opinion off of the heads of what I calculate would be the most qualified group of colleagues that I know of, anywhere. I say again ... if anyone feels that the thread is inappropriate to have been posted or approved, then, let the NodeReaper do his solemn duty, without further delay and with my cordial apologies.