postdata

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

postdata

Koen Segers
Hi,

I'm wondering how the POSTDATA message generated by some websites is created.
And more importantly, if it is possible to set this generation in tapestry.

This is what the message says:
The page you are trying to view contains POSTDATA that has expired from cache.
If you resend the data, any action the form carried out (such as a search or
online purchase) will be repeated.
To resend the data, click ok. Otherwise, click cancel.

Greetz
--

Koen Segers

<[hidden email]>
<http://eddyvite.dyndns.org>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: postdata

Robert Zeigler
Koen Segers wrote:

> Hi,
>
> I'm wondering how the POSTDATA message generated by some websites is created.
> And more importantly, if it is possible to set this generation in tapestry.
>
> This is what the message says:
> The page you are trying to view contains POSTDATA that has expired from cache.
> If you resend the data, any action the form carried out (such as a search or
> online purchase) will be repeated.
> To resend the data, click ok. Otherwise, click cancel.
>
> Greetz


That's actually a browser-generated message, and not something specific
to any website or framework.

Robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: postdata

Koen Segers
On Wednesday 25 May 2005 20:01, Robert Zeigler wrote:
> That's actually a browser-generated message, and not something specific
> to any website or framework.

I'm not fully convinced. Using the same browser on several forms will not
always generate this message. It is actually rare to get this message ...

Greetz
--

Koen Segers

<[hidden email]>
<http://eddyvite.dyndns.org>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: postdata

Patrick Casey

        Web browsers support two kinds of interactions with a server, POST
and GET.

        Most interactions are GETS.

        When you submit a form though (or perform certain other actions
which cause javascript to submit a form for you), you use a POST which has
the advantage of not having a cap on the size of the transaction.

        Both POST and GET allow the web server to respond. Most first time
web app designers typically send a response page up in response to a POST
e.g.

1) User submits form
2) Server handles post
3) Server replies with "record saved" or something analogous

        This, in a nutshell, is wrong because ...

4) User pushes refresh.
5) Refresh causes browser to re-execute whatever action resulted in the
current page. Net result is it tries to "double post". Most modern browsers
try to prevent double posts by warning you with some variant on the
"refreshing requires resending POST data" message.

        The way around this is to implement the POST->redirect->GET web
pattern.

1) User submits form.
2) Server handles post.
3) Server replies with a redirect.
4) Browser catches redirect and does a GET for the 'record saved' page.

        Since in this pattern the ack page is the result of a GET, not a
POST, it's refresh (and back) button safe.

        --- Pat

> -----Original Message-----
> From: Koen Segers [mailto:[hidden email]]
> Sent: Wednesday, May 25, 2005 3:44 PM
> To: Tapestry users
> Subject: Re: postdata
>
> On Wednesday 25 May 2005 20:01, Robert Zeigler wrote:
> > That's actually a browser-generated message, and not something specific
> > to any website or framework.
>
> I'm not fully convinced. Using the same browser on several forms will not
> always generate this message. It is actually rare to get this message ...
>
> Greetz
> --
>
> Koen Segers
>
> <[hidden email]>
> <http://eddyvite.dyndns.org>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: postdata

Koen Segers
On Thursday 26 May 2005 02:23, Patrick Casey wrote:
> Web browsers support two kinds of interactions with a server, POST
> and GET.
>
> Most interactions are GETS.

Form or url interactions?
All our form interactions are POST...

>
> When you submit a form though (or perform certain other actions
> which cause javascript to submit a form for you), you use a POST which has
> the advantage of not having a cap on the size of the transaction.

OT: how is this different from GET?

>
> Both POST and GET allow the web server to respond. Most first time
> web app designers typically send a response page up in response to a POST
> e.g.
>
> 1) User submits form
> 2) Server handles post
> 3) Server replies with "record saved" or something analogous
>
> This, in a nutshell, is wrong because ...
>
> 4) User pushes refresh.
> 5) Refresh causes browser to re-execute whatever action resulted in the
> current page. Net result is it tries to "double post". Most modern browsers
> try to prevent double posts by warning you with some variant on the
> "refreshing requires resending POST data" message.
>
> The way around this is to implement the POST->redirect->GET web
> pattern.
>
> 1) User submits form.
> 2) Server handles post.
> 3) Server replies with a redirect.

You mean a cycle.activate("somepage"); ? isn't this what was wrong?

> 4) Browser catches redirect and does a GET for the 'record saved' page.

I want an automatic refresh of the form page, not of the "message" page...

>
> Since in this pattern the ack page is the result of a GET, not a
> POST, it's refresh (and back) button safe.

I think I don't get the point totally. Can you be a bit more precise?

Suppose you have redirected to a message page. If the user presses "back" it
isn't refresh (and back) button safe, is it?

Thx very much for the quick answer !!!
I appreciate it !

Greetz ;)

>
> --- Pat
>
> > -----Original Message-----
> > From: Koen Segers [mailto:[hidden email]]
> > Sent: Wednesday, May 25, 2005 3:44 PM
> > To: Tapestry users
> > Subject: Re: postdata
> >
> > On Wednesday 25 May 2005 20:01, Robert Zeigler wrote:
> > > That's actually a browser-generated message, and not something specific
> > > to any website or framework.
> >
> > I'm not fully convinced. Using the same browser on several forms will not
> > always generate this message. It is actually rare to get this message ...
> >
> > Greetz
> > --
> >
> > Koen Segers
> >
> > <[hidden email]>
> > <http://eddyvite.dyndns.org>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

