Re: Forwards, Absolute URIs and Leading Slash [LONG]

2002-11-19 Thread Ted Husted
In 1.0, the way we do that is to use an Action that returned an 
ActionForward with redirect=true. In 1.1, we can elevate that 
approach to a standard RedirectAction -- at least, once I fix the 
bug in * that prepends a slash to everything whether redirect is 
set to true or not =:0)

I took a walk down CVS lane and found that the auto-prepend 
behavior was introduced in revision 1.45. Apparently it was added 
for the benefit of Tiles, but Cedric later made changes to Tiles 
so that this isn't necessary anymore.

Revision 1.45 / (view) - annotate - [select for diffs] , Sun Jul 7 
23:45:21 2002 UTC (4 months, 1 week ago) by craigmcc
Branch: MAIN
Changes since 1.44: +18 -7 lines
Diff to previous 1.44 (colored)

Deal with a "path" attribute on a  that does not contain 
a leading slash by inserting one if necessary, for backwards 
compatibility.

PR: Bugzilla #10534
Submitted by:   Matt Raible 

11/18/2002 10:30:36 AM, David Graham <[EMAIL PROTECTED]> 
wrote:

>Thanks for the explanation Ted.  What if I want to redirect to 
another 
>server from an Action?  I need to return an ActionForward with 
>redirect=true.  Will your solution handle absolute uris in that 
way?
>
>Dave




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: Forwards, Absolute URIs and Leading Slash [LONG]

2002-11-18 Thread James Mitchell
Not sure about anyone else's requirements, but I've can think of one.

Customer needs to see shipment tracking information/status.
Marketing wants to know who is actually using the 'display tracking info'
page.

So, when user clicks the 'Display Tracking Information', new window (of
configurable dimensions) opens and calls an action (/showTracking.do) that
should log some info (username, date, time, shipment release, etc) and
redirect to the assigned carrier's web tracking internet site (e.g. UPS,
Consolidated Freight, Company's Distribution Center, etc)


James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org

"If you were plowing a field, which would you rather use? Two strong oxen or
1024 chickens?"
- Seymour Cray (1925-1996), father of supercomputing


> -Original Message-
> From: edgar [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 18, 2002 11:28 AM
> To: 'Struts Developers List'
> Subject: RE: Forwards, Absolute URIs and Leading Slash [LONG]
>
>
> Perhaps I am missing something as there has been a great deal of
> discussion about allowing an action to forward outside of the container
> from an action in struts-config.xml.
>
> My question is what business issue are you attempting to solve when this
> is so easily handled in the html/jsp itself.  The only one I can imagine
> is where you are triing to overlay a single struts application over
> multiple physical servers.  If so isn't this better left to other
> external methods of combining servers.
>
> Anyway that is my $.02.
>
> Edgar
>
>
> -Original Message-----
> From: David Graham [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 18, 2002 10:31 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Forwards, Absolute URIs and Leading Slash [LONG]
>
>
> Thanks for the explanation Ted.  What if I want to redirect to another
> server from an Action?  I need to return an ActionForward with
> redirect=true.  Will your solution handle absolute uris in that way?
>
> Dave
>
>
>
>
>
>
> >From: Ted Husted <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: Struts Developers List <[EMAIL PROTECTED]>
> >Subject: Re: Forwards, Absolute URIs and Leading Slash [LONG]
> >Date: Mon, 18 Nov 2002 08:13:05 -0500
> >
> >11/16/2002 9:19:51 PM, David Graham <[EMAIL PROTECTED]>
> >wrote:
> > >I was trying to fix
> >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11021
> > >but got rather confused along the way.  The problem seems to be
> >that
> > >RequestUtils.forwardURL() always prepends the context path even
> >for absolute
> > >urls.  The version comments seem to go back and forth on how to
> >behave with
> > >a leading / in the url.  Sometimes no leading / means don't
> >prepend the
> > >context, then that decision was reversed.
> > >
> > >Maybe I'm not the right person to fix this but we need to decide
> >how to
> > >determine if the user has entered an absolute url like
> > >http://www.google.com.
> >
> >
> >
> >OK, let's start with the 1.0 behavior.
> >
> >There are two ways to indicate a path, an ActionMapping.forward and an
> >ActionForward.
> >
> >In the case of an ActionMapping.forward, we did this
> >
> >* Get String (path) stored as the ActionMapping forward property.
> >* Give it to the RequestDispatcher.
> >
> >which boils down to
> >
> >String forward = ActionMapping.getForward();
> >// ... error checking
> >RequestDispatcher rd =
> >   getServletContext().getRequestDispatcher(forward);
> >// ... error checking
> >rd.forward(request, response);
> >
> >rd.forward allows you to forwards a request from a servlet to another
> >resource (servlet, JSP file, or HTML file) on the server. Since we
> >obtained it via getRequestDispatcher(), the ServletRequest object has
> >its path elements and parameters adjusted to match the path of the
> >target resource. So, all the references here will *always* be context
> >relative without our having to munge the path in any way.
> >
> >Also, this method does *not* support absolute URL with a schema
> >attached. It's meant to forward to another resource on the same server,
>
> >and since we were using getServletContext, to a resource in the same
> >application.
> >
> >In the case of an ActionForward, in 1.0 we handle it like this:
> >
> >* Retrieve the ActionForward bean
> >* get the path property
> >* if the ActionForwar

RE: Forwards, Absolute URIs and Leading Slash [LONG]

2002-11-18 Thread edgar
Perhaps I am missing something as there has been a great deal of
discussion about allowing an action to forward outside of the container
from an action in struts-config.xml.

My question is what business issue are you attempting to solve when this
is so easily handled in the html/jsp itself.  The only one I can imagine
is where you are triing to overlay a single struts application over
multiple physical servers.  If so isn't this better left to other
external methods of combining servers.

Anyway that is my $.02.

Edgar  


-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]] 
Sent: Monday, November 18, 2002 10:31 AM
To: [EMAIL PROTECTED]
Subject: Re: Forwards, Absolute URIs and Leading Slash [LONG]


