Re: response.sendRedirect()
Sorry, I did more test about the problem. I have one JSP(jspa) and (jspb) from jsp I do an include of jspb and from jspb I have a sendRedirect(www.google.com). If I invoke to http:///../jspa.jsp it doesn't work, but If I invoke directly to http://..//jspb.jsp It works ok. best regard Ben Souther ([EMAIL PROTECTED]) escribi? Without seeing the rest of your code, I'll guess that the problem is that you've started the relative link with a /. Try without it. If you have to back up a directory use ../jknopkn/prueba.jsp. On Wed, 2004-10-06 at 11:11, Pablo Carretero Sánchez wrote: Hi, I don't test in other Tomcat version. I'm trying a sendRedirect() in one JSP. And it doesn't work. The code is: response.sendRediredt(/jknopkn/prueba.jsp); QM ([EMAIL PROTECTED]) escribió: On Wed, Oct 06, 2004 at 04:38:54PM +0200, Pablo Carretero S?nchez wrote: : I have a urgent problem response.sendRedirect() in Tomcat 5.0.27. : : It doesn't work in my appl. What, specifically, doesn't work? Did this same code work in a previous version of Tomcat 5.0.x? etc, etc. We're all pretty sharp here, but I don't think any of us are clairvoyant. ;) -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- __ Pablo Carretero Sánchez Cygnux Arquitecto de Software Pintor Velazquez nº 3 Esc Izq 7º B 28932 #8211; Móstoles (Madrid) Movil: +34 699929150 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect()
Are you getting any error messages in your log files? In your browser window? It sounds like your trying to call sendRedirect after you've already started sending output to the browser. Try moving the include to the very top of the jspa page. On Thu, 2004-10-07 at 03:04, Pablo Carretero Snchez wrote: Sorry, I did more test about the problem. I have one JSP(jspa) and (jspb) from jsp I do an include of jspb and from jspb I have a sendRedirect(www.google.com). If I invoke to http:///../jspa.jsp it doesn't work, but If I invoke directly to http://..//jspb.jsp It works ok. best regard Ben Souther ([EMAIL PROTECTED]) escribi? Without seeing the rest of your code, I'll guess that the problem is that you've started the relative link with a /. Try without it. If you have to back up a directory use ../jknopkn/prueba.jsp. On Wed, 2004-10-06 at 11:11, Pablo Carretero Snchez wrote: Hi, I don't test in other Tomcat version. I'm trying a sendRedirect() in one JSP. And it doesn't work. The code is: response.sendRediredt(/jknopkn/prueba.jsp); QM ([EMAIL PROTECTED]) escribi: On Wed, Oct 06, 2004 at 04:38:54PM +0200, Pablo Carretero S?nchez wrote: : I have a urgent problem response.sendRedirect() in Tomcat 5.0.27. : : It doesn't work in my appl. What, specifically, doesn't work? Did this same code work in a previous version of Tomcat 5.0.x? etc, etc. We're all pretty sharp here, but I don't think any of us are clairvoyant. ;) -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect()
On Wed, Oct 06, 2004 at 04:38:54PM +0200, Pablo Carretero S?nchez wrote: : I have a urgent problem response.sendRedirect() in Tomcat 5.0.27. : : It doesn't work in my appl. What, specifically, doesn't work? Did this same code work in a previous version of Tomcat 5.0.x? etc, etc. We're all pretty sharp here, but I don't think any of us are clairvoyant. ;) -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect()
Hi, I don't test in other Tomcat version. I'm trying a sendRedirect() in one JSP. And it doesn't work. The code is: response.sendRediredt(/jknopkn/prueba.jsp); QM ([EMAIL PROTECTED]) escribió: On Wed, Oct 06, 2004 at 04:38:54PM +0200, Pablo Carretero S?nchez wrote: : I have a urgent problem response.sendRedirect() in Tomcat 5.0.27. : : It doesn't work in my appl. What, specifically, doesn't work? Did this same code work in a previous version of Tomcat 5.0.x? etc, etc. We're all pretty sharp here, but I don't think any of us are clairvoyant. ;) -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- __ Pablo Carretero Sánchez Cygnux Arquitecto de Software Pintor Velazquez nº 3 Esc Izq 7º B 28932 #8211; Móstoles (Madrid) Movil: +34 699929150 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendRedirect()
You haven't answered the main question, which is, exactly what doesn't work? Is there an error? Is the redirect ignored? Anything else? If it is in a JSP, have you enclosed the redirect in % %? I also assume you have spelt it correctly in the code as there is a spelling mistake in your example below. Ta Matt -Original Message- From: Pablo Carretero Sánchez [mailto:[EMAIL PROTECTED] Sent: 06 October 2004 16:11 To: Tomcat Users List Subject: Re: response.sendRedirect() Hi, I don't test in other Tomcat version. I'm trying a sendRedirect() in one JSP. And it doesn't work. The code is: response.sendRediredt(/jknopkn/prueba.jsp); QM ([EMAIL PROTECTED]) escribió: On Wed, Oct 06, 2004 at 04:38:54PM +0200, Pablo Carretero S?nchez wrote: : I have a urgent problem response.sendRedirect() in Tomcat 5.0.27. : : It doesn't work in my appl. What, specifically, doesn't work? Did this same code work in a previous version of Tomcat 5.0.x? etc, etc. We're all pretty sharp here, but I don't think any of us are clairvoyant. ;) -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- __ Pablo Carretero Sánchez Cygnux Arquitecto de Software Pintor Velazquez nº 3 Esc Izq 7º B 28932 #8211; Móstoles (Madrid) Movil: +34 699929150 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Any opinions expressed in this E-mail may be those of the individual and not necessarily the company. This E-mail and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this E-mail in error and that any use or copying is strictly prohibited. If you have received this E-mail in error please notify the beCogent postmaster at [EMAIL PROTECTED] Unless expressly stated, opinions in this email are those of the individual sender and not beCogent Ltd. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendRedirect()
works for me -Original Message- From: Pablo Carretero Sánchez [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 9:39 AM To: [EMAIL PROTECTED] Subject: response.sendRedirect() Hi, I have a urgent problem response.sendRedirect() in Tomcat 5.0.27. It doesn't work in my appl. Can anyone help me. Thanks a lot -- __ Pablo Carretero Sánchez Cygnux Arquitecto de Software Pintor Velazquez nº 3 Esc Izq 7º B 28932 #8211; Móstoles (Madrid) Movil: +34 699929150 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.768 / Virus Database: 515 - Release Date: 9/22/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.768 / Virus Database: 515 - Release Date: 9/22/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect()
Without seeing the rest of your code, I'll guess that the problem is that you've started the relative link with a /. Try without it. If you have to back up a directory use ../jknopkn/prueba.jsp. On Wed, 2004-10-06 at 11:11, Pablo Carretero Snchez wrote: Hi, I don't test in other Tomcat version. I'm trying a sendRedirect() in one JSP. And it doesn't work. The code is: response.sendRediredt(/jknopkn/prueba.jsp); QM ([EMAIL PROTECTED]) escribi: On Wed, Oct 06, 2004 at 04:38:54PM +0200, Pablo Carretero S?nchez wrote: : I have a urgent problem response.sendRedirect() in Tomcat 5.0.27. : : It doesn't work in my appl. What, specifically, doesn't work? Did this same code work in a previous version of Tomcat 5.0.x? etc, etc. We're all pretty sharp here, but I don't think any of us are clairvoyant. ;) -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendredirect failig from an included .jsp
Tim, Thanks for the info. The redirect that I'm trying to achieve is actually internal to my site. So I started looking at requestdispatcher.forward( ), but it appears to me that you have to simply pass the same 'request' and 'response' variables into it. I need to be able to clear the variables in the query string. Any ideas? Thanks, Jon On Tue, 03 Aug 2004 19:50:11 -0400, Tim Funk [EMAIL PROTECTED] wrote: Yes it should be failing. You cannot set headers or issue redirects from an include. (Its a rule in the spec) -Tim Jon Beyer wrote: The code 'response.sendRedirect( http://www.yahoo.com; )' fails when the containing jsp is included from another jsp. Should this be failing? What am I doing wrong? By 'failing', I mean that there is no exception thrown, and no error message, but simply no redirect. e.g. (the redirect works properly when foo.jsp is called directly, but fails when foo2.jsp is called): foo2.jsp %@ page language=java import=java.lang.*,java.util.* % %@ include file=foo.jsp % foo.jsp %@ page language=java import=java.lang.*,java.util.* % % response.sendRedirect( http://www.yahoo.com; ); % - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- We don't stop playing because we grow old, we grow old because we stop playing Try not. Do. Or do not. There is no try. -Yoda Jon Beyer 412 Brown Hall Princeton University Princeton, NJ 08544 609 986 7453 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendredirect failig from an included .jsp
Howdy, Use an HttpServletRequestWrapper and override getQueryString and/or related getParameter methods. Yoav Shapira Millennium Research Informatics -Original Message- From: Jon Beyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 9:43 AM To: [EMAIL PROTECTED]; Tomcat Users List Subject: Re: response.sendredirect failig from an included .jsp Tim, Thanks for the info. The redirect that I'm trying to achieve is actually internal to my site. So I started looking at requestdispatcher.forward( ), but it appears to me that you have to simply pass the same 'request' and 'response' variables into it. I need to be able to clear the variables in the query string. Any ideas? Thanks, Jon On Tue, 03 Aug 2004 19:50:11 -0400, Tim Funk [EMAIL PROTECTED] wrote: Yes it should be failing. You cannot set headers or issue redirects from an include. (Its a rule in the spec) -Tim Jon Beyer wrote: The code 'response.sendRedirect( http://www.yahoo.com; )' fails when the containing jsp is included from another jsp. Should this be failing? What am I doing wrong? By 'failing', I mean that there is no exception thrown, and no error message, but simply no redirect. e.g. (the redirect works properly when foo.jsp is called directly, but fails when foo2.jsp is called): foo2.jsp %@ page language=java import=java.lang.*,java.util.* % %@ include file=foo.jsp % foo.jsp %@ page language=java import=java.lang.*,java.util.* % % response.sendRedirect( http://www.yahoo.com; ); % - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- We don't stop playing because we grow old, we grow old because we stop playing Try not. Do. Or do not. There is no try. -Yoda Jon Beyer 412 Brown Hall Princeton University Princeton, NJ 08544 609 986 7453 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendredirect failig from an included .jsp
Yes it should be failing. You cannot set headers or issue redirects from an include. (Its a rule in the spec) -Tim Jon Beyer wrote: The code 'response.sendRedirect( http://www.yahoo.com; )' fails when the containing jsp is included from another jsp. Should this be failing? What am I doing wrong? By 'failing', I mean that there is no exception thrown, and no error message, but simply no redirect. e.g. (the redirect works properly when foo.jsp is called directly, but fails when foo2.jsp is called): foo2.jsp %@ page language=java import=java.lang.*,java.util.* % %@ include file=foo.jsp % foo.jsp %@ page language=java import=java.lang.*,java.util.* % % response.sendRedirect( http://www.yahoo.com; ); % - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect problem in Tomcat 5.0.18
You'll need to structure your code so that you either write to the out stream or perform a sendRedirect. There has never been a version of Tomcat that would allow otherwise. This is the same in PHP, ASP, and I imagine any other web scripting language. A sendRedirect does nothing more than send back a bodyless header with a Location: url parameter. You can't send a header once you've started writing to the body of the message. You also can't write to the body after sending a redirect (which is why you need to add a return statement just after the redirect). On Sunday 01 February 2004 06:55 am, you wrote: Hi Ben, Thanks for your assistance, I added return ; statements directly after the redirects but this didn't stop the errors. I am currently having the code checked and will let you know what eventuates. Should there be no out.print statements above the response.sendRedirect lines in the jsp code ? There are also out.write statements in the jsp code above the redirect lines, could these also cause a problem ? The code was not erroring like this when using Tomcat 4.1.24 or 5.0.16, do you think this is due to Tomcat 5.0.18 being more strict with syntax ? Thanks for your time, Regards Anthony From: Ben Souther [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: response.sendRedirect problem in Tomcat 5.0.18 Date: Sat, 31 Jan 2004 23:53:41 -0500 On Saturday 31 January 2004 11:32 pm, you wrote: at org.apache.jsp.product_jsp._jspService(product_jsp.java:283) If you go into your work directory, and look at product_jsp.java line 283, you will see exactly what's causing the problem. Without seeing your code, I can't be sure what the problem is but 99% of the time when I see an illegal state exception it caused by one of two things. Either you've written someting to the out stream before redirecting (setting content type or any out.print statements) or you didn't put a return statement just after the redirect. If neither of these is the case and you can post your code, attach your JSP and the product_jsp.java code I'll take a stab at it. -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect problem in Tomcat 5.0.18
On Saturday 31 January 2004 11:32 pm, you wrote: at org.apache.jsp.product_jsp._jspService(product_jsp.java:283) If you go into your work directory, and look at product_jsp.java line 283, you will see exactly what's causing the problem. Without seeing your code, I can't be sure what the problem is but 99% of the time when I see an illegal state exception it caused by one of two things. Either you've written someting to the out stream before redirecting (setting content type or any out.print statements) or you didn't put a return statement just after the redirect. If neither of these is the case and you can post your code, attach your JSP and the product_jsp.java code I'll take a stab at it. -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendRedirect() finite loop?!
Hi, On further investigation it would appear that this is not a Tomcat issue. It seems to be something to do with mod_jk. When a response.sendRedirect occurs it does not apply it properly. Or at least something is not executing properly. The setup we have is Apache 2.0.48, Tomcat 4.1.29, and mod_jk between them working with mod_ssl. I tested the code without using apache between me and Tomcat and everything worked as expected. Any suggestions or comments?? Regards Stuart -Original Message- From: Stuart Stephen [mailto:[EMAIL PROTECTED] Sent: 03 December 2003 10:06 To: [EMAIL PROTECTED] Subject: response.sendRedirect() finite loop?! talk2UtimeHi all, I am getting strange entries in my test_service_log.2003-12-03.txt. In my JSP which gets executed before this I am running a response.sendRedirect(/test/RedirectToMe.jsp); with a return; afterwards. So this should only get executed once. However. According to my logs its being accessed 1333 times in just SIX seconds [line count / 2]. I am the ONLY person on the server and therefore this is strange occurance! I checked the corresponding apache logs and this servlet was not in the logs, the servlet before hand which does the redirect was the only servlet that has been accessed externally. This is true from what the user sees. Is this a bug in Tomcat 4.1.29 or has something changed? I've been using Tomcat for a few years now and I've never seen anything like this? Regards, Stuart Stephen 2003-12-03 09:32:08 StandardContext[/t2ut]: Mapping contextPath='/test' with requestURI='/test/RedirectToMe.jsp' and relativeURI='/RedirectToMe.jsp' 2003-12-03 09:32:08 StandardContext[/t2ut]: Mapped to servlet 'jsp' with servlet path '/RedirectToMe.jsp' and path info 'null' and update=true 2003-12-03 09:32:08 StandardContext[/t2ut]: Mapping contextPath='/test' with requestURI='/test/RedirectToMe.jsp' and relativeURI='/RedirectToMe.jsp' 2003-12-03 09:32:08 StandardContext[/t2ut]: Mapped to servlet 'jsp' with servlet path '/RedirectToMe.jsp' and path info 'null' and update=true ... ... ... 2003-12-03 09:32:14 StandardContext[/t2ut]: Mapping contextPath='/t2ut' with requestURI='/t2ut/RoomTimes.jsp' and relativeURI='/RoomTimes.jsp' 2003-12-03 09:32:14 StandardContext[/t2ut]: Mapped to servlet 'jsp' with servlet path '/RoomTimes.jsp' and path info 'null' and update=true 2003-12-03 09:32:14 StandardContext[/t2ut]: Mapping contextPath='/t2ut' with requestURI='/t2ut/RoomTimes.jsp' and relativeURI='/RoomTimes.jsp' 2003-12-03 09:32:14 StandardContext[/t2ut]: Mapped to servlet 'jsp' with servlet path '/RoomTimes.jsp' and path info 'null' and update=true - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendRedirect() finite loop?!
Howdy, I've never seen something like this with tomcat, and I don't know enough about mod_jk to comment intelligently. If you don't need Apache, don't use it ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Stuart Stephen [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 7:37 AM To: Tomcat Users List Subject: RE: response.sendRedirect() finite loop?! Hi, On further investigation it would appear that this is not a Tomcat issue. It seems to be something to do with mod_jk. When a response.sendRedirect occurs it does not apply it properly. Or at least something is not executing properly. The setup we have is Apache 2.0.48, Tomcat 4.1.29, and mod_jk between them working with mod_ssl. I tested the code without using apache between me and Tomcat and everything worked as expected. Any suggestions or comments?? Regards Stuart -Original Message- From: Stuart Stephen [mailto:[EMAIL PROTECTED] Sent: 03 December 2003 10:06 To: [EMAIL PROTECTED] Subject: response.sendRedirect() finite loop?! talk2UtimeHi all, I am getting strange entries in my test_service_log.2003-12-03.txt. In my JSP which gets executed before this I am running a response.sendRedirect(/test/RedirectToMe.jsp); with a return; afterwards. So this should only get executed once. However. According to my logs its being accessed 1333 times in just SIX seconds [line count / 2]. I am the ONLY person on the server and therefore this is strange occurance! I checked the corresponding apache logs and this servlet was not in the logs, the servlet before hand which does the redirect was the only servlet that has been accessed externally. This is true from what the user sees. Is this a bug in Tomcat 4.1.29 or has something changed? I've been using Tomcat for a few years now and I've never seen anything like this? Regards, Stuart Stephen 2003-12-03 09:32:08 StandardContext[/t2ut]: Mapping contextPath='/test' with requestURI='/test/RedirectToMe.jsp' and relativeURI='/RedirectToMe.jsp' 2003-12-03 09:32:08 StandardContext[/t2ut]: Mapped to servlet 'jsp' with servlet path '/RedirectToMe.jsp' and path info 'null' and update=true 2003-12-03 09:32:08 StandardContext[/t2ut]: Mapping contextPath='/test' with requestURI='/test/RedirectToMe.jsp' and relativeURI='/RedirectToMe.jsp' 2003-12-03 09:32:08 StandardContext[/t2ut]: Mapped to servlet 'jsp' with servlet path '/RedirectToMe.jsp' and path info 'null' and update=true ... ... ... 2003-12-03 09:32:14 StandardContext[/t2ut]: Mapping contextPath='/t2ut' with requestURI='/t2ut/RoomTimes.jsp' and relativeURI='/RoomTimes.jsp' 2003-12-03 09:32:14 StandardContext[/t2ut]: Mapped to servlet 'jsp' with servlet path '/RoomTimes.jsp' and path info 'null' and update=true 2003-12-03 09:32:14 StandardContext[/t2ut]: Mapping contextPath='/t2ut' with requestURI='/t2ut/RoomTimes.jsp' and relativeURI='/RoomTimes.jsp' 2003-12-03 09:32:14 StandardContext[/t2ut]: Mapped to servlet 'jsp' with servlet path '/RoomTimes.jsp' and path info 'null' and update=true - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendRedirect() finite loop?!
Also, are you using the latest mod_jk? We had some thread hangs (never saw what you are seeing), that cleared up by moving to 1.2.5 mod_jk. [EMAIL PROTECTED] 12/3/03 7:05:52 AM Howdy, I've never seen something like this with tomcat, and I don't know enough about mod_jk to comment intelligently. If you don't need Apache, don't use it ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: Stuart Stephen [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 7:37 AM To: Tomcat Users List Subject: RE: response.sendRedirect() finite loop?! Hi, On further investigation it would appear that this is not a Tomcat issue. It seems to be something to do with mod_jk. When a response.sendRedirect occurs it does not apply it properly. Or at least something is not executing properly. The setup we have is Apache 2.0.48, Tomcat 4.1.29, and mod_jk between them working with mod_ssl. I tested the code without using apache between me and Tomcat and everything worked as expected. Any suggestions or comments?? Regards Stuart -Original Message- From: Stuart Stephen [mailto:[EMAIL PROTECTED] Sent: 03 December 2003 10:06 To: [EMAIL PROTECTED] Subject: response.sendRedirect() finite loop?! talk2UtimeHi all, I am getting strange entries in my test_service_log.2003-12-03.txt. In my JSP which gets executed before this I am running a response.sendRedirect(/test/RedirectToMe.jsp); with a return; afterwards. So this should only get executed once. However. According to my logs its being accessed 1333 times in just SIX seconds [line count / 2]. I am the ONLY person on the server and therefore this is strange occurance! I checked the corresponding apache logs and this servlet was not in the logs, the servlet before hand which does the redirect was the only servlet that has been accessed externally. This is true from what the user sees. Is this a bug in Tomcat 4.1.29 or has something changed? I've been using Tomcat for a few years now and I've never seen anything like this? Regards, Stuart Stephen 2003-12-03 09:32:08 StandardContext[/t2ut]: Mapping contextPath='/test' with requestURI='/test/RedirectToMe.jsp' and relativeURI='/RedirectToMe.jsp' 2003-12-03 09:32:08 StandardContext[/t2ut]: Mapped to servlet 'jsp' with servlet path '/RedirectToMe.jsp' and path info 'null' and update=true 2003-12-03 09:32:08 StandardContext[/t2ut]: Mapping contextPath='/test' with requestURI='/test/RedirectToMe.jsp' and relativeURI='/RedirectToMe.jsp' 2003-12-03 09:32:08 StandardContext[/t2ut]: Mapped to servlet 'jsp' with servlet path '/RedirectToMe.jsp' and path info 'null' and update=true ... ... ... 2003-12-03 09:32:14 StandardContext[/t2ut]: Mapping contextPath='/t2ut' with requestURI='/t2ut/RoomTimes.jsp' and relativeURI='/RoomTimes.jsp' 2003-12-03 09:32:14 StandardContext[/t2ut]: Mapped to servlet 'jsp' with servlet path '/RoomTimes.jsp' and path info 'null' and update=true 2003-12-03 09:32:14 StandardContext[/t2ut]: Mapping contextPath='/t2ut' with requestURI='/t2ut/RoomTimes.jsp' and relativeURI='/RoomTimes.jsp' 2003-12-03 09:32:14 StandardContext[/t2ut]: Mapped to servlet 'jsp' with servlet path '/RoomTimes.jsp' and path info 'null' and update=true - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendRedirect() finite loop?!
On further investigation it would appear that this is not a Tomcat issue. It seems to be something to do with mod_jk. When a response.sendRedirect occurs it does not apply it properly. Or at least something is not executing properly. The setup we have is Apache 2.0.48, Tomcat 4.1.29, and mod_jk between them working with mod_ssl. I tested the code without using apache between me and Tomcat and everything worked as expected. Just out of curiosity, are you using mod_rewrite? If your .jsp redirects A - B, and you are rewriting B - A, then this will produce behavior similar to what you're seeing. (However, you'd also see one line for each loop iteration in Apache's access log). Are there any HTTP headers returned via response.sendRedirect(/test/RedirectToMe.jsp); (Should be an HTTP 302 with a Location: header). Also, what is the url for the servlet/jsp that makes the above call? -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendRedirect()
you do not lose your session, but you create a new request. /anton -Original Message- From: Duncan [mailto:[EMAIL PROTECTED] Sent: den 7 november 2003 17:36 To: Tomcat User List Subject: response.sendRedirect() Is it normal to loose your session when using the response.sendRedirect() command? If so is there a way to redirect without loosing the session? Cheers, Duncan. Decker Telecom Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect()
Duncan wrote: Is it normal to loose your session when using the response.sendRedirect() command? If so is there a way to redirect without loosing the session? Yes, do a RequestDispatcher.forward(...) instead. -- Jeanfrancois Cheers, Duncan. Decker Telecom Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect()
Oops. Just realised that my app was switching between contexts on my server, which is why I was loosing session info. Thanks for the replies thought. - Duncan. Jean-Francois Arcand wrote: Duncan wrote: Is it normal to loose your session when using the response.sendRedirect() command? If so is there a way to redirect without loosing the session? Yes, do a RequestDispatcher.forward(...) instead. -- Jeanfrancois Cheers, Duncan. Decker Telecom Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect()
You should only loose your session if session cookies support is disabled, and - the redirected URL has not been rewritten to add the session id, or - you redirect to another context / server in the second case the passed session id will be invalid, or ignored, depending on the case. Sometimes I have lost my session because I was not calling the getSession() in my servlet. This led my servlet engine to not properly set the response cookies. Hope it helps you, Rodrigo Ruiz Duncan wrote: Is it normal to loose your session when using the response.sendRedirect() command? If so is there a way to redirect without loosing the session? Cheers, Duncan. Decker Telecom Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect()
Are you redirecting from an http to an https url or vice versa? Are you redirecting to a different domain? On Friday 07 November 2003 11:35 am, Duncan wrote: Is it normal to loose your session when using the response.sendRedirect() command? If so is there a way to redirect without loosing the session? Cheers, Duncan. Decker Telecom Ltd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ben Souther F.W. Davison Company, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect
Say you're accessing pages on localhost, so your URLs take the form http://localhost:8080/war-file/jsp-file then the servlet container root is http://localhost:8080/ and a redirect to /another-war-file/another.jsp would be a redirect to: http://localhost:8080/another-war-file/another.jsp In sendRedirect, I'm fairly sure that you simply use /cal/form/index.jsp. That sort of pattern always works for my webapps. - Original Message - From: Charlie Toohey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 05, 2003 7:07 PM Subject: response.sendRedirect The Servlet API doc for the sendRedirect method states: If the location is relative with a leading '/' the container interprets it as relative to the servlet container root. I've looked thru the Servlet Spec and can not quite figure out what they mean by servlet container root ? Is this a typo and supposed to be servlet context root ? Or is there really such a thing as the servlet container root, and if so, what is it ? e.g. if my context path is /cal and I want to redirect to /cal/form/index.jsp, what would I use in sendRedirect ? (I know I could do a forward, but want to redirect in my situation) Thanks, Charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect
The easiest way to understand this is to think about how a browser sees a relative link. Browsers don't know that they're dealing with a servlet app. A sendRedirect simply puts the following header in the response: Location: url Let's take the following url: http://www.mydomain.com/cal/index.jsp If your page index.jsp resides in the context root cal and you want to send a redirect to page2.jsp you would use page2.jsp. This tells the browser to look in the current directory for a file name page2.jsp. If you enter /page2.jsp The browser will go to what IT considers to be the webroot; the first directory after the base url http://www.mydomain.com/; and look for page2.jsp. If you're several directories below the context root and need to redirect to a higher directory, you're better off prepending one ../ to the url for each directory that you need to climb than to try to list the context root and work your way down ( /cal/page.jsp). This way, you won't need to fish through your code and change the urls if the application name cal changes. But that's just my opinion. -Ben On Friday 05 September 2003 02:07 pm, Charlie Toohey wrote: The Servlet API doc for the sendRedirect method states: If the location is relative with a leading '/' the container interprets it as relative to the servlet container root. I've looked thru the Servlet Spec and can not quite figure out what they mean by servlet container root ? Is this a typo and supposed to be servlet context root ? Or is there really such a thing as the servlet container root, and if so, what is it ? e.g. if my context path is /cal and I want to redirect to /cal/form/index.jsp, what would I use in sendRedirect ? (I know I could do a forward, but want to redirect in my situation) Thanks, Charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendRedirect
The one thing you want to watch out for with relative redirects is that they're converted by the servlet container to absolute URLs (this is in the servlet spec). This is, by the letter of the HTTP spec, the correct thing to do. Unfortunately, it can cause problems in deployments where an proxying SSL accelerator is used. These are proxies that take HTTPS requests and convert them to HTTP requests, handling all the SSL crypto stuff in the process (this technique is used in some high-volume deployments where SSL is required...the SSL stuff can be done in hardware). Consider the following: - browser requests https://visibleserver/a.jsp - a proxy SSL accelerator does the SSL processing, then forwards the request via standard HTTP to http://realserver/a.jsp - the web application does some processing, followed by a response.sendRedirect(b.jsp), which the servlet container trainslates to http://realserver/b.jsp. This is probably not what the programmer intended There are a couple of things you can do to solve this problem: * Change all sendRedirect calls to use absolute URLs. This implies that you know the absolute URL...it'd have to be a parameter to the web application, or something. OR * Implement your own sendRedirect method that sends the relative URL to the browser. This does not adhere to the HTTP spec, but all the browsers I tested seem to handle it fine (I've read elsewhere that this was the case too). Anyway, this probably isn't an issue for most people. If you have a commercial application and can't control the deployment, you should at least consider this, though. Allen -Original Message- From: Christopher Williams [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 2:22 PM To: Tomcat Users List Subject: Re: response.sendRedirect Say you're accessing pages on localhost, so your URLs take the form http://localhost:8080/war-file/jsp-file then the servlet container root is http://localhost:8080/ and a redirect to /another-war-file/another.jsp would be a redirect to: http://localhost:8080/another-war-file/another.jsp In sendRedirect, I'm fairly sure that you simply use /cal/form/index.jsp. That sort of pattern always works for my webapps. - Original Message - From: Charlie Toohey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 05, 2003 7:07 PM Subject: response.sendRedirect The Servlet API doc for the sendRedirect method states: If the location is relative with a leading '/' the container interprets it as relative to the servlet container root. I've looked thru the Servlet Spec and can not quite figure out what they mean by servlet container root ? Is this a typo and supposed to be servlet context root ? Or is there really such a thing as the servlet container root, and if so, what is it ? e.g. if my context path is /cal and I want to redirect to /cal/form/index.jsp, what would I use in sendRedirect ? (I know I could do a forward, but want to redirect in my situation) Thanks, Charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect
The one thing you want to watch out for with relative redirects is that they're converted by the servlet container to absolute URLs (this is in the servlet spec). This is, by the letter of the HTTP spec, the correct thing to do. Unfortunately, it can cause problems in deployments where an proxying SSL accelerator is used. These are proxies that take HTTPS requests and convert them to HTTP requests, handling all the SSL crypto stuff in the process (this technique is used in some high-volume deployments where SSL is required...the SSL stuff can be done in hardware). I stand corrected. I was unaware the container converted relative urls to absolute urls. That being said, the rest of what I've said still holds true, just not for the reason that I thought it does. On Friday 05 September 2003 02:53 pm, Ben Souther wrote: The easiest way to understand this is to think about how a browser sees a relative link. Browsers don't know that they're dealing with a servlet app. A sendRedirect simply puts the following header in the response: Location: url Let's take the following url: http://www.mydomain.com/cal/index.jsp If your page index.jsp resides in the context root cal and you want to send a redirect to page2.jsp you would use page2.jsp. This tells the browser to look in the current directory for a file name page2.jsp. If you enter /page2.jsp The browser will go to what IT considers to be the webroot; the first directory after the base url http://www.mydomain.com/; and look for page2.jsp. If you're several directories below the context root and need to redirect to a higher directory, you're better off prepending one ../ to the url for each directory that you need to climb than to try to list the context root and work your way down ( /cal/page.jsp). This way, you won't need to fish through your code and change the urls if the application name cal changes. But that's just my opinion. -Ben On Friday 05 September 2003 02:07 pm, Charlie Toohey wrote: The Servlet API doc for the sendRedirect method states: If the location is relative with a leading '/' the container interprets it as relative to the servlet container root. I've looked thru the Servlet Spec and can not quite figure out what they mean by servlet container root ? Is this a typo and supposed to be servlet context root ? Or is there really such a thing as the servlet container root, and if so, what is it ? e.g. if my context path is /cal and I want to redirect to /cal/form/index.jsp, what would I use in sendRedirect ? (I know I could do a forward, but want to redirect in my situation) Thanks, Charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ben Souther F.W. Davison Company, Inc. REGISTER NOW FOR THE SCORPEO USER CONFERENCE! September 18-19, 2003 in Boston/Brookline, MA Additional Training Sessions held September 17, 2003 More info http://www.fwdco.com/services/Uconf03/default.shtm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect() and the servlet path?
My reading of section 5.3 of the servlet-spec (version=2.3), says that you are wrong. Paths to sendRedirect are normal URL patterns, and are *not* based on the calling Context. joe user [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, if I have a context path such as /mycontext and I use response.sendRedirect(/foo.jsp), the container should translate that into a full url such as http://myserver/mycontext/foo.jsp, instead of http://myserver/foo.jsp. However, it seems that this is not happening. Am I doing something wrong, or is there a bug, or ??? Thanks for any help on this. __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendRedirect( .. )
One reason is this: After a redirect the servlet that issues the redirect will continue to run unless you stop the processing with a return statement directly after the redirect. Now consider this example: Servlet A: doSomething(); include(Servlet B); doSomethingMore(); Servlet B: doSomeOtherThing(); if (condition) { respose.sendRedirect(); return; } doMoreOtherThings(); This will stop Servlet B from processing doMoreOtherThings() after the redirect, but Servlet A will still execute doSomethingMore(). One other thing with sendRedirect() is, that it is a good practice to do the redirect as early as possible. The later you do it, the higher gets the risk that the response header has already been sent to the client. (If you produced enough output to force a flush of the outputbuffer) -Original Message- From: Geoff Coffey [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 12:49 AM To: Tomcat Users List Subject: Re: response.sendRedirect( .. ) Does anybody know the reason for this limitation? Does anybody have a better way to accomplish what I'm describing? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect( .. )
After a redirect the servlet that issues the redirect will continue to run unless you stop the processing with a return statement directly after the redirect. Now consider this example: [...] This will stop Servlet B from processing doMoreOtherThings() after the redirect, but Servlet A will still execute doSomethingMore(). One other thing with sendRedirect() is, that it is a good practice to do the redirect as early as possible. [...] Yes, but this just seems like a weakness in the model really. In our case, the redirect was sent in every case before anything of significance was added to the content of the response, so we never would have run in to a committed response issue. The fact that my JSP page turns in to a servlet behind-the-scenes, and that servlet model doesn't handle redirects in includes because of a code organization problem seems arbitrary and inappropriate. I would expect sendRedirect() to abort the response anyway, although someone may have a good reason to include content in a 302 response. A forward, on the other hand, does abort the response, so it is even more arbitrary that forwards don't work in includes. It seems like this is a case where a weakness in the model at a low level rears its head at the very highest level (JSP), which is, IMO, a bad thing. And the docs don't seem clear on this point at all. We only were able to confirm that redirects and forwards don't work in includes by examining the generated .java files and reading the docs on the servlet stuff. The JSP docs don't seem to mention it (I may be missing it...) Here's the relevant docs: sendRedirect public void sendRedirect (String location) throws IOException Sends a temporary redirect response to the client using the specified redirect location URL. This method can accept relative URLs; the servlet container must convert the relative URL to an absolute URL before sending the response to the client. If the location is relative without a leading '/' the container interprets it as relative to the current request URI. If the location is relative with a leading '/' the container interprets it as relative to the servlet container root. If the response has already been committed, this method throws an IllegalStateException. After using this method, the response should be considered to be committed and should not be written to. Parameters: location - the redirect location URL Throws: IOException - If an input or output exception occurs IllegalStateException - If the response was committed and jsp:forward Forwards a client request to an HTML file, JSP file, or servlet for processing. JSP Syntax jsp:forward page={ relativeURL | %= expression %} / or jsp:forward page={ relativeURL | %= expression %} jsp:param name= parameterName value={ parameterValue | %= expression %} /+ /jsp:forward Examples jsp:forward page=/servlet/login / jsp:forward page=/servlet/login jsp:param name=username value=jsmith / /jsp:forward Description The jsp:forward element forwards the request object containing the client request information from one JSP file to another file. The target file can be an HTML file, another JSP file, or a servlet, as long as it is in the same application context as the forwarding JSP file. The lines in the source JSP file after the jsp:forward element are not processed. You can pass parameter names and values to the target file by using a jsp:param clause. An example of this would be passing the parameter name username (with name=username ) and the value scott (with value=scott )to a servlet login file as part of the request. If you use jsp:param , the target file should be a dynamic file that can handle the parameters. Be careful when using jsp:forward with unbuffered output. If you have used the %@ page % directive with buffer=none to specify that the output of your JSP file should not be buffered, and if the JSP file has any data in the out object, using jsp:forward will cause an IllegalStateException . Attributes page={ relativeURL | %= expression %} AString or an expression representing the relative URL of the file to which you are forwarding the request. The file can be another JSP file, a servlet, or any other dynamic file that can handle a request object. The relative URL looks like a path-it cannot contain a protocol name, port number, or domain name. The URL can be absolute or relative to the current JSP file. If it is absolute (beginning with a /), the path is resolved by your Web or application server. jsp:param name= parameterName value={ parameterValue | %= expression %} /+ Sends one or more name/value pairs as parameters to a dynamic file. The target file should be dynamic, that is, a JSP file, servlet, or other file that can process the data that is sent to it as parameters. You can use more than one jsp:param clause if you need to send more than one parameter to the target file. The name
Re: response.sendRedirect( .. )
Section 4.4 of the Jsp spec: An included page only has access to the JspWriter object and it cannot set headers. This precludes invoking methods like setCookie(). Attempts to invoke these methods will be ignored. The constraint is equivalent to the one imposed on the include() method of the RequestDispatcher class. So jsp:include also has all the same restrictions imposed by RequestDispatcher.include(). As for th 302 errors, from the RFC: http://www.ietf.org/rfc/rfc2616.txt ... The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). I paraphrase as its nice to present some body content in your page since browsers/agents do have the option of displaying/parsing the body for some context before following the redirect. -Tim Geoff Coffey wrote: [...] I would expect sendRedirect() to abort the response anyway, although someone may have a good reason to include content in a 302 response. A forward, on the other hand, does abort the response, so it is even more arbitrary that forwards don't work in includes. It seems like this is a case where a weakness in the model at a low level rears its head at the very highest level (JSP), which is, IMO, a bad thing. And the docs don't seem clear on this point at all. We only were able to confirm that redirects and forwards don't work in includes by examining the generated .java files and reading the docs on the servlet stuff. The JSP docs don't seem to mention it (I may be missing it...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect( .. )
On Wednesday, March 5, 2003, at 08:32 AM, Tim Funk wrote: I paraphrase as its nice to present some body content in your page since browsers/agents do have the option of displaying/parsing the body for some context before following the redirect. I stand corrected on that point, although I've never followed this guidance in 8 years, and I've never seen a user agent that didn't follow redirects immediately. I've also never seen anyone else do this. But none-the-less, it would be wrong, then, for redirect to abort the response. Thanks again, tim. Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect( .. )
Geoff Coffey wrote: On Wednesday, March 5, 2003, at 08:32 AM, Tim Funk wrote: I paraphrase as its nice to present some body content in your page since browsers/agents do have the option of displaying/parsing the body for some context before following the redirect. I stand corrected on that point, although I've never followed this guidance in 8 years, and I've never seen a user agent that didn't follow redirects immediately. You're probably thinking of browsers. Spiders and other scripts, on the other hand, might not be so kind, esp since you're trying to use redirect to prevent access to a restricted area. For instance, in CGI environments, after setting the Location header (equivalent of sendRedirect) it is always wise to immediately exit the script so that no further content is sent along with the header. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect( .. )
Geoff Coffey wrote: It seems like we need our authentication check and redirect (or forward) on the content page itself and not in an include, so Muffi created a taglib to encapsulate this check and that seems to be working. Is this a typical solution? It seems like a frustrating restriction to prevent redirects or forwards in includes. Does anybody know the reason for this limitation? Does anybody have a better way to accomplish what I'm describing? I know a lot of people prefer container-managed authentication, but my own approach has been similar to yours. At first I tried doing the exact same thing, which is how I would have done it in my old language, PHP. But with servlets/JSP, I think a better way to do this (that works well for me) is to write a filter and map that filter to any sensitive URLs. The filter does the authentication check, and has the ability to perform the sendRedirect with no problems (unlike a runtime JSP include using jsp:forward). Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendRedirect( .. )
I have 3 machines that I support with broken browsers that don't follow redirects immediately. In fact if the page includes any content, any at all, the ignore the redirect. I'm not 100% sure, but I even thing they ignore meta tag redirects. --mikej -=- mike jackson [EMAIL PROTECTED] -Original Message- From: Geoff Coffey [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 7:39 AM To: Tomcat Users List Subject: Re: response.sendRedirect( .. ) On Wednesday, March 5, 2003, at 08:32 AM, Tim Funk wrote: I paraphrase as its nice to present some body content in your page since browsers/agents do have the option of displaying/parsing the body for some context before following the redirect. I stand corrected on that point, although I've never followed this guidance in 8 years, and I've never seen a user agent that didn't follow redirects immediately. I've also never seen anyone else do this. But none-the-less, it would be wrong, then, for redirect to abort the response. Thanks again, tim. Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect( .. )
On Wednesday, March 5, 2003, at 09:41 AM, Mike Jackson wrote: I have 3 machines that I support with broken browsers that don't follow redirects immediately. In fact if the page includes any content, any at all, the ignore the redirect. I'm not 100% sure, but I even thing they ignore meta tag redirects. If they ignore redirects that contain content, then following the HTTP spec guidance would exacerbate the problem, not solve it. The guidance was to always include some content on redirect responses, which I have never done. Hmmm...seems to be some uncertainty about this :( I'm going to try including content from now on just to be well behaved, but if I too see problems, I'll have to rethink that. At least browsers aren't half as bad as in the past :) Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect( ); question
Mufaddal Khumri wrote: Now if the USER_AUTHORIZED attribute is not set, it will enter the if block and get redirected to the login.jsp page. The browser shows me the content of the body page after the if block instead. Does after getting redirected the call returns to this page and completes the processing of this page ? Try putting a return; statement immediately after the call to sendRedirect. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect( ); question
Adding a return does not work. Infact I tried to add this to the top of my page %@ page buffer=32KB autoFlush=true % This throws the following error: 2003-03-04 14:19:07 StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception org.apache.jasper.JasperException: /include/header.jsp(0,113) jsp.error.buffer.invalid at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHand ler.java:94) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java :428) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java :140) at org.apache.jasper.compiler.Validator$PageDirectiveVisitor.visit(Validato r.java:183) at org.apache.jasper.compiler.Node$PageDirective.accept(Node.java:280) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:1028) at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:1070) at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:1076) at org.apache.jasper.compiler.Node$Root.accept(Node.java:232) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:1028) at org.apache.jasper.compiler.Validator.validate(Validator.java:581) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:226) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:351) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.ja va:474) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja va:184) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc her.java:684) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDisp atcher.java:575) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispat cher.java:498) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.ja va:822) at org.apache.jsp.Catalog_jsp._jspService(Catalog_jsp.java:42) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja va:204) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv e.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i nvokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 80) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv e.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i nvokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja va:246) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i nvokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 80) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:241 5) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java :180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i nvokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa lve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i nvokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java :172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i nvokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 80) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i nvokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 80) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at
Re: response.sendRedirect( ); question
Mufaddal Khumri wrote: Adding a return does not work. Well, it was worth a try. Sorry it didn't work out. My own approach (modeled after the conventional wisdom tossed about on this list and in some tutorials I have read) is to refrain from using decision logic in JSPs wherever possible. Some people call it the MVC approach, I typically have a servlet as the target resource of all HTTP requests, which does the decision making and then calls dispatcher.forward() on a JSP to generate the HTML to send to the browser. I have not had any problem calling sendRedirect from a servlet. If I absolutely must have conditional logic in the JSP I try to put it into a custom tag. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect( .. )
If this page is being called via a jsp:include - your out of luck. You cannot perform a sendRedirect() inside of an include. It's not tomcat's fault - it specified by the JSP spec. -Tim Mufaddal Khumri wrote: I have a .jsp page which has the following contents: / /--- html % // if the user is not authenticated, we need to send them to the login page if(session.getAttribute(USER_AUTHORIZED) == null || session.getAttribute(USER_AUTHORIZED).equals(false)) { System.out.println(Before redirect); response.sendRedirect(/login/Login.jsp); System.out.println(After redirect); } % body pI don't know why this is being called when the user is not already authenticated /p /body /html / /--- Now if the USER_AUTHORIZED attribute is not set, it will enter the if block and get redirected to the login.jsp page. The browser shows me the content of the body page after the if block instead. Does after getting redirected the call returns to this page and completes the processing of this page ? I checked if the if block was being entered by putting the two System.out.println( .. ) statements .. and when i call this JSP from my browser .. both those statements get printed onto the console. This used to work in Tomcat 3.XX i recently upgraded to Tomcat 4.1.18 .. is there some change in the behaviour of response.sendRedirect () ? thanks. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect( .. )
Yes This is used from within an include. so how would I redirect ? Thanks. On Wednesday, March 5, 2003, at 03:20 AM, Tim Funk wrote: If this page is being called via a jsp:include - your out of luck. You cannot perform a sendRedirect() inside of an include. It's not tomcat's fault - it specified by the JSP spec. -Tim Mufaddal Khumri wrote: I have a .jsp page which has the following contents: / /- -- html % // if the user is not authenticated, we need to send them to the login page if(session.getAttribute(USER_AUTHORIZED) == null || session.getAttribute(USER_AUTHORIZED).equals(false)) { System.out.println(Before redirect); response.sendRedirect(/login/Login.jsp); System.out.println(After redirect); } % body pI don't know why this is being called when the user is not already authenticated /p /body /html / /- -- Now if the USER_AUTHORIZED attribute is not set, it will enter the if block and get redirected to the login.jsp page. The browser shows me the content of the body page after the if block instead. Does after getting redirected the call returns to this page and completes the processing of this page ? I checked if the if block was being entered by putting the two System.out.println( .. ) statements .. and when i call this JSP from my browser .. both those statements get printed onto the console. This used to work in Tomcat 3.XX i recently upgraded to Tomcat 4.1.18 .. is there some change in the behaviour of response.sendRedirect () ? thanks. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect( .. )
You can do a compile time include instead of a run-time include. -Tim Mufaddal Khumri wrote: Yes This is used from within an include. so how would I redirect ? Thanks. On Wednesday, March 5, 2003, at 03:20 AM, Tim Funk wrote: If this page is being called via a jsp:include - your out of luck. You cannot perform a sendRedirect() inside of an include. It's not tomcat's fault - it specified by the JSP spec. -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect( .. )
You can do a compile time include instead of a run-time include. Tim: We wanted to avoid that because we're including quite a lot of stuff, and it is being included on every page. Naively, I felt that duplicating all that header and footer logic and HTML in every generated servlet would be unwise. But I'm very new to this, so I may be off base. The general setup is that we have the typical standardized header and footer, and some standardized, but conditional, navigation stuff. This is all part of two include files called, aptly, Header.jsp and Footer.jsp. These files are included on nearly every page, so that the page itself only needs to define its unique content. Our header performs the requisite check that the user is authenticated, and attempts to redirect to the login page if not. For some reason it worked fine until recently, perhaps coinciding with our switch to the latest stable tomcat. It seems like we need our authentication check and redirect (or forward) on the content page itself and not in an include, so Muffi created a taglib to encapsulate this check and that seems to be working. Is this a typical solution? It seems like a frustrating restriction to prevent redirects or forwards in includes. Does anybody know the reason for this limitation? Does anybody have a better way to accomplish what I'm describing? Thanks for all your help so far! Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect( .. )
(Sorry for the ramblings ...) Yes - creating a taglib is much, much better than a compile time include. My only reason of recommendation for a compile time include was because that was the easiest and quickest fix - but also the worst. There are a few ways to perform authentication. Each has their own merits. - Use a custom tag that will force an abort/redirect of the page - Use a filter - Use the servlet api' security constraints A custom tag offers the most flexibility since it is easiest it is the easiest way to perform granular access. But this method has the drawback of reinventing the wheel with respect to page protection. A filter is nice since the pages to be protected don't need to know whether they are being protected or not. This leaves the coding of the page MUCH cleaner and easier to maintain. Filters can also be selectively run on only mappings defined in web.xml. Filters also have the abolity to be run on every request and you can create your own wacky rules too. The prefered way is via the servlet sepcification. This method relies on the spec and the brain pwoer of a lot of smart people trying to think of how to solve the exact problem you had. But on the bad side, it is also a lot of smart people from different organizations with their own agenda so for some people - this method is completely unworkable to them. But this method is the best since ultimately security is taken out of the hadns of the programmer and placed into the hands of the system administrator or configurator. This method still relies on developer support but offers the most flexibility if you can plan on using this first. Pertaining to the topic below of using a header.jsp and footer.jsp. We have the same mess, and I emphasize mess. Many of my pages include a header, then do stuff, then a footer. I inherited it and hate it. Luckily the consulting firm that did this to me is long gone. Since then we have done the following to fix messes like this: - Get a real content management system. Let it republish all the HTML file when stuff changes. For us, navigation doesn't change very often so mass publishes aren't very painful. - Custom tags are your friend. For newer parts of my site, I have created a 3 custom tags which handle my header/footer/nav hell. So now my pages look like this: foo:html foo:head Any extra stuff which needs to appear in head tag goes here. Otherwise this tag just places the normal stuff that would appear in the head tag here. /foo:head foo:body print=true width=800 Body of page goes here. /foo:body /foo:html It is the job of the head and body tags to pull in the appropriate navs at the right time and plop them on the page. Currently the tags are a mess which involve some printlns, but mainly it has many includes from other assets. If I code the body of my page well - I can easily turn the same page into a printer friendy page or even a mobile device friendly page with these tags. (If I felt masochistic). But the above also has issues too if your site is content heavy and each content page becomes a JSP. In that case - you should really be publishing your content in an intermediate format and have it transformed dynamically by a single servlet instance so hundreds (or thousands) or JSP's are not instantiated on your server. -Tim Geoff Coffey wrote: You can do a compile time include instead of a run-time include. Tim: We wanted to avoid that because we're including quite a lot of stuff, and it is being included on every page. Naively, I felt that duplicating all that header and footer logic and HTML in every generated servlet would be unwise. But I'm very new to this, so I may be off base. The general setup is that we have the typical standardized header and footer, and some standardized, but conditional, navigation stuff. This is all part of two include files called, aptly, Header.jsp and Footer.jsp. These files are included on nearly every page, so that the page itself only needs to define its unique content. Our header performs the requisite check that the user is authenticated, and attempts to redirect to the login page if not. For some reason it worked fine until recently, perhaps coinciding with our switch to the latest stable tomcat. It seems like we need our authentication check and redirect (or forward) on the content page itself and not in an include, so Muffi created a taglib to encapsulate this check and that seems to be working. Is this a typical solution? It seems like a frustrating restriction to prevent redirects or forwards in includes. Does anybody know the reason for this limitation? Does anybody have a better way to accomplish what I'm describing? Thanks for all your help so far! Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect() - is this allowed?
if ( POST.equalsIgnoreCase( request.getMethod() ) ) { StringBuffer buf = new StringBuffer(); buf.append( request.getRequestURI() ); buf.append( ? ); buf.append( request.getQueryString() ); response.sendRedirect( buf.toString() ); return; } You need to be careful doing this actually... While it will work in most cases, if the data + URL is longer than 2048 bytes it will fail (for RFC-compliant browsers) as 2048 bytes is the limit on GET. In this case data will be truncated after 2048 bytes and there is a risk of crashes or incorrect data being sent to the process-function. GET also exposes all the arguments on the URL line which can be messy and dangerous if the form contained sensitive information. If the data length + URL length is longer than 2048 bytes, or to stop double-posts, use the following method, which is sometimes called POST-cleaning: - Use POST as the method - When the servlet/JSP processes the POST, first check the data and display error messages for missing-data etc.. (data-validation). - If there are no errors, *do not* output anything, just process the data. - After processing, use sendRedirect() to send the user to a page that displays the output (eg: Thankyou for your submission, or Update successful, or send them back to the menu etc..). Now the final page is retrieved with a GET, has no 2k-limit on the data for thr processing, and has no displayed URL params. - Instead of setting sendRedirect(), also consider using setHeader calls to set the status to 302 with the new location, and also output a meta-refresh tag which sends the user to the final page and/or some javascript which sends them to the final page (or at worst a link saying click here to continue). Now you have 4 methods to make sure they continue to the result-page instead of relying on the 302. - Use sessions or a URL token to maintain the state, because after sendRedirect(), the servlet will be called again with a GET, and you will need some way to figure out who the client is and what data was submitted in case you need to display it again. Hope that helps, Neale Rudd metawerx java hosting http://www.metawerx.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendRedirect() - is this allowed?
Arbitrarily changing a POST to a GET can also end up in your customers ordering two sets of football tickets, rather than one. A repeat of a POST requires that the user be prompted, as POSTs are non-idempotent. Browsers can issue as many GET requests as they like in order to get the page downloaded (IE, for example, appears to just repeat a GET request if looks like the first attempt is taking too long). And as Neale says, having things like credit card numbers, passwords, etc., in your browser history isn't ideal. Finally, here's what HTTP/1.1 has to say on URI lengths: The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths. (from 3.2.1, General Syntax). We've run into a number of problems in the past in which application servers have transformed POSTs into GETs for their own internal reasons (usually to munge things into some MVC-esque structure), and dissappeared parameters off the end of the list. Very frustrating, and very tedious to debug :( Dan. -Original Message- From: Neale [mailto:[EMAIL PROTECTED]] Sent: 07 February 2003 09:01 To: Tomcat Users List Subject: Re: response.sendRedirect() - is this allowed? if ( POST.equalsIgnoreCase( request.getMethod() ) ) { StringBuffer buf = new StringBuffer(); buf.append( request.getRequestURI() ); buf.append( ? ); buf.append( request.getQueryString() ); response.sendRedirect( buf.toString() ); return; } You need to be careful doing this actually... While it will work in most cases, if the data + URL is longer than 2048 bytes it will fail (for RFC-compliant browsers) as 2048 bytes is the limit on GET. In this case data will be truncated after 2048 bytes and there is a risk of crashes or incorrect data being sent to the process-function. GET also exposes all the arguments on the URL line which can be messy and dangerous if the form contained sensitive information. If the data length + URL length is longer than 2048 bytes, or to stop double-posts, use the following method, which is sometimes called POST-cleaning: - Use POST as the method - When the servlet/JSP processes the POST, first check the data and display error messages for missing-data etc.. (data-validation). - If there are no errors, *do not* output anything, just process the data. - After processing, use sendRedirect() to send the user to a page that displays the output (eg: Thankyou for your submission, or Update successful, or send them back to the menu etc..). Now the final page is retrieved with a GET, has no 2k-limit on the data for thr processing, and has no displayed URL params. - Instead of setting sendRedirect(), also consider using setHeader calls to set the status to 302 with the new location, and also output a meta-refresh tag which sends the user to the final page and/or some javascript which sends them to the final page (or at worst a link saying click here to continue). Now you have 4 methods to make sure they continue to the result-page instead of relying on the 302. - Use sessions or a URL token to maintain the state, because after sendRedirect(), the servlet will be called again with a GET, and you will need some way to figure out who the client is and what data was submitted in case you need to display it again. Hope that helps, Neale Rudd metawerx java hosting http://www.metawerx.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect() - is this allowed?
It isn't against the HTTP specification to sendRedirect (which in Tomcat will result in a 302 response). It's just that very few (if any) browsers actually implement the spec in this area. Most of them will respond by doing a GET to the new URL, instead of a POST (which is what the RFC says to do). If you wanted to be completely safe with broken browsers, then you should also add the POSTed parameters to the query string in your example below. Julius Davies [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hello, Tomcat User's List, There was some talk a few days ago about response.sendRedirect() after a POST request being against the HTTP specification... is that really true? For example, would this be a problem? IE and Netscape seem to do what I want! // This is common trick I use after a form submission to // help make navigation easier for the user, and to help // avoid dual-submission of the same form. // // request is an HttpServletRequest and response // is an HttpServletResponse. if ( POST.equalsIgnoreCase( request.getMethod() ) ) { StringBuffer buf = new StringBuffer(); buf.append( request.getRequestURI() ); buf.append( ? ); buf.append( request.getQueryString() ); response.sendRedirect( buf.toString() ); return; } I would appreciate any advice anyone might have. yours, Julius Davies, Programmer, CUCBC Email: [EMAIL PROTECTED], Ph: 604.730.6385 This email represents my personal opinions and concerns and not those of CUCBC. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect() - is this allowed?
// This is common trick I use after a form submission to // help make navigation easier for the user, and to help // avoid dual-submission of the same form. // Not clear - how is the second submission avoided? if ( POST.equalsIgnoreCase( request.getMethod() ) ) { StringBuffer buf = new StringBuffer(); buf.append( request.getRequestURI() ); buf.append( ? ); buf.append( request.getQueryString() ); response.sendRedirect( buf.toString() ); return; } I have been using this technique for quite some time but I am not happy as all the POST data appears in the query string straight away. What is a better way of passing data(possibly huge) to a redirected url? RequestDispatcher would do but I dont see the redirected url at the browser if I use it. ~rf __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect() - is this allowed?
rf [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... // This is common trick I use after a form submission to // help make navigation easier for the user, and to help // avoid dual-submission of the same form. // Not clear - how is the second submission avoided? if ( POST.equalsIgnoreCase( request.getMethod() ) ) { StringBuffer buf = new StringBuffer(); buf.append( request.getRequestURI() ); buf.append( ? ); buf.append( request.getQueryString() ); response.sendRedirect( buf.toString() ); return; } I have been using this technique for quite some time but I am not happy as all the POST data appears in the query string straight away. What is a better way of passing data(possibly huge) to a redirected url? RequestDispatcher would do but I dont see the redirected url at the browser if I use it. The above code is harmless, and will work with any browser that actually implements the RFC (AFAIK, this is the empty set :). For broken browsers, you have the choice of either storing the POST data in the session (and use URL re-writing for safety), or copying it to the query-string. ~rf __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.sendRedirect() - is this allowed?
Further to this, the W3 recognized the fact that many clients did not adhere to the specification for 302 and 303, so they introduced 307 in HTTP 1.1--which was intended to be followed more strictly. The original method must be used when following a re-direct, but when a non-idempotent method is used (i.e.: POST), the client must obtain confirmation from the user before following the re-direct. Only handled by HTTP 1.1 capable browsers only. :-( At 20:50 2003-02-06 -0800, you wrote: It isn't against the HTTP specification to sendRedirect (which in Tomcat will result in a 302 response). It's just that very few (if any) browsers actually implement the spec in this area. Most of them will respond by doing a GET to the new URL, instead of a POST (which is what the RFC says to do). If you wanted to be completely safe with broken browsers, then you should also add the POSTed parameters to the query string in your example below. Julius Davies [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hello, Tomcat User's List, There was some talk a few days ago about response.sendRedirect() after a POST request being against the HTTP specification... is that really true? For example, would this be a problem? IE and Netscape seem to do what I want! // This is common trick I use after a form submission to // help make navigation easier for the user, and to help // avoid dual-submission of the same form. // // request is an HttpServletRequest and response // is an HttpServletResponse. if ( POST.equalsIgnoreCase( request.getMethod() ) ) { StringBuffer buf = new StringBuffer(); buf.append( request.getRequestURI() ); buf.append( ? ); buf.append( request.getQueryString() ); response.sendRedirect( buf.toString() ); return; } I would appreciate any advice anyone might have. yours, Julius Davies, Programmer, CUCBC Email: [EMAIL PROTECTED], Ph: 604.730.6385 This email represents my personal opinions and concerns and not those of CUCBC. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sean Dockery [EMAIL PROTECTED] Certified Java Web Component Developer Certified Delphi Programmer SBD Consultants http://www.sbdconsultants.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.sendRedirect not redirecting
Thanks a lot, it worked! What does return do? -Original Message- From: Brian Adams [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 17, 2002 8:05 PM To: Tomcat Users List Subject: RE: response.sendRedirect not redirecting add return; just after response.sendR. -Original Message- From: Mostafa Al-Mallawani [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 17, 2002 7:12 AM To: 'Tomcat Users List' Subject: response.sendRedirect not redirecting Hi, I have a problem with redirecting. In my JSP page I keep checking for errors, whenever I catch one, I set a variable on the session object and then forward to an error page; this could happen up to 5 times in one page. The weird thing is, redirection works on some pages and does absolutely nothing on some other pages. Execution just passes over response.sendRedirect(../error.jsp); like it doesn't even exist. Please help, this is really frustrating. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 3:45 PM To: [EMAIL PROTECTED] Subject: RE: How can I resolve this IllegalStateException: Response has a lrea dy been committed problem? The exception seems to be occurring because the Home servlet forwards more than once (to different locations) - first to home.jsp, then later to the Create servlet. It is definitely the fact that it is forwarding to more than one place, that is causing the problem. I know this because if I call the Login servlet and fail the login authorization - this servlet consequently forwards to login.jsp more than once (first - to display the fresh login page, and second - to prompt user to try again). This however does not give me an exception. Given that my Home servlet is like the central servlet, it needs to be capable of forwarding to a variety of places, depending on the activity selected by the user. Ryan - I have looked at create.jsp and, as far as my little mind can see, it does not play with the response object at all. All it does is get a few session attributes and fit them into the page using %= blablabla %. Could that be a problem? This problem is not isolated to the Create example. There are other activities the user can choose which all follow exactly the same forwarding mechanism (except to different servlets), and these give exactly the same exception. Lindsay -Original Message- From: Ryan Daigle [mailto:[EMAIL PROTECTED]] Sent: 08 March 2002 13:25 To: 'Tomcat Users List' Subject:RE: How can I resolve this IllegalStateException: Response has a lrea dy been committed problem? Are you sure there isn't something in create.jsp that is trying to manipulate the response? I have found that trying to do a jsp:include... after manipulating the session can cause this exception. Is this a possibility? Perhaps you could send the relevant source of create.jsp and the Create servlet? -Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 8:26 AM To: [EMAIL PROTECTED] Subject: RE: How can I resolve this IllegalStateException: Response has a lrea dy been committed problem? OK here's the sequence of events: [ Note: all forwarding done using RequestDispatcher.forward(req,res) ] 1. User begins by clicking link to Login servlet 2. Login servlet forwards to login.jsp 3. Login.jsp submits request to Login servlet 4. Servlet authorizes user and forwards to Home servlet 5. Home servlet forwards to home.jsp NO EXCEPTIONS YET - EVERYTHING IS OK! 6. User then chooses an action (e.g. create new agent, in my example) from home.jsp and submits request to Home servlet 7. Home servlet processes request and forwards to appropriate servlet (called Create in my example) 8. Create servlet does some stuff and forwards to create.jsp BANG! I GET THIS EXCEPTION (I have included some buildup to this exception): Now in Home servlet - processing request... 2002-03-08 13:19:08 - DecodeInterceptor: Charset from session ISO-8859-1 Now in Create servlet - processing request... Getting list of available types seems to have went OK 2002-03-08 13:19:09 - Ctx(/AgentGenerator) : IllegalStateException in R( /AgentGenerator + /create.jsp + null) - java.la ng.IllegalStateException: Cannot forward because the response has already been committed at org.apache.tomcat.facade.RequestDispatcherImpl.doForward(Unknown Source) at org.apache.tomcat.facade.RequestDispatcherImpl.forward(Unknown Source) at zeus.generator.web.controllers.Home.goToAddress(Home.java:157) at zeus.generator.web.controllers.Home.processRequest(Home.java:120) at zeus.generator.web.controllers.Home.doGet(Home.java:131) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(Unknown Source) at org.apache.tomcat.core.Handler.invoke(Unknown
Re: response.sendRedirect not redirecting
--- Mostafa Al-Mallawani [EMAIL PROTECTED] wrote: Hi, I have a problem with redirecting. In my JSP page I keep checking for errors, whenever I catch one, I set a variable on the session object and then forward to an error page; this could happen up to 5 times in one page. The weird thing is, redirection works on some pages and does absolutely nothing on some other pages. Execution just passes over response.sendRedirect(../error.jsp); like it doesn't even exist. Please help, this is really frustrating. Thanks. I am guessing that this happens because you are calling sendRedirect after writing something to the response that causes it to be committed. Once the servlet container (tomcat) considers the response committed it can start streaming it to the browser, and so at that point it's kind-of too late to change your mind and redirect. Attempting to redirect at this point will cause an IllegalStateException. Maybe your error catching code is eating this exception. Look at the JavaDocs for the Servlet API, specifically HttpServletResponse.sendRedirect() for a clearer explaination. Hope this helps, -Chris __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: response.sendRedirect not redirecting
add return; just after response.sendR. -Original Message- From: Mostafa Al-Mallawani [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 17, 2002 7:12 AM To: 'Tomcat Users List' Subject: response.sendRedirect not redirecting Hi, I have a problem with redirecting. In my JSP page I keep checking for errors, whenever I catch one, I set a variable on the session object and then forward to an error page; this could happen up to 5 times in one page. The weird thing is, redirection works on some pages and does absolutely nothing on some other pages. Execution just passes over response.sendRedirect(../error.jsp); like it doesn't even exist. Please help, this is really frustrating. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 3:45 PM To: [EMAIL PROTECTED] Subject: RE: How can I resolve this IllegalStateException: Response has a lrea dy been committed problem? The exception seems to be occurring because the Home servlet forwards more than once (to different locations) - first to home.jsp, then later to the Create servlet. It is definitely the fact that it is forwarding to more than one place, that is causing the problem. I know this because if I call the Login servlet and fail the login authorization - this servlet consequently forwards to login.jsp more than once (first - to display the fresh login page, and second - to prompt user to try again). This however does not give me an exception. Given that my Home servlet is like the central servlet, it needs to be capable of forwarding to a variety of places, depending on the activity selected by the user. Ryan - I have looked at create.jsp and, as far as my little mind can see, it does not play with the response object at all. All it does is get a few session attributes and fit them into the page using %= blablabla %. Could that be a problem? This problem is not isolated to the Create example. There are other activities the user can choose which all follow exactly the same forwarding mechanism (except to different servlets), and these give exactly the same exception. Lindsay -Original Message- From: Ryan Daigle [mailto:[EMAIL PROTECTED]] Sent: 08 March 2002 13:25 To: 'Tomcat Users List' Subject:RE: How can I resolve this IllegalStateException: Response has a lrea dy been committed problem? Are you sure there isn't something in create.jsp that is trying to manipulate the response? I have found that trying to do a jsp:include... after manipulating the session can cause this exception. Is this a possibility? Perhaps you could send the relevant source of create.jsp and the Create servlet? -Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 8:26 AM To: [EMAIL PROTECTED] Subject: RE: How can I resolve this IllegalStateException: Response has a lrea dy been committed problem? OK here's the sequence of events: [ Note: all forwarding done using RequestDispatcher.forward(req,res) ] 1. User begins by clicking link to Login servlet 2. Login servlet forwards to login.jsp 3. Login.jsp submits request to Login servlet 4. Servlet authorizes user and forwards to Home servlet 5. Home servlet forwards to home.jsp NO EXCEPTIONS YET - EVERYTHING IS OK! 6. User then chooses an action (e.g. create new agent, in my example) from home.jsp and submits request to Home servlet 7. Home servlet processes request and forwards to appropriate servlet (called Create in my example) 8. Create servlet does some stuff and forwards to create.jsp BANG! I GET THIS EXCEPTION (I have included some buildup to this exception): Now in Home servlet - processing request... 2002-03-08 13:19:08 - DecodeInterceptor: Charset from session ISO-8859-1 Now in Create servlet - processing request... Getting list of available types seems to have went OK 2002-03-08 13:19:09 - Ctx(/AgentGenerator) : IllegalStateException in R( /AgentGenerator + /create.jsp + null) - java.la ng.IllegalStateException: Cannot forward because the response has already been committed at org.apache.tomcat.facade.RequestDispatcherImpl.doForward(Unknown Source) at org.apache.tomcat.facade.RequestDispatcherImpl.forward(Unknown Source) at zeus.generator.web.controllers.Home.goToAddress(Home.java:157) at zeus.generator.web.controllers.Home.processRequest(Home.java:120) at zeus.generator.web.controllers.Home.doGet(Home.java:131) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(Unknown Source) at org.apache.tomcat.core.Handler.invoke(Unknown Source) at org.apache.tomcat.core.Handler.service(Unknown Source) at org.apache.tomcat.facade.ServletHandler.service(Unknown Source) at org.apache.tomcat.core.ContextManager.internalService(Unknown Source)
RE: response.sendRedirect
Poking fun have you // your session.invalidate and tried it? :) sorry it begged the question! my answer is dunno, try commenting it out and then try it or swapping the two lines /Poking fun -Original Message- From: Jerry Jalenak [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 17, 2002 2:26 PM To: '[EMAIL PROTECTED]' Subject: response.sendRedirect I have the following code snipet in a .JSP... if (userStatus.equals (Failed)) { session.invalidate() ; // Kill this session. response.sendRedirect(htmlHome) ; // Redirect the user to our home page. return ; } When this condition occurs, the response.sendRedirect fails with the following message: javax.servlet.ServletException: Response has already been committed According to the response object documentation, the sendRedirect 'must be called before the response is committed (in other words, before the status code and headers have been written).' Obviously, the response has been committed, else I wouldn't be getting the error! My question - is the session.invalidate() doing this to me, or is it something else that I am completely unaware of? Thanks. Jerry Jalenak LabOne, Inc. This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: response.sendRedirect
Yeah, I have. I'm also getting it now outside of the snipnet, when I am just wanting to redirect to another page. Should I be using jsp:forward instead? Jerry -Original Message- From: Brian Adams [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 17, 2002 2:08 PM To: 'Tomcat Users List' Subject: RE: response.sendRedirect Poking fun have you // your session.invalidate and tried it? :) sorry it begged the question! my answer is dunno, try commenting it out and then try it or swapping the two lines /Poking fun -Original Message- From: Jerry Jalenak [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 17, 2002 2:26 PM To: '[EMAIL PROTECTED]' Subject: response.sendRedirect I have the following code snipet in a .JSP... if (userStatus.equals (Failed)) { session.invalidate() ; // Kill this session. response.sendRedirect(htmlHome) ; // Redirect the user to our home page. return ; } When this condition occurs, the response.sendRedirect fails with the following message: javax.servlet.ServletException: Response has already been committed According to the response object documentation, the sendRedirect 'must be called before the response is committed (in other words, before the status code and headers have been written).' Obviously, the response has been committed, else I wouldn't be getting the error! My question - is the session.invalidate() doing this to me, or is it something else that I am completely unaware of? Thanks. Jerry Jalenak LabOne, Inc. This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: response.sendRedirect
Do you have any html tags in your jsp file before the logic you mention? Also, what jsp spec are you using? -Original Message- From: Jerry Jalenak [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 17, 2002 3:26 PM To: '[EMAIL PROTECTED]' Subject: response.sendRedirect I have the following code snipet in a .JSP... if (userStatus.equals (Failed)) { session.invalidate() ; // Kill this session. response.sendRedirect(htmlHome) ; // Redirect the user to our home page. return ; } When this condition occurs, the response.sendRedirect fails with the following message: javax.servlet.ServletException: Response has already been committed According to the response object documentation, the sendRedirect 'must be called before the response is committed (in other words, before the status code and headers have been written).' Obviously, the response has been committed, else I wouldn't be getting the error! My question - is the session.invalidate() doing this to me, or is it something else that I am completely unaware of? Thanks. Jerry Jalenak LabOne, Inc. This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: response.sendRedirect problems with IE5.5
Calling response.sendRedirect does not stop the execution of a JSP page. You are responsible for returning from the _jspService method after calling sendRedirect (by placing a return statement in your JSP). What is actually happening is that Netscape is thinking that its smarter than the web developer by ignoring everything after the redirect command while IE is actually doing the correct thing (for once) and showing all the HTML returned by the server. Randy -Original Message- From: Eric Simpson [mailto:[EMAIL PROTECTED]] Sent: Friday, August 24, 2001 4:42 PM To: [EMAIL PROTECTED] Subject: response.sendRedirect problems with IE5.5 When I call the response.sendRedirect() function from a Java Bean I get a response that already has data in it, the only problem is that the response shouldn't have any data in it already. I have a function call before anything is written to the output buffer that determines if this page should call a response.sendRedirect(). The weird thing is that only IE has the data that shouldn't be returned in the html page (from the view source option). Netscape doesn't have the garbage data when I view source. What is going on here? Info: Tomcat 3.2.3 jdk1.2.2 NT 4.0 ### data that shouldn't be returned ### !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN http://www.w3.org/TR/REC-html40/loose.dtd; html head ... omitted data ... CircImage4.src = HTTP/1.1 200 OK Via: 1.0 MAIL Connection: Keep-Alive Content-Length: 1536 Content-Type: text/html Last-Modified: Thu, 16 Aug 2001 16:54:28 GMT Servlet-Engine: Tomcat Web Server/3.2.3 (JSP 1.1; Servlet 2.2; Java 1.2.2; Windows NT 4.0 x86; java.vendor=Sun Microsystems Inc.) ### page that should be returned ### html head ... rest of response ... ### relevent parts of index. jsp ### /*** session operations ***/ try { sessionBean.setResponse(response); sessionBean.setRequest(request); sessionBean.setIP(request.getRemoteAddr()); sessionBean.setFile(path + name); sessionBean.log(); } catch(IOException ignored) { } catch(SQLException ignored) { } // output header,nav application.getRequestDispatcher(/main.jsp).include(request, response); // output static page if no processing needed on content if(proc == null || proc.equals(false)) { application.getRequestDispatcher(/static.jsp).include(reques t,response); } else { application.getRequestDispatcher(/ + name).include(request,response); } // output footer application.getRequestDispatcher(/footer.jsp).include(reques t,response); % ### relevent portion of SessionBean ### public void log() { ... if(visits == 1) { res.sendRedirect(/intro.html); } ... }
RE: response.sendRedirect vs. requestDispatcher.forward
So what is the correct way to redirect? I have started using relative links to redirect and it seems to fix the problem. Is this just coincidence, or is there an explanation for that? Brandon -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 6:38 PM To: [EMAIL PROTECTED] Subject: RE: response.sendRedirect vs. requestDispatcher.forward If you webserver is serving in /usr/local/apache/htdocs, you are redirecting to /usr/local/apache/htdocs/login.jsp, which is handled in this example by apache, who doesn't know anything about jsp files. (that's why you got tomcat in the first place...) Mvgr, Martin -Original Message- From: Brandon Cruz [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 1:31 AM To: [EMAIL PROTECTED] Subject: RE: response.sendRedirect vs. requestDispatcher.forward Has anyone figured out why response.sendRedirect(/login.jsp) will not work when using apache-tomcat with mod_jk? It gets all screwed up and prints a bunch of header information out to the page...is there a way around it besides using javascript to redirect the page? Brandon Cruz -Original Message- From: A Yang [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 1:13 PM To: [EMAIL PROTECTED] Subject: RE: response.sendRedirect vs. requestDispatcher.forward Hi, Thanks for the help. As it turns out, switching between requestDispath.forward and response.redirect will trip you up because of differences in what they expect as their parameters. RequestDispatch.forward takes a URL that is a RELATIVE path but also requires a leading slash. If you are brilliant (like myself) and you change your code to use response.encodeRedirectURL but you KEEP that leading slash, well then. Your response will treat it like an absolute path and wind up plunking you into a different servlet context, which Tomcat will generate a new session for. Thanks again for your help, Andy --- Martin van den Bemt [EMAIL PROTECTED] wrote: A different hostname creates a new session which could be the problem here.. (so http://www.example.com and http://example.com create a different session even it's the same server/context/etc.. Mvgr, Martin -Original Message- From: Alex Fernandez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 4:57 PM To: [EMAIL PROTECTED] Subject: Re: response.sendRedirect vs. requestDispatcher.forward Conceptually, requestDispatcher.forward() is different from response.sendRedirect(). In forward(), you are moving inside the same webapp, and as such it doesn't even reach the client browser. The session is maintained. In sendRedirect(), you're instead moving across webapps, and it's the browser that redirects to the specified location. In fact, it doesn't even need to be another servlet, you may redirect to an ASP or a static page. New request and response are created. It seems strange that the session is not maintained, though, since both requests come from the same browser. Perhaps it's a bug? Un saludo, Alex. A Yang wrote: Hi All, Does anyone know offhand whether the Java Servlet specification requires a new HttpSession to be created when using HttpServletResponse.sendRedirect()? In a servlet, I was using: getServletConfig().getServletContext().getRequestDispatcher(/Resu lt.jsp).forward(req, resp); at the end of a sequence of pages/servlets, but I wanted to replace it with response.sendRedirect(/Result.jsp); instead. The result page prints out the contents of several javabeans which are stored in the session. This worked fine when all I used were requestDispatcher.forward but with response.sendRedirect(), all of my session attributes are gone! In fact, the session id is different after the sendRedirect. I'm pretty sure the session is supposed to survive across any series of GET's and POST's until it is invalidated explicitly (or timed out). Any thoughts? I'm using Tomcat 3.2.1 Thanks. ___ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca ___ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca
Re: response.sendRedirect vs. requestDispatcher.forward
Hi Andy! Just a fine point here. A Yang wrote: RequestDispatch.forward takes a URL that is a RELATIVE path but also requires a leading slash. From the javadoc of ServletRequest.getRequestDispatcher(String): 'The pathname specified may be relative, although it cannot extend outside the current servlet context. If the path begins with a / it is interpreted as relative to the current context root. This method returns null if the servlet container cannot return a RequestDispatcher. The difference between this method and ServletContext.getRequestDispatcher(String) is that this method can take a relative path.' So, if you get your RequestDispatcher from the request, you don't need the leading /. Un saludo, Alex.
RE: response.sendRedirect vs. requestDispatcher.forward
Hi, Never used the reqeuestdispatcher, but in your case it could be something like : response.sendRedirect(http://servername/context/login.jsp); (don't know where tomcat is serving jsp files though, I never use them..) Mvgr, Martin -Original Message- From: Brandon Cruz [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 3:26 PM To: [EMAIL PROTECTED] Subject: RE: response.sendRedirect vs. requestDispatcher.forward So what is the correct way to redirect? I have started using relative links to redirect and it seems to fix the problem. Is this just coincidence, or is there an explanation for that? Brandon -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 6:38 PM To: [EMAIL PROTECTED] Subject: RE: response.sendRedirect vs. requestDispatcher.forward If you webserver is serving in /usr/local/apache/htdocs, you are redirecting to /usr/local/apache/htdocs/login.jsp, which is handled in this example by apache, who doesn't know anything about jsp files. (that's why you got tomcat in the first place...) Mvgr, Martin -Original Message- From: Brandon Cruz [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 1:31 AM To: [EMAIL PROTECTED] Subject: RE: response.sendRedirect vs. requestDispatcher.forward Has anyone figured out why response.sendRedirect(/login.jsp) will not work when using apache-tomcat with mod_jk? It gets all screwed up and prints a bunch of header information out to the page...is there a way around it besides using javascript to redirect the page? Brandon Cruz -Original Message- From: A Yang [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 1:13 PM To: [EMAIL PROTECTED] Subject: RE: response.sendRedirect vs. requestDispatcher.forward Hi, Thanks for the help. As it turns out, switching between requestDispath.forward and response.redirect will trip you up because of differences in what they expect as their parameters. RequestDispatch.forward takes a URL that is a RELATIVE path but also requires a leading slash. If you are brilliant (like myself) and you change your code to use response.encodeRedirectURL but you KEEP that leading slash, well then. Your response will treat it like an absolute path and wind up plunking you into a different servlet context, which Tomcat will generate a new session for. Thanks again for your help, Andy --- Martin van den Bemt [EMAIL PROTECTED] wrote: A different hostname creates a new session which could be the problem here.. (so http://www.example.com and http://example.com create a different session even it's the same server/context/etc.. Mvgr, Martin -Original Message- From: Alex Fernandez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 4:57 PM To: [EMAIL PROTECTED] Subject: Re: response.sendRedirect vs. requestDispatcher.forward Conceptually, requestDispatcher.forward() is different from response.sendRedirect(). In forward(), you are moving inside the same webapp, and as such it doesn't even reach the client browser. The session is maintained. In sendRedirect(), you're instead moving across webapps, and it's the browser that redirects to the specified location. In fact, it doesn't even need to be another servlet, you may redirect to an ASP or a static page. New request and response are created. It seems strange that the session is not maintained, though, since both requests come from the same browser. Perhaps it's a bug? Un saludo, Alex. A Yang wrote: Hi All, Does anyone know offhand whether the Java Servlet specification requires a new HttpSession to be created when using HttpServletResponse.sendRedirect()? In a servlet, I was using: getServletConfig().getServletContext().getRequestDispatcher(/Resu lt.jsp).forward(req, resp); at the end of a sequence of pages/servlets, but I wanted to replace it with response.sendRedirect(/Result.jsp); instead. The result page prints out the contents of several javabeans which are stored in the session. This worked fine when all I used were requestDispatcher.forward but with response.sendRedirect(), all of my session attributes are gone! In fact, the session id is different after the sendRedirect. I'm pretty sure the session is supposed to survive across any series of GET's and POST's until it is invalidated explicitly (or timed out). Any thoughts? I'm using Tomcat 3.2.1 Thanks. ___ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca
RE: response.sendRedirect vs. requestDispatcher.forward
Hi, Thanks for the help. As it turns out, switching between requestDispath.forward and response.redirect will trip you up because of differences in what they expect as their parameters. RequestDispatch.forward takes a URL that is a RELATIVE path but also requires a leading slash. If you are brilliant (like myself) and you change your code to use response.encodeRedirectURL but you KEEP that leading slash, well then. Your response will treat it like an absolute path and wind up plunking you into a different servlet context, which Tomcat will generate a new session for. Thanks again for your help, Andy --- Martin van den Bemt [EMAIL PROTECTED] wrote: A different hostname creates a new session which could be the problem here.. (so http://www.example.com and http://example.com create a different session even it's the same server/context/etc.. Mvgr, Martin -Original Message- From: Alex Fernandez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 4:57 PM To: [EMAIL PROTECTED] Subject: Re: response.sendRedirect vs. requestDispatcher.forward Conceptually, requestDispatcher.forward() is different from response.sendRedirect(). In forward(), you are moving inside the same webapp, and as such it doesn't even reach the client browser. The session is maintained. In sendRedirect(), you're instead moving across webapps, and it's the browser that redirects to the specified location. In fact, it doesn't even need to be another servlet, you may redirect to an ASP or a static page. New request and response are created. It seems strange that the session is not maintained, though, since both requests come from the same browser. Perhaps it's a bug? Un saludo, Alex. A Yang wrote: Hi All, Does anyone know offhand whether the Java Servlet specification requires a new HttpSession to be created when using HttpServletResponse.sendRedirect()? In a servlet, I was using: getServletConfig().getServletContext().getRequestDispatcher(/Resu lt.jsp).forward(req, resp); at the end of a sequence of pages/servlets, but I wanted to replace it with response.sendRedirect(/Result.jsp); instead. The result page prints out the contents of several javabeans which are stored in the session. This worked fine when all I used were requestDispatcher.forward but with response.sendRedirect(), all of my session attributes are gone! In fact, the session id is different after the sendRedirect. I'm pretty sure the session is supposed to survive across any series of GET's and POST's until it is invalidated explicitly (or timed out). Any thoughts? I'm using Tomcat 3.2.1 Thanks. ___ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca ___ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca
RE: response.sendRedirect vs. requestDispatcher.forward
Has anyone figured out why response.sendRedirect(/login.jsp) will not work when using apache-tomcat with mod_jk? It gets all screwed up and prints a bunch of header information out to the page...is there a way around it besides using javascript to redirect the page? Brandon Cruz -Original Message- From: A Yang [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 1:13 PM To: [EMAIL PROTECTED] Subject: RE: response.sendRedirect vs. requestDispatcher.forward Hi, Thanks for the help. As it turns out, switching between requestDispath.forward and response.redirect will trip you up because of differences in what they expect as their parameters. RequestDispatch.forward takes a URL that is a RELATIVE path but also requires a leading slash. If you are brilliant (like myself) and you change your code to use response.encodeRedirectURL but you KEEP that leading slash, well then. Your response will treat it like an absolute path and wind up plunking you into a different servlet context, which Tomcat will generate a new session for. Thanks again for your help, Andy --- Martin van den Bemt [EMAIL PROTECTED] wrote: A different hostname creates a new session which could be the problem here.. (so http://www.example.com and http://example.com create a different session even it's the same server/context/etc.. Mvgr, Martin -Original Message- From: Alex Fernandez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 4:57 PM To: [EMAIL PROTECTED] Subject: Re: response.sendRedirect vs. requestDispatcher.forward Conceptually, requestDispatcher.forward() is different from response.sendRedirect(). In forward(), you are moving inside the same webapp, and as such it doesn't even reach the client browser. The session is maintained. In sendRedirect(), you're instead moving across webapps, and it's the browser that redirects to the specified location. In fact, it doesn't even need to be another servlet, you may redirect to an ASP or a static page. New request and response are created. It seems strange that the session is not maintained, though, since both requests come from the same browser. Perhaps it's a bug? Un saludo, Alex. A Yang wrote: Hi All, Does anyone know offhand whether the Java Servlet specification requires a new HttpSession to be created when using HttpServletResponse.sendRedirect()? In a servlet, I was using: getServletConfig().getServletContext().getRequestDispatcher(/Resu lt.jsp).forward(req, resp); at the end of a sequence of pages/servlets, but I wanted to replace it with response.sendRedirect(/Result.jsp); instead. The result page prints out the contents of several javabeans which are stored in the session. This worked fine when all I used were requestDispatcher.forward but with response.sendRedirect(), all of my session attributes are gone! In fact, the session id is different after the sendRedirect. I'm pretty sure the session is supposed to survive across any series of GET's and POST's until it is invalidated explicitly (or timed out). Any thoughts? I'm using Tomcat 3.2.1 Thanks. ___ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca ___ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca
RE: response.sendRedirect vs. requestDispatcher.forward
If you webserver is serving in /usr/local/apache/htdocs, you are redirecting to /usr/local/apache/htdocs/login.jsp, which is handled in this example by apache, who doesn't know anything about jsp files. (that's why you got tomcat in the first place...) Mvgr, Martin -Original Message- From: Brandon Cruz [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 1:31 AM To: [EMAIL PROTECTED] Subject: RE: response.sendRedirect vs. requestDispatcher.forward Has anyone figured out why response.sendRedirect(/login.jsp) will not work when using apache-tomcat with mod_jk? It gets all screwed up and prints a bunch of header information out to the page...is there a way around it besides using javascript to redirect the page? Brandon Cruz -Original Message- From: A Yang [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 1:13 PM To: [EMAIL PROTECTED] Subject: RE: response.sendRedirect vs. requestDispatcher.forward Hi, Thanks for the help. As it turns out, switching between requestDispath.forward and response.redirect will trip you up because of differences in what they expect as their parameters. RequestDispatch.forward takes a URL that is a RELATIVE path but also requires a leading slash. If you are brilliant (like myself) and you change your code to use response.encodeRedirectURL but you KEEP that leading slash, well then. Your response will treat it like an absolute path and wind up plunking you into a different servlet context, which Tomcat will generate a new session for. Thanks again for your help, Andy --- Martin van den Bemt [EMAIL PROTECTED] wrote: A different hostname creates a new session which could be the problem here.. (so http://www.example.com and http://example.com create a different session even it's the same server/context/etc.. Mvgr, Martin -Original Message- From: Alex Fernandez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 4:57 PM To: [EMAIL PROTECTED] Subject: Re: response.sendRedirect vs. requestDispatcher.forward Conceptually, requestDispatcher.forward() is different from response.sendRedirect(). In forward(), you are moving inside the same webapp, and as such it doesn't even reach the client browser. The session is maintained. In sendRedirect(), you're instead moving across webapps, and it's the browser that redirects to the specified location. In fact, it doesn't even need to be another servlet, you may redirect to an ASP or a static page. New request and response are created. It seems strange that the session is not maintained, though, since both requests come from the same browser. Perhaps it's a bug? Un saludo, Alex. A Yang wrote: Hi All, Does anyone know offhand whether the Java Servlet specification requires a new HttpSession to be created when using HttpServletResponse.sendRedirect()? In a servlet, I was using: getServletConfig().getServletContext().getRequestDispatcher(/Resu lt.jsp).forward(req, resp); at the end of a sequence of pages/servlets, but I wanted to replace it with response.sendRedirect(/Result.jsp); instead. The result page prints out the contents of several javabeans which are stored in the session. This worked fine when all I used were requestDispatcher.forward but with response.sendRedirect(), all of my session attributes are gone! In fact, the session id is different after the sendRedirect. I'm pretty sure the session is supposed to survive across any series of GET's and POST's until it is invalidated explicitly (or timed out). Any thoughts? I'm using Tomcat 3.2.1 Thanks. ___ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca ___ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca
Re: response.sendRedirect vs. requestDispatcher.forward
Conceptually, requestDispatcher.forward() is different from response.sendRedirect(). In forward(), you are moving inside the same webapp, and as such it doesn't even reach the client browser. The session is maintained. In sendRedirect(), you're instead moving across webapps, and it's the browser that redirects to the specified location. In fact, it doesn't even need to be another servlet, you may redirect to an ASP or a static page. New request and response are created. It seems strange that the session is not maintained, though, since both requests come from the same browser. Perhaps it's a bug? Un saludo, Alex. A Yang wrote: Hi All, Does anyone know offhand whether the Java Servlet specification requires a new HttpSession to be created when using HttpServletResponse.sendRedirect()? In a servlet, I was using: getServletConfig().getServletContext().getRequestDispatcher(/Result.jsp).forward(req, resp); at the end of a sequence of pages/servlets, but I wanted to replace it with response.sendRedirect(/Result.jsp); instead. The result page prints out the contents of several javabeans which are stored in the session. This worked fine when all I used were requestDispatcher.forward but with response.sendRedirect(), all of my session attributes are gone! In fact, the session id is different after the sendRedirect. I'm pretty sure the session is supposed to survive across any series of GET's and POST's until it is invalidated explicitly (or timed out). Any thoughts? I'm using Tomcat 3.2.1 Thanks. ___ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca
RE: response.sendRedirect vs. requestDispatcher.forward
A different hostname creates a new session which could be the problem here.. (so http://www.example.com and http://example.com create a different session even it's the same server/context/etc.. Mvgr, Martin -Original Message- From: Alex Fernandez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 4:57 PM To: [EMAIL PROTECTED] Subject: Re: response.sendRedirect vs. requestDispatcher.forward Conceptually, requestDispatcher.forward() is different from response.sendRedirect(). In forward(), you are moving inside the same webapp, and as such it doesn't even reach the client browser. The session is maintained. In sendRedirect(), you're instead moving across webapps, and it's the browser that redirects to the specified location. In fact, it doesn't even need to be another servlet, you may redirect to an ASP or a static page. New request and response are created. It seems strange that the session is not maintained, though, since both requests come from the same browser. Perhaps it's a bug? Un saludo, Alex. A Yang wrote: Hi All, Does anyone know offhand whether the Java Servlet specification requires a new HttpSession to be created when using HttpServletResponse.sendRedirect()? In a servlet, I was using: getServletConfig().getServletContext().getRequestDispatcher(/Resu lt.jsp).forward(req, resp); at the end of a sequence of pages/servlets, but I wanted to replace it with response.sendRedirect(/Result.jsp); instead. The result page prints out the contents of several javabeans which are stored in the session. This worked fine when all I used were requestDispatcher.forward but with response.sendRedirect(), all of my session attributes are gone! In fact, the session id is different after the sendRedirect. I'm pretty sure the session is supposed to survive across any series of GET's and POST's until it is invalidated explicitly (or timed out). Any thoughts? I'm using Tomcat 3.2.1 Thanks. ___ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca
Re: response.sendRedirect and target
Here is a little JavaScript function you can call from the "onload" of the body tag that will assure your page is the topmost page: /*/ function setAsTop() { if (top.location != self.location) top.location = self.location; } /*/ --- Carlos [EMAIL PROTECTED] wrote: if i have: response.sendRedirect("page.jsp"); how can i put in a target=_top the redirect? thanks Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] = Wyn Easton [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: response.sendRedirect() and NSAPI redirection...
I ran into this problem with NTWorkstation4.0 running Apache Web server and Tomcat 3.2.1 Apache has a config file,httpd.conf, which references a Servername variable. I set this variable name to what is defined in the host file, which is "localhost". Perhaps the iplanet web server has a similar config file that needs to be modified as well. Hope this helps! Original Message- From: "Dean Des Rosiers" [EMAIL PROTECTED] To: "[EMAIL PROTECTED]" [EMAIL PROTECTED] Cc: Bcc: Subj: response.sendRedirect() and NSAPI redirection... Type: IPM.Note Sent: Tuesday, January 23, 2001 11:44 AM Hello, All. I have a legacy web app running under iPlanet Web Server 4.1. I have configured the app to run under Tomcat 3.2 and it runs fine. Our app needs iPlanet's additional speed in handling static content, though, so I configured iPlanet to use the NSAPI redirector. Everything seems to work fine except for response.sendRedirect(). Ordinarily we use a relative path as the argument to this method, but full paths seem to fail as well. Again, everything works fine under Tomcat alone (port 8080). When I use iPlanet and the NSAPI redirector (port 8082 - it's a testing configuration) things don't work. Thanks in advance, Dean Des Rosiers Digital Artisans, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: response.sendRedirect bug or feature
Add a return statement: if (a b) { response.sendRedirect(url1); return; } // Do something else! response.sendRedirect(url1); -Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Zsolt Koppany Sent: Thursday, December 07, 2000 12:30 AM To: [EMAIL PROTECTED] Subject: response.sendRedirect bug or feature Hi, I think it might have been changed since tomcat-3.2-beta-6 but now when I execute a response.sendRedirect(..) the rest of the jsp file is still executed. How can I prevent that? My example: if (a b) { response.sendRedirect(url1); // Here I don't want to proceed this jsp file because url1 creates a complete page on its own. } // Let's do somthing else! ... response.sendRedirect(url2); Zsolt -- Zsolt Koppany Intland GmbH www.intland.com Schulze-Delitzsch-Strasse 16 D-70565 Stuttgart Tel: +49-711-7871080 Fax: +49-711-7871017
Re: response.sendRedirect stops working in Apache/Tomcat setup
Instead of redirecting, try forwarding like this: getServletConfig().getServletContext().getRequestDispatcher("/jsp/forwardto.jsp").forward(request, response); Leon - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 30, 2000 6:44 AM Subject: response.sendRedirect stops working in Apache/Tomcat setup Hi!I recently setup my Tomcat to run integrated with Apache. Everything worked fine, except that any jsp-page that contained a response.sendRedirect stopped redirecting. I don't get any response at all. Any clues?Thanks!/Martin Holmgren Check out the latest in z.com programming, produced exclusively for the net! http://www.z.com