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
