Re: RequestDispatcher.forward()-Problem with anchors
thank you, Rob! (thank you, Michael) ... it sounds consistent. once more again to secure, i understand it correct: a forward in opposition to a redirect is some server-internal operation, whose result is send back to the browser. as the browser itself don't realize it, the anchor at the url has not the desired effect. ok. that a redirection with a anchor-url operates, is clear. is there a trick to anyhow get some related behavior with forward to work? or is this not necessary, because i can access the original session object at the second page in the case of a redirect as well? (i think this was my error in reasoning, that i have to use a forward when using sessions) thank you again, bAs T. Rob Tanner schrieb: When you do a RequestDispatcher.forward(), that's an internal operation, and not a redirect send back to the browser. In the latter case, the browser initiates a new GET request to the new URL. In the former case, the page at the RequestDispatcher.forward() address is simply sent to the browser without the browser being any the wiser. In that sense, it's the same kind of thing as an internal redirect in Apache. Whether the address "example.jsp#position1" is a good URL or a bad URL or whether it's a tomcat bug or a serverlet 2.2 spec bug that an exception wasn't thrown is something I don't know. But going back to my first point, since the browser is unaware of the forward anyway, anchors won't work. Do a redirect to the browser instead. -- Rob --On Monday, March 05, 2001 10:09:24 AM -0800 Filip Hanik [EMAIL PROTECTED] wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: RequestDispatcher.forward()-Problem with anchors
Hi Sebastian, Sebastian Schulz wrote: is there a trick to anyhow get some related behavior with forward to work? or is this not necessary, because i can access the original session object at the second page in the case of a redirect as well? I think so. If you want to send an error, store it in the session and check it in the receiving servlet. Un saludo, Alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RequestDispatcher.forward()-Problem with anchors
hi, i have a problem with RequestDispatcher.forward(): if the url contains an anchor like "example.jsp#position1" then forwarding seams to be be all right (no error, exception ...), but the 'new' page has no content. i tried to forward to a url with parameters like "example.jsp?name=value", this is no problem and the page is shown correctly? whats my mistake? is it possible to forward a anchor-containing url at all? any suggestions desired! thank you all in advance, bas T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: RequestDispatcher.forward()-Problem with anchors
I thought the anchor tag was something that was interpreted by the browser, not the server. doesn't the server just ignore those? correct me if I am wrong! Filip -Original Message- From: Sebastian Schulz [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 9:48 AM To: [EMAIL PROTECTED] Subject: RequestDispatcher.forward()-Problem with anchors hi, i have a problem with RequestDispatcher.forward(): if the url contains an anchor like "example.jsp#position1" then forwarding seams to be be all right (no error, exception ...), but the 'new' page has no content. i tried to forward to a url with parameters like "example.jsp?name=value", this is no problem and the page is shown correctly? whats my mistake? is it possible to forward a anchor-containing url at all? any suggestions desired! thank you all in advance, bas T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: RequestDispatcher.forward()-Problem with anchors
When you do a RequestDispatcher.forward(), that's an internal operation, and not a redirect send back to the browser. In the latter case, the browser initiates a new GET request to the new URL. In the former case, the page at the RequestDispatcher.forward() address is simply sent to the browser without the browser being any the wiser. In that sense, it's the same kind of thing as an internal redirect in Apache. Whether the address "example.jsp#position1" is a good URL or a bad URL or whether it's a tomcat bug or a serverlet 2.2 spec bug that an exception wasn't thrown is something I don't know. But going back to my first point, since the browser is unaware of the forward anyway, anchors won't work. Do a redirect to the browser instead. -- Rob --On Monday, March 05, 2001 10:09:24 AM -0800 Filip Hanik [EMAIL PROTECTED] wrote: I thought the anchor tag was something that was interpreted by the browser, not the server. doesn't the server just ignore those? correct me if I am wrong! Filip -Original Message- From: Sebastian Schulz [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 9:48 AM To: [EMAIL PROTECTED] Subject: RequestDispatcher.forward()-Problem with anchors hi, i have a problem with RequestDispatcher.forward(): if the url contains an anchor like "example.jsp#position1" then forwarding seams to be be all right (no error, exception ...), but the 'new' page has no content. i tried to forward to a url with parameters like "example.jsp?name=value", this is no problem and the page is shown correctly? whats my mistake? is it possible to forward a anchor-containing url at all? any suggestions desired! thank you all in advance, bas T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] _ _ _ _ __ _ _ _ _ /\_\_\_\_\/\_\ /\_\_\_\_\_\ /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT, /\/_/__\/_/ __/\/_//\/_/ PROFUNDUM VIDITUR /\/_/_/_/_/ /\_\ /\/_//\/_/ /\/_/ \/_/ /\/_/_/\/_//\/_/ (Whatever is said in Latin \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound) Rob Tanner McMinnville, Oregon [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]