Caching of cgi urls

[Ken Case]

[Sorry about the long delay in responding:  I've been on leave.]

The subject line of this message actually contains a misnomer, as  
there's no such thing as a "cgi url".  Any URL may or may not return  
dynamic content (whether generated by a cgi mechanism or WebObjects  
or whatever), there is no mechanism for determining that from the  
URL.

If you want to make sure the browser doesn't cache your page, you  
can set the "Expires" header on the HTTP response to specify an  
expiration time equal to the "Date" header value.  (You can also use  
"Expires: 0", but that usage is deprecated by HTTP/1.1 though still  
supported.)

> For the most part I have everything working correctly, but I have
> found some situations where OmniWeb, upon accessing a url for a
> cgi script, displays a page of outdated data. This does not occur
> when I access the page via Netscape. I have also found that
> selected reload on the document does not help.

Reloading a page flushes it from OmniWeb's cache, so this would  
certainly seem to indicate that your web server is caching the page  
rather than OmniWeb.

> It occured to me that it could be the web server which is caching
> the page, rather than Omniweb; but if this is the case there most
> be some way for omni web to request a new version of the document
> in the way Netscape does.

When reloading a page, we send the "Pragma: no-cache" header.  This  
is the HTTP 1.0 mechanism for indicating to a web server that it  
should return a new version of the document, and according to the  
HTTP 1.0 and 1.1 standards the web server MUST NOT use a cached copy  
when responding to such a request.  I have no idea why your web  
server would be failing to obey this directive from OmniWeb but  
performing correctly with Netscape.

To diagnose this problem further, perhaps it would help to take a  
look at what we're sending and what the server is replying.  Are you  
using OmniWeb 3?  If so, bring up the OmniWeb Console and click the  
"Show HTTP Requests" switch, then reproduce your problem.

(If you're still using OmniWeb 2, you can get the same debugging  
information by using "dwrite OmniWeb DebugHTTP YES" in a Terminal  
window and restarting OmniWeb.)

Hope this helps,

				Ken