--

Koen Segers

<[hidden email]>
<http://eddyvite.dyndns.org>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: postdata

Patrick Casey



> -----Original Message-----
> From: Koen Segers [mailto:[hidden email]]
> Sent: Thursday, May 26, 2005 4:07 PM
> To: Tapestry users
> Subject: Re: postdata
>
> On Thursday 26 May 2005 02:23, Patrick Casey wrote:
> > Web browsers support two kinds of interactions with a server, POST
> > and GET.
> >
> > Most interactions are GETS.
>
> Form or url interactions?
> All our form interactions are POST...

        Any time you push "submit" on a form it's a POST. Pretty much
anytime you push a link, it's a GET.
>
> >
> > When you submit a form though (or perform certain other actions
> > which cause javascript to submit a form for you), you use a POST which
> has
> > the advantage of not having a cap on the size of the transaction.
>
> OT: how is this different from GET?

        Post encodes the contents of the currently active form and sends it
to the server. POST interactions do not have a cap on the amount of data
that can be pushed, while GET interactions are limited by the MAX_URL size
(1024 bytes if memory serves).

>
> >
> > Both POST and GET allow the web server to respond. Most first time
> > web app designers typically send a response page up in response to a
> POST
> > e.g.
> >
> > 1) User submits form
> > 2) Server handles post
> > 3) Server replies with "record saved" or something analogous
> >
> > This, in a nutshell, is wrong because ...
> >
> > 4) User pushes refresh.
> > 5) Refresh causes browser to re-execute whatever action resulted in the
> > current page. Net result is it tries to "double post". Most modern
> browsers
> > try to prevent double posts by warning you with some variant on the
> > "refreshing requires resending POST data" message.
> >
> > The way around this is to implement the POST->redirect->GET web
> > pattern.
> >
> > 1) User submits form.
> > 2) Server handles post.
> > 3) Server replies with a redirect.
>
> You mean a cycle.activate("somepage"); ? isn't this what was wrong?

        Nope, I mean reply with a redirect instruction. In tapestry the way
to do that is to throw a pageredirectexception.


>
> > 4) Browser catches redirect and does a GET for the 'record saved' page.
>
> I want an automatic refresh of the form page, not of the "message" page...
>
> >
> > Since in this pattern the ack page is the result of a GET, not a
> > POST, it's refresh (and back) button safe.
>
> I think I don't get the point totally. Can you be a bit more precise?
>
> Suppose you have redirected to a message page. If the user presses "back"
> it
> isn't refresh (and back) button safe, is it?

        If you've redirected then sure it's safe because what you're
refreshing is the GET.

        Here's somebody elses more long winded explanation of the
post->redirect-> get pattern.

http://www.theserverside.com/patterns/thread.tss?thread_id=20936

>
> Thx very much for the quick answer !!!
> I appreciate it !
>
> Greetz ;)
>
> >
> > --- Pat
> >
> > > -----Original Message-----
> > > From: Koen Segers [mailto:[hidden email]]
> > > Sent: Wednesday, May 25, 2005 3:44 PM
> > > To: Tapestry users
> > > Subject: Re: postdata
> > >
> > > On Wednesday 25 May 2005 20:01, Robert Zeigler wrote:
> > > > That's actually a browser-generated message, and not something
> specific
> > > > to any website or framework.
> > >
> > > I'm not fully convinced. Using the same browser on several forms will
> not
> > > always generate this message. It is actually rare to get this message
> ...
> > >
> > > Greetz
> > > --
> > >
> > > Koen Segers
> > >
> > > <[hidden email]>
> > > <http://eddyvite.dyndns.org>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> --
>
> Koen Segers
>
> <[hidden email]>
> <http://eddyvite.dyndns.org>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: postdata

Koen Segers
On Friday 27 May 2005 01:18, Patrick Casey wrote:
> > Suppose you have redirected to a message page. If the user presses "back"
> > it
> > isn't refresh (and back) button safe, is it?
>
>         If you've redirected then sure it's safe because what you're
> refreshing is the GET.

I just tried it this way:
Users.remove(context, getUserName());
visit.setMessage("User '"+getUserName()+"' successfully removed.");
//cycle.activate("Message");
throw new PageRedirectException("Message");

The commented statement is the one I used before.

When I hit the back-button I see the incorrect form.
So this pattern doens't help me get rid of my problem...

>
>         Here's somebody elses more long winded explanation of the
> post->redirect-> get pattern.
>
> http://www.theserverside.com/patterns/thread.tss?thread_id=20936

Exactly,
<quote>
The only thing that have to be dealt with is intentional form resubmitting
which happens when a user returns to the first page using Back button and
submits form again. This should be checked by controller and a model and is
out of scope of this pattern.
</quote>

So we need to work with the hidden field for data synchronisation check...
Isn't it?

Greetz

--

Koen Segers

<[hidden email]>
<http://eddyvite.dyndns.org>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]