How to mark not-cacheable?

How can I put "not-cacheable" in some of my pages http headers, so that when
the user uses the Back button to return to them, the browser will not
present a cached version?

Thanks,

Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sophie,

Look for senders of #doNotCache. That should be default behavior.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of itsme213
> Sent: Tuesday, January 15, 2008 11:11 AM
> To: [hidden email]
> Subject: [Seaside] How to mark not-cacheable?
>
> How can I put "not-cacheable" in some of my pages http headers, so
that
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> "Boris Popov" <[hidden email]> wrote in message
> Look for senders of #doNotCache. That should be default behavior.

Thanks.

A related question: is it possible to manually "expire" older versions of a
page (which, I assume, means a version of the complete component tree that
was used to render that page)? How?

(I'm not sure if I am doing this part the right way, really ... for my app
(and current skills) I'd be happier without "Back" :-)

- Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sophie,

That's what #isolate: is for, try googling for "seaside isolate".

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
of
> a
> page (which, I assume, means a version of the complete component tree
that
> was used to render that page)? How?
>
> (I'm not sure if I am doing this part the right way, really ... for my
app
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris,

On Jan 15, 2008 5:48 PM, Boris Popov <[hidden email]> wrote:
> That's what #isolate: is for, try googling for "seaside isolate".

I did that search, and found that isolate: works fine if what is
isolated is the call to another component, and not an action or a
render of the same component.

For example:

In component A I remove an object from a collection presented as a
list, if I go back to the page where the component was shown in the
screen, and click the "delete" anchor (again), I would get an "object
not found" error, because the callback was already executed, and the
collection doesn't have the deleted item anymore.

Within component A, I've found no way of invalidating this kind of scenario.

Best regards,

--
Esteban A. Maringolo
[hidden email]
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Esteban,

Check out WATransactionTest and point your browser to it via "browse -
tests - alltests - transaction",

1. It should be in "Before parent txn" state
2. Click OK until you get to "Outside child txn"
3. Now hit back in your browser and hit OK again

Isn't that the kind of expiry you are looking for?

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > How can I put "not-cacheable" in some of my pages http headers, so that
> > when the user uses the Back button to return to them, the browser will not
> > present a cached version?
>
> Look for senders of #doNotCache. That should be default behavior.

Please note that marking a page's "Cache-Control" header attribute as
"no-cache" (which is what #doNotCache does) *should* not influence a
browser's back-button behaviour. (Similarly with setting "Pragma" to
"no-cache" for HTTP 1.0 or setting the date header "Expires" to 0.)

The misleading thing is that Internet Exploder incorrectly interprets
these directives and mistakenly equates caching and the history
functionality. Other (standards-compliant) browsers may not.

Have a look at http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Boris,

On Jan 15, 2008 7:22 PM, Boris Popov <[hidden email]> wrote:
> Esteban,
>
> Check out WATransactionTest and point your browser to it via "browse -
> tests - alltests - transaction",
[SNIP]
> Isn't that the kind of expiry you are looking for?

Unfortunately, not exactly.

The WATransactionTest works in combination with (is composed by) a
WANestedTransaction, which is a WATask. The isolation in such task
works because it has a defined workflow (in the #go method), which in
each step of the flow it calls another component (via #inform:) inside
of a transaction decorator.

Suppose this example:
WAComponent subclass: #WATransactionExample
        instanceVariableNames: 'collection'.

WATransactionExample>>#initialize
        super initialize.
        collection := OrderedCollection with: 'Foo' with: 'Baz'

WATransactionExample>>renderContentOn: html
        html unorderedList
                list: collection;
                callback: [:value | collection remove: value]

The first time you render the component, it will show a list with two
items, Foo and Baz, if you click on any of them, it will remove them
properly and then render itself again with only one item (the one you
didn't remove).

But, and here comes the problem, if you go back the list will show
both elements, if you attempt to remove the already removed element,
you'll get a walkback (in this case reporting an NotFoundError).

This example is trivial, because in this case one can backtrack the
collection, but if the component interacts with a database or anything
which can't (or doesn't want) to be backtracked, the
WATransactionDecoration doesn't fit this needs.

Another option would be to associate the callback with a render pass,
or something similar.
I've read that tweaking the WALRUCache this could be achieved,
however, no one said how :-).

Best regards,

--
Esteban A. Maringolo
[hidden email]
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> But, and here comes the problem, if you go back the list will show
> both elements, if you attempt to remove the already removed element,
> you'll get a walkback (in this case reporting an NotFoundError).

WATransactionExample>>renderContentOn: html
       html unorderedList
               list: collection;
               callback: [:value | collection remove: value ifAbsent: []]

Works perfectly ;-)

> Another option would be to associate the callback with a render pass,
> or something similar.

This has always been done like this.

> I've read that tweaking the WALRUCache this could be achieved,
> however, no one said how :-).

I think the cleanest solution would be to make it an option for a
callback to only trigger once. Should be fairly simple to do so.

There are two questions remaining:

- What happens if you try to trigger such a callback the second time?
Do you specify another callback that should be triggered instead? Do
you display an error message? Do you regenerate the current page? Do
you redirect to the latest page?

- Why does a [fundamental|unnecessary]? feature request comes after 7
years of application development with Seaside? Is it because you have
to take precaution anyway, just in case somebody else deleted the
element from a different session? Is it because the remove
functionality should be part of the model and handle this situation?

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Jan 16, 2008 10:28 AM, Lukas Renggli <[hidden email]> wrote:
Cheater! :-)