Thanks for the explanation Ted.  What if I want to redirect to another 
server from an Action?  I need to return an ActionForward with 
redirect=true.  Will your solution handle absolute uris in that way?

Dave






>From: Ted Husted <[EMAIL PROTECTED]>
>Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
>To: Struts Developers List <[EMAIL PROTECTED]>
>Subject: Re: Forwards, Absolute URIs and Leading Slash [LONG]
>Date: Mon, 18 Nov 2002 08:13:05 -0500
>
>11/16/2002 9:19:51 PM, David Graham <[EMAIL PROTECTED]>
>wrote:
> >I was trying to fix
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11021
> >but got rather confused along the way.  The problem seems to be
>that
> >RequestUtils.forwardURL() always prepends the context path even
>for absolute
> >urls.  The version comments seem to go back and forth on how to
>behave with
> >a leading / in the url.  Sometimes no leading / means don't
>prepend the
> >context, then that decision was reversed.
> >
> >Maybe I'm not the right person to fix this but we need to decide
>how to
> >determine if the user has entered an absolute url like 
> >http://www.google.com.
>
>
>
>OK, let's start with the 1.0 behavior.
>
>There are two ways to indicate a path, an ActionMapping.forward and an 
>ActionForward.
>
>In the case of an ActionMapping.forward, we did this
>
>* Get String (path) stored as the ActionMapping forward property.
>* Give it to the RequestDispatcher.
>
>which boils down to
>
>String forward = ActionMapping.getForward();
>// ... error checking
>RequestDispatcher rd =
>   getServletContext().getRequestDispatcher(forward);
>// ... error checking
>rd.forward(request, response);
>
>rd.forward allows you to forwards a request from a servlet to another 
>resource (servlet, JSP file, or HTML file) on the server. Since we 
>obtained it via getRequestDispatcher(), the ServletRequest object has 
>its path elements and parameters adjusted to match the path of the 
>target resource. So, all the references here will *always* be context 
>relative without our having to munge the path in any way.
>
>Also, this method does *not* support absolute URL with a schema 
>attached. It's meant to forward to another resource on the same server,

