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
