caching header question

[Xuefer]

is it possible to make browser load cached content when user press "back" button
but request content from server when user click on url(same url)

[justageek]

Only by changing the url each time. At least that I know of.

[daisho]

justageek is right. Think of a URI/URL as an object. It does not matter how you get to that object (ie backbutton, link, post, redirect) the properties are still the same.

daisho,

[Xuefer]

did u guys notice that, google did the trick?
when we click on page 1 2 3 ..
pages always reload from server
but when we press back/forward button it's immediately load it from local cache, which is very fast

i've tested it on opera and ie

it's not the same as *.html files, cause while static html is cached, clicking on a link will load cached content, not request a new one

[justageek]

I'm not sure how they do it then. I suppose it's possible that they don't return a possible cache code. Maybe the code is always a 200. I suppose I'll have to turn my packet trace on and find out someday.

[daisho]

They could be telling the browser the page is unchanged if the browser sends and ETag or If-Modified-Since header. Again this does not have much to do with the "Back" button so to speak but logic on the server side.

daisho.

[Xuefer]

if u use a sniffer or www.blunck.info/iehttpheaders.html (this is not my own, but just a tool website, hope it's ok to post this url)
iehttpheaders
it show headers when IE request to server
it's exactly same as what i explained
not the etag helping to do this

[edited by: jatar_k at 6:59 pm (utc) on Sep. 15, 2003]
[edit reason] delinked [/edit]

[daisho]

Exactly. This is not happening on your client side but on the server side. ETag if the server sets it and the browser has it cached will be in the request. Google may be looking at the ETag and sending a "Not Modified" back to the browser and therefore the browser will pull the object from it's cache rather than getting it from google again.

You may also want to look at the HTTP RFC which explains how the protocol works.

daisho.

[Xuefer]

u haven't sniff it

[Xuefer]

default page
HTTP/1.1 200 OK
Date: Tue, 16 Sep 2003 02:07:56 GMT
Cache-control: private
Content-Type: text/html
Content-Encoding: gzip
Server: GWS/2.1
Content-length: 1536

page 2
HTTP/1.1 200 OK
Date: Tue, 16 Sep 2003 02:08:33 GMT
Content-Encoding: gzip
Transfer-Encoding: chunked
Server: GWS/2.1
Content-Type: text/html
Cache-control: private

ETag is useless for google, waste cpu time to calc it, low hit

[Xuefer]

so.. anyone has idea on "Cache-control: private" with no "Last-Modified"?
i've tested on opear7 ie6
but is it cross most browser?

[justageek]

Sorry. I'm stumped.

[daisho]

Cache-Control: Private tells caching servers NOT to cache the content. Therefore Last-Modified and other cache headers really are not important.

daisho

[Xuefer]

but how about the behavior of the client?
is there any client won't request when user click on link?

hrm,...
my goal is to make sure the content is fresh if user click on the link, but able to navigate back/forward as fast as possible

[daisho]

Then you ont he server side should set Last-Modified and/or and ETag.

Once set if the client has any type of cache for that object it will make the reqest sending you the ETag and/or If-Modified-Since headers.

On the server side analyse them. If you determine that the client has a current copy then simply send back "304 Not Modified" rather than a "200 OK" followed by the content. That way you tell the client that it's object is still fresh and do don't waste the time/bandwidth to send the page. The client will then display out of it's cache.

Again the HTTP RFC is a *GREAT* place to start. Read about the different possibilites and behaviours and then code to your hearts content.

daisho.

[Xuefer]

thanks, i've already read it, however, it's just a standard, each browser has its own implements and improvements

but there maybe a little mistake:
when a content has "last-modified", IE don't even request the server if user click on link in the 2nd time, unless user press f5 to refresh page

that's how IE handle *.html(with its headers)

[daisho]

You say "It's just a standard". That's the point. You have no control if the client browser decides *NOT* to support it. The only thing you can do it code your program to support everything possible and trust that the browser will also.

daisho.

[justageek]

I suggest then that you use the changing of the url each time then. Seems to work all the time for me anyway.

JAG