> > Another option would be to associate the callback with a render pass,
> > or something similar.
> This has always been done like this.

Yeap, you're right.

> > I've read that tweaking the WALRUCache this could be achieved,
> > however, no one said how :-).
> I think the cleanest solution would be to make it an option for a
> callback to only trigger once. Should be fairly simple to do so.

Great, how much simple?

> There are two questions remaining:
 > - What happens if you try to trigger such a callback the second time?
> Do you specify another callback that should be triggered instead? Do
> you display an error message? Do you regenerate the current page? Do
> you redirect to the latest page?

The latest would be the safer option.
Another would be to handle this in the same way as #isolate: does.

> - Why does a [fundamental|unnecessary]? feature request comes after 7
> years of application development with Seaside? Is it because you have
> to take precaution anyway, just in case somebody else deleted the
> element from a different session? Is it because the remove
> functionality should be part of the model and handle this situation?

Well... actually it is handled at the domain level, raising an special
kind of exception, for the particular case (concurrency problems
mostly). But that kind of problems arise very rarely, and we use an
optimistic approach to concurrency in all of our traditional apps
(with peaks of 200 concurrent users). Leaving such cases to be handled
by an special "general" handler.
What I want is to avoid this kind of problems coming from the same
user, disabling the previous pages callbacks would fit now. If
collisions start to grow, then we will focus on solving them at
another level.

Thanks.

Best regards,

--
Esteban A. Maringolo
[hidden email]
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"Esteban A. Maringolo" <[hidden email]> wrote in message
>> There are two questions remaining:
> > - What happens if you try to trigger such a callback the second time?
>> Do you specify another callback that should be triggered instead? Do
>> you display an error message? Do you regenerate the current page? Do
>> you redirect to the latest page?
>
> The latest would be the safer option.
> Another would be to handle this in the same way as #isolate: does.

I would prefer to regenerate, so the page looks at least similar to what he
had previously (except some content has changed due to non-backtrackable
state change on the server). A redirect page could be a completely different
looking page, I think, so would be diorienting for "Back". It would be up to
page-generation to correctly render according to whatever it considers
backtrackable + non-backtrackable state at the time of (re)generation.

Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"itsme213" <[hidden email]> wrote

> I would prefer to regenerate

In fact, is there any way to do this re-generation right when the back
button is pressed, as opposed to after the user clicks on the backed-up
page? (I am under the impression that "Back" requires a server request if
the earlier header said do-not-cache, so perhaps this is possible).

Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>>>>> "itsme213" == itsme213  <[hidden email]> writes:

itsme213> In fact, is there any way to do this re-generation right when the
itsme213> back button is pressed, as opposed to after the user clicks on the
itsme213> backed-up page? (I am under the impression that "Back" requires a
itsme213> server request if the earlier header said do-not-cache, so perhaps
itsme213> this is possible).

I think you were told earlier that "do not cache" has NOTHING to do with
compliant browsers.  It's strictly for caching web proxies.  Do not confuse
IE's misinterpretation of the header with what it was intended for.

NOTHING stops a web browser from caching a web page and presenting it to the
user a second time once the "back" button is pressed, without *any* net
traffic.  This is as it should be.  It's your job (as was already pointed out)
to ignore any callbacks that no longer make sense, either because of the
current conversation *or* some other conversation elsewhere that invalidates
the callback as well.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"Randal L. Schwartz" <[hidden email]> wrote in message
> Do not confuse
> IE's misinterpretation of the header with what it was intended for.

Thanks for the further explanation. It wasn't IE's misinterpretation of the
header, it was mine :-) I'm not accustomed to thinking of concurrency and
related issues as many of you clearly are ...

Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > Do not confuse
> > IE's misinterpretation of the header with what it was intended for.
>
> It wasn't IE's misinterpretation of the header, it was mine :-)

Sadly, it's IE's misinterpretation that causes so many people to
misinterpret how it's *supposed* to work. Stop using IE (except
perhaps in rare cases for testing) and you should be fine in no time
;-)
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside