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