>and since we were using getServletContext, to a resource in the same 
>application.
>
>In the case of an ActionForward, in 1.0 we handle it like this:
>
>* Retrieve the ActionForward bean
>* get the path property
>* if the ActionForward.redirect property is true and the path starts 
>with a slash, then we insert the context path before redirecting. If 
>the path does not start with a slash (e.g, it has a schema), we leave 
>it alone.
>* if ActionForward.redirect is false (the default), we handle it like 
>the ActionMapping.forward (getServletContext.getRequestDispatcher).
>
>   if (forward != null) {
>   String path = forward.getPath();
>   if (forward.getRedirect()) {
>   if (path.startsWith("/"))
> path = request.getContextPath() + path;
>   response.sendRedirect(response.encodeRedirectURL
>(path));
>   } else {
>   RequestDispatcher rd =
>   getServletContext().getRequestDispatcher(path);
> if (rd == null) {
> response.sendError 
>(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
>internal.getMessage 
>("requestDispatcher",
>path));
> return;
> }
>   rd.forward(request, response);
>   }
>
>So, to get to another server, we had to set redirect=true and use an 
>ActionForward.
>
>A third way to indicate a path was via the standard ForwardAction. In 
>1.0, the behavior of the ForwardAction and IncludeAction mimicks the 
>ActionMapping.forward and 

Re: Forwards, Absolute URIs and Leading Slash [LONG]

2002-11-18 Thread David Graham
Thanks for the explanation Ted.  What if I want to redirect to another 
server from an Action?  I need to return an ActionForward with 
redirect=true.  Will your solution handle absolute uris in that way?

Dave






From: Ted Husted <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: Forwards, Absolute URIs and Leading Slash [LONG]
Date: Mon, 18 Nov 2002 08:13:05 -0500

11/16/2002 9:19:51 PM, David Graham <[EMAIL PROTECTED]>
wrote:
>I was trying to fix
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11021
>but got rather confused along the way.  The problem seems to be
that
>RequestUtils.forwardURL() always prepends the context path even
for absolute
>urls.  The version comments seem to go back and forth on how to
behave with
>a leading / in the url.  Sometimes no leading / means don't
prepend the
>context, then that decision was reversed.
>
>Maybe I'm not the right person to fix this but we need to decide
how to
>determine if the user has entered an absolute url like
>http://www.google.com.



OK, let's start with the 1.0 behavior.

There are two ways to indicate a path, an ActionMapping.forward
and an ActionForward.

In the case of an ActionMapping.forward, we did this

* Get String (path) stored as the ActionMapping forward property.
* Give it to the RequestDispatcher.

which boils down to

String forward = ActionMapping.getForward();
// ... error checking
RequestDispatcher rd =
  getServletContext().getRequestDispatcher(forward);
// ... error checking
rd.forward(request, response);

rd.forward allows you to forwards a request from a servlet to
another resource (servlet, JSP file, or HTML file) on the server.
Since we obtained it via getRequestDispatcher(), the
ServletRequest object has its path elements and parameters
adjusted to match the path of the target resource. So, all the
references here will *always* be context relative without our
having to munge the path in any way.

Also, this method does *not* support absolute URL with a schema
attached. It's meant to forward to another resource on the same
server, and since we were using getServletContext, to a resource
in the same application.

In the case of an ActionForward, in 1.0 we handle it like this:

* Retrieve the ActionForward bean
* get the path property
* if the ActionForward.redirect property is true and the path
starts with a slash, then we insert the context path before
redirecting. If the path does not start with a slash (e.g, it has
a schema), we leave it alone.
* if ActionForward.redirect is false (the default), we handle it
like the ActionMapping.forward
(getServletContext.getRequestDispatcher).

	if (forward != null) {
	String path = forward.getPath();
	if (forward.getRedirect()) {
	if (path.startsWith("/"))
path = request.getContextPath() + path;
		response.sendRedirect(response.encodeRedirectURL
(path));
	} else {
		RequestDispatcher rd =
		getServletContext().getRequestDispatcher(path);
if (rd == null) {
response.sendError
(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
   internal.getMessage
("requestDispatcher",
   path));
return;
}
		rd.forward(request, response);
	}

So, to get to another server, we had to set redirect=true and use
an ActionForward.

A third way to indicate a path was via the standard ForwardAction.
In 1.0, the behavior of the ForwardAction and IncludeAction
mimicks the ActionMapping.forward and ActionMapping.include with
any apparent value add. I don't remember why we did this. My guess
is that we did the Actions first and then extended the
ActionMappings, leaving the Actions behind for backward
compatability.

So, in 1.0, the only place we needed to munge a path was when

* We used an ActionForward (rather than ActionMapping.forward)
* Redirect was true
* The path started with a slash

We only munge it here because we are going through the
response.sendRedirect. Response.sendDirect doesn't know anything
about the ServletContext, and so we provide this bit ourselves. In
all other cases, RequestDispatcher does all the dirty work fr us.

In 1.1, we munge paths more often, since we need to inject the
module component. There are also times when we should not inject
the module component, so we added the contextRelative property to
the ActionForward.

When contextRelative is false (the default), we are implying that
the path is instead module relative.

In the case of a 1.1 ActionMapping.forward, we do this

* Get String (path) stored as the ActionMapping forward property.
* Inject the module prefix (which may be blank).
* Give it to the RequestDispatcher.

So, conceptually, this appears to be same behavior as

Re: Forwards, Absolute URIs and Leading Slash [LONG]

2002-11-18 Thread Ted Husted
11/16/2002 9:19:51 PM, David Graham <[EMAIL PROTECTED]> 
wrote:
>I was trying to fix 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11021 
>but got rather confused along the way.  The problem seems to be 
that 
>RequestUtils.forwardURL() always prepends the context path even 
for absolute 
>urls.  The version comments seem to go back and forth on how to 
behave with 
>a leading / in the url.  Sometimes no leading / means don't 
prepend the 
>context, then that decision was reversed.
>
>Maybe I'm not the right person to fix this but we need to decide 
how to 
>determine if the user has entered an absolute url like 
>http://www.google.com.



OK, let's start with the 1.0 behavior. 

There are two ways to indicate a path, an ActionMapping.forward 
and an ActionForward. 

In the case of an ActionMapping.forward, we did this 

* Get String (path) stored as the ActionMapping forward property. 
* Give it to the RequestDispatcher.

which boils down to 

String forward = ActionMapping.getForward();
// ... error checking
RequestDispatcher rd =
  getServletContext().getRequestDispatcher(forward);
// ... error checking
rd.forward(request, response);

rd.forward allows you to forwards a request from a servlet to 
another resource (servlet, JSP file, or HTML file) on the server. 
Since we obtained it via getRequestDispatcher(), the 
ServletRequest object has its path elements and parameters 
adjusted to match the path of the target resource. So, all the 
references here will *always* be context relative without our 
having to munge the path in any way.

Also, this method does *not* support absolute URL with a schema 
attached. It's meant to forward to another resource on the same 
server, and since we were using getServletContext, to a resource 
in the same application. 

In the case of an ActionForward, in 1.0 we handle it like this:

* Retrieve the ActionForward bean
* get the path property
* if the ActionForward.redirect property is true and the path 
starts with a slash, then we insert the context path before 
redirecting. If the path does not start with a slash (e.g, it has 
a schema), we leave it alone.
* if ActionForward.redirect is false (the default), we handle it 
like the ActionMapping.forward 
(getServletContext.getRequestDispatcher). 

if (forward != null) {
String path = forward.getPath();
if (forward.getRedirect()) {
if (path.startsWith("/"))
path = request.getContextPath() + path;
response.sendRedirect(response.encodeRedirectURL
(path));
} else {
RequestDispatcher rd =
getServletContext().getRequestDispatcher(path);
if (rd == null) {
response.sendError
(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
   internal.getMessage
("requestDispatcher",
   path));
return;
}
rd.forward(request, response);
}

So, to get to another server, we had to set redirect=true and use 
an ActionForward. 

A third way to indicate a path was via the standard ForwardAction. 
In 1.0, the behavior of the ForwardAction and IncludeAction 
mimicks the ActionMapping.forward and ActionMapping.include with 
any apparent value add. I don't remember why we did this. My guess 
is that we did the Actions first and then extended the 
ActionMappings, leaving the Actions behind for backward 
compatability. 

So, in 1.0, the only place we needed to munge a path was when 

* We used an ActionForward (rather than ActionMapping.forward)
* Redirect was true
* The path started with a slash 

We only munge it here because we are going through the 
response.sendRedirect. Response.sendDirect doesn't know anything 
about the ServletContext, and so we provide this bit ourselves. In 
all other cases, RequestDispatcher does all the dirty work fr us. 

In 1.1, we munge paths more often, since we need to inject the 
module component. There are also times when we should not inject 
the module component, so we added the contextRelative property to 
the ActionForward.

When contextRelative is false (the default), we are implying that 
the path is instead module relative. 

In the case of a 1.1 ActionMapping.forward, we do this 

* Get String (path) stored as the ActionMapping forward property. 
* Inject the module prefix (which may be blank).
* Give it to the RequestDispatcher.

So, conceptually, this appears to be same behavior as 1.0. I can 
only ActionMapping.forward (or include) to another resource in the 
current application (or application module). 

In the case of an 1.1 ActionForward, we would want to

* if contextRelative is false, insert the module prefix 

and then

* if redirect is true and the path starts with a slash, insert the 
context path. 

Right now in RequestUtils.forwardURL, we're forcing a leading 
slash if context-rel