Craig,
One last thing, when you said:
because the address has to be relative to wherever the
browser submitted the form, not to the page itself
using an "absolute-path" type of relative URI should be equivalent to an
absolute URL in solving this problem.
-- Stoehr
-Original Message-
From: Sukachevin, Stoehr
Sent: Thursday, April 12, 2001 02:18 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Use of RequestUtils.absoluteURL() in LinkTag [and
RedirectTag ]
Craig McClanahan wrote:
* For the link tag, the logic is faced with having a context-relative
path (retrieved from struts-config.xml) that it needs to return to
the browser. Browsers have no clue how to understand context-relative
references, so we've only got two choices: (a) translate it to
absolute, or (b) try to figure out a valid relative path to the new
destination. The latter is harder than it looks in the Struts
environment, because the address has to be relative to wherever the
browser submitted the form, not to the page itself.
I'm not sure if I see (b) as being "harder than it looks in the Struts
environment" because the URI spec (RFC 2396) supports the notion of an
"absolute-path" type of relative URI. So if a link on a web page called
'Page X' was simply "/struts/index.html" (notice the beginning "/") so it
was not a fully qualified URL, then a browser would translate that to
"http://jakarta.apache.org/struts/index.html" when followed (clicked-on) if
the URL of 'Page X' had the "http" schema and "jakarta.apache.org" as the
server (and port of 80).
I guess what I'm saying is that if doing (a) via RequestUtils.absoluteURL()
effectively returns "http://jakarta.apache.org/struts/index.html" (because,
say, the web context path was "/struts" and the LinkTag's path attribute was
"/index.html"), that should be equivalent to just returning
"/struts/index.html". The code in RequestUtils.absoluteURL() already has
"request.getContextPath() + path" that would effectively be
"/struts/index.html" in this example.
Note that even if 'Page X' was redirected-to by a different web server than
"jakarta.apache.org", the browser would still correctly understand that
"jakarta.apache.org" is the server that "/struts/index.html" refers to
(because it was the browser that did the GET for 'Page X' after the
redirection HTTP response from the different web server).
So if choice (b) really is not that hard, should these types of custom
Struts tags be changed so that they do not make links absolute so
deployments of Struts applications that use things like SSL accelerators
work?
-- Stoehr
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 12, 2001 12:28 PM
To: '[EMAIL PROTECTED]'
Cc: Sukachevin, Stoehr
Subject: Re: Use of RequestUtils.absoluteURL() in LinkTag [and
RedirectTag]
On Thu, 12 Apr 2001, Sukachevin, Stoehr wrote:
Is it really necessary to have the LinkTag [and RedirectTag] use the
RequestUtils.absoluteURL() method when the "forward" or "page" attribute
is
specified?
There are a couple of issues here:
* For the link tag, the logic is faced with having a context-relative
path (retrieved from struts-config.xml) that it needs to return to
the browser. Browsers have no clue how to understand context-relative
references, so we've only got two choices: (a) translate it to
absolute, or (b) try to figure out a valid relative path to the new
destination. The latter is harder than it looks in the Struts
environment, because the address has to be relative to wherever the
browser submitted the form, not to the page itself.
* For the redirect tag, even if the tag doesn't convert the URL to
absolute, the servlet engine is supposed to -- this is required by
the servlet specification.
Craig McClanahan
