Sorry, but...... cookies? I never tried it too much, but I think that
cookies have to works within windows. I haven't time to try it right
now.
-----Original Message-----
From: A mailing list about Java Server Pages specification and reference
[mailto:[EMAIL PROTECTED]] On Behalf Of Duffey, Kevin
Sent: Tuesday, August 14, 2001 3:24 PM
To: [EMAIL PROTECTED]
Subject: Re: User hits STOP button, then submits again..how to prevent
thi s or provide a solution?
Ok..tried it. Doesn't work. When you use File -> New -> Window, or
right-click and use Open link in new window, it continues to show the
JSP page it came from..and not null. That is too bad..that would have
been a kewl way to control it. Wonder if there is another method to do
this with.
> -----Original Message-----
> From: Jon Garry [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 14, 2001 2:10 AM
> To: [EMAIL PROTECTED]
> Subject: Re: User hits STOP button, then submits again..how to prevent
> thi s or provide a solution?
>
>
> The HTTP_REFERER environment variable gives the URL of the page you
> was viewing before the one you are currently viewing.
>
> Therefore, if you do a 'new window', there would be no refering page,
> so HTTP_REFERER would be blank/null but if you were browsing
> round a site then
> HTTP_REFERER would always contain a URL.
>
> I think the best way of trying this is to write some code. Write a few
> interlinking JSPs to display the HTTP_REFERER and then try doing a new
> window - hopefully it should be blank!
>
> -----Original Message-----
> From: Kevin Duffey [mailto:[EMAIL PROTECTED]]
> Sent: 14 August 2001 10:09
> To: [EMAIL PROTECTED]
> Subject: Re: User hits STOP button, then submits again..how to prevent
> thi s or provide a solution?
>
>
> I have never looked into that to be honest. However, I know when I am
> on one page, and I open a new window, it shows me the same page in
> the new window.
> So I am not sure how the HTTP_REFERER would be blank...can
> you explain how
> you think this might be?
>
> > -----Original Message-----
> > From: A mailing list about Java Server Pages specification and
> > reference [mailto:[EMAIL PROTECTED]]On Behalf Of Jon Garry
> > Sent: Tuesday, August 14, 2001 1:20 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: User hits STOP button, then submits again..how
> to prevent
> > thi s or provide a solution?
> >
> >
> > Kevin,
> >
> > Just an idea, but to stop someone opening up a new window, could you
> > not check the HTTP_REFERER attribute?
> >
> > If a new window has been opened, it should (as far as I am aware) be
> > blank whilst your 'legitimate' window would have some value
> in there -
> > the URL of the old page.
> >
> > Jon
> >
> > -----Original Message-----
> > From: Duffey, Kevin [mailto:[EMAIL PROTECTED]]
> > Sent: 13 August 2001 21:24
> > To: [EMAIL PROTECTED]
> > Subject: User hits STOP button, then submits again..how to prevent
> > this or provide a solution?
> >
> >
> > Hi al,
> >
> > I am almost positive the answer is no, but I thought I'd
> see if anyone
> > has come up with a solution. All too often, we have some users that
> > submit a large query, then hit the STOP button on the browser, then
> > change something and submit again. In the meantime, their original
> > query is still executing on the server-side. Sure..Orion throws an
> > exception when it tries to send the response back and the connection
> > to the browser is gone. But I am wondering if there is any
> way at all
> > to just kill that particular request. Like..is there some
> way the app
> > server or web server can send pings every say, 100ms to the
> browser to
> > make sure its connection is still alive..and if
> > not, just kill the request in some manner. Perhaps by
> having a special
> > interface that an application can implement, so that a particular
> > method can be called if the server detects that the connection to
> > the
> browser is dead
> > before the response has gone back. In this way, that method
> call can get
> > ahold of the session, and perhaps get ahold of a connection
> being used,
> > close it, etc.
> >
> > Ofcourse, you can use some client-side javascript to "disable" a
> > button after its been clicked. We have done this, and we
> also inserted
> > a "transition" page in particular areas where long queries might
> > occur. In this case, the user sees an animated gif and a
> message that
> > tells them not to hit stop or back. Ofcourse..you're still going to
> > get those users that do this. My personal opinion is that
> if they call
> > in, we tell them they are stupid, they should unplug their computer
> > and quit their job because they can't follow instructions.
> > Ofcourse..that wont fly, especially if they are a big money client.
> > Besides, its ethically wrong to screw
> your clients over.
> > ;)
> >
> > So, one possible idea I have had is to do the following.
> Each user has
> > a session when they log in. Upon any request, a "flag" is set in the
> > session of that user, indicating a transaction is starting. If the
> > user hits STOP, then submits while that transaction is
> still going on,
> > the server will see the flag is set, and send back a response
> > indicating that a transaction is currently happening and
> they have to
> > wait for it to be done before another submit can occur. There is a
> > plus side to this..it prevents any user to doing more than
> one thing.
> > The down side is, it is possible using the File
> > -> New -> Window to open up another window with the same
> > -> cookie/sessionID
> > and the user could actually go to a different module and do
> MORE work
> > at the same time. This would allow, for example a large query to be
> > performing in one module and they could go do some work in another
> > module. My method of a flag would prevent this type of
> > multiple-module capability.
> The solution,
> > ofcourse is to allow one flag per module, thus only one
> transaction per
> > module could be performed, which is what I intend to
> implement to at least
> > keep the user experience at a satisfactory level while
> preventing tons of
> > form submissions from inundating the server.
> >
> > So anyone had this experience and resolve it in some manner?
> >
> > Thanks.
> >
> > ==================================================================
> > =========
> > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> > JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body:
> > "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be
> > found at:
> >
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
> > ----------------------DISCLAIMER-----------------------
> > The information contained in this e-mail and any files transmitted
> > with it are confidential and intended for the addressee
> only. No other
> > person is authorised to copy, forward, disclose, distribute
> or retain
> > this email in any form. If you have received this e-mail in error
> > please notify the originator or send an e-mail to
> > [EMAIL PROTECTED] This e-mail and any associated
> > attachments have been scanned for viruses prior to dispatch, however
> > Emap Performance and its subsidiary companies accept no liability
> > for any losses resulting from infected e-mail transmissions.
> >
> > Please note any views expressed may be those of the
> originator and do
> > not necessarily reflect those of this organisation.
> > --------------------------------------------------------
> >
> > ==================================================================
> > =========
> > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> > JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body:
> > "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be
> > found at:
> >
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
> >
>
> ==============================================================
> =============
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with
> body: "set
> JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found
> at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
> ----------------------DISCLAIMER-----------------------
> The information contained in this e-mail and any files transmitted
> with it are confidential and intended for the addressee only. No other
> person is authorised to copy, forward, disclose, distribute or retain
> this email in any form. If you have received this e-mail in
> error please notify the originator or send an e-mail to
> [EMAIL PROTECTED] This e-mail and any
> associated attachments have been scanned for viruses
> prior to dispatch, however Emap Performance and its
> subsidiary companies accept no liability for any losses
> resulting from infected e-mail transmissions.
>
> Please note any views expressed may be those of the originator and do
> not necessarily reflect those of this organisation.
> --------------------------------------------------------
>
> ==============================================================
> =============
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body:
> "set JSP-INTEREST DIGEST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
========================================================================
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set
JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found
at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
