Re: Issue 55 in urlrewritefilter: Outbound rule triggers for response.encodeURL but not for c:url
codesite...@google.com
Comment #1 on issue 55 by ptomli: Outbound rule triggers for
response.encodeURL but not for c:url
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
Is it possible that this is the cause of the issues I'm seeing here:
http://stackoverflow.com/questions/1762453/rewrite-spring-security-redirect-urls
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
codesite...@google.com
Comment #2 on issue 55 by robin.sa...@gmx.net: Outbound rule triggers for
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
It seems not to be the same problem. I deactivated spring-security and the
problem
remains the same: response.encodeURL() is intercepted while c:url is not.
I don't know HOW the filter hooks into the URL encoding but with c:url the
filter
gets the path *with* the context-root so the rule does not match.
If this is the expected behaviour, maybe because JSTL works different than
response.encodeURL(), it should at least be mentioned in the documentation.
codesite...@google.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 55 by robin.sa...@gmx.net: Outbound rule triggers for
response.encodeURL but not for c:url
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
What steps will reproduce the problem?
1. Configure UrlRewriterFilter with one outbound rule
<outbound-rule match-type="wildcard">
<from>/static/pics/*</from>
<to>http://static.m2d.de:8080/$1</to>
</outbound-rule>
2. Create a JSP which encodes the same URL matching the outbound rule in
two different ways: first using response.encodeURL and then using c:url,
e.g.:
<a href='<%=response.encodeURL("/static/pics/testpic1")%>'>testlink1</a>
<a href='<c:url value="/static/pics/testpic2"/>'>testlink2</a>
3. The first URL triggers UrlRewriterFilter, the second doesn't.
Looking into the log file it seems that the 2nd case (c:url) does have the
context root of the web app include *before* the rewrite filter gets its
hands on it.
org.tuckey.web.filters.urlrewrite.RuleBase DEBUG: Outbound Rule 0 run
called with /static/pics/testpic1
...
INFO: org.tuckey.web.filters.urlrewrite.RuleBase DEBUG: Outbound Rule 0 run
called with /m2d/static/pics/testpic2
(m2d is the context-root of my web app)
What is the expected output? What do you see instead?
The first link is rewritten to 'http://static.m2d.de:8080/testpic1' the
second one isn't, I would expect both to behave the same like it is stated
in the documentation of UrlRewriterFilter.
(btw., using encodefirst="false" or true does not change this behaviour)
What version of the product are you using? On what operating system?
UrlRewriter 3.1 on Mac OS X 10.6.2, Tomcat 6.0.20, Java 6
Please provide any additional information below.
urlrewri...@googlecode.com
Comment #3 on issue 55 by iamake: Outbound rule triggers for
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
Hi Robin,
I just ran into the same problem and I just fixed it.
I don't really know your environment, but I would suggest the following.
1. Pick up your favorite Java IDE.
2. Set a breakpoint at c:url
3. See how it works... it will make use of UrlTag which the important part
is at the
org.apache.taglibs.standard.tag.common.core.UrlSupport method doEndTag().
The
response.encodeURL will be called iff ImportSupport.isAbsoluteUrl returns
false.
4. Check the return value from response.encodeURL to see if it return the
object
org.tuckey.web.filters.urlrewrite.UrlRewriteWrappedResponse.
Regards,
-Ake
urlrewri...@googlecode.com
Comment #4 on issue 55 by avlesh: Outbound rule triggers for
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
Does it work for you, robin?
urlrewri...@googlecode.com
Comment #5 on issue 55 by robin.sa...@gmx.net: Outbound rule triggers for
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
What do you mean? Opening my IDE and debug the code? Should I provide a
patch or why
should I do that?
The bug still exists if you mean that...
urlrewri...@googlecode.com
Status: WontFix
Comment #6 on issue 55 by avlesh: Outbound rule triggers for
response.encodeURL but not for c:url
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
Seems to be a problem with the usage of <c:url> taglib. There is absolutely
no issue
with the URF; it gets into action much beyond any JSTL tag. For people who
find this
as a "bug" might be doing something as silly as something reported here -
http://www.mail-archive.com/taglib...@jakarta.apache.org/msg09343.html
Marking this as won't fix.
urlrewri...@googlecode.com
Comment #7 on issue 55 by robin.sa...@gmx.net: Outbound rule triggers for
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
Then you should at least update your documentation, it wasn't my idea to
use the
filter with c:url, see http://tuckey.org/urlrewrite/manual/3.0/:
"Note, If you are using JSTL (ie, <c:url) this will work also."
And since so many sites are using JSTL I thought this would be a desired
feature...
A workaround may be to specify the outbound rule including the web app's
context root.
urlrewri...@googlecode.com
Comment #8 on issue 55 by sylvain.laurent: Outbound rule triggers for
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
I also think that the documentation should be fixed, including the "URL
abstraction" examples section : the
example outbound-rule works only if the context is the root context :-(
A nice improvement would be to add a optional boolean
attribute "prependedContext" to the <outbound-
rule> tag. its default value would false for backward compatibility.
Here would be an example (with the wild card engine):
<outbound-rule prependedContext="true">
<from>/servlet/**</from>
<to>/$1</to>
</outbound-rule>
If the application is deployed under the context "/context", URF would
automatically use /context/servlet/**
for the <from> expression instead of only /servlet/**
This way, applications that use <c:url value="/servlet/foo"> would work out
of the box, whatever the context
under which it is deployed, without changing the URF config.
urlrewri...@googlecode.com
Comment #9 on issue 55 by sylvain.laurent: Outbound rule triggers for
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
actually the prependedContext attribute should rather be on the <from> tag
and probably named "use-context"
since this attribute already exists on the <urlrewrite> tag. So, this would
be a way of enabling use-context on a
per <from> basis rather than for the whole <urlrewrite> config
urlrewri...@googlecode.com
Comment #10 on issue 55 by avlesh: Outbound rule triggers for
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
Why not have the <from> rule's in <outbound-rule> take care of the context.
I would
rather have this outbound rule for the use case above -
<outbound-rule>
<from>/context/some.html?foo=bar</from>
<to>/context/some/path</to>
</outbound-rule>
The documentation, i just noticed, should be fixed for this statement -
"... rules and conditions should not contain the context path"
AFAIK this is not true for outbound rules.
urlrewri...@googlecode.com
Comment #11 on issue 55 by robin.sa...@gmx.net: Outbound rule triggers for
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
@avlesh: The statement *is true* for outbound rules when you use
response.encodeURL()!
That's what this issue is all about! See my example at the top of this page:
A web app with context root 'm2d', outbould rule
<outbound-rule match-type="wildcard">
<from>/static/pics/*</from>
<to>http://static.m2d.de:8080/$1</to>
</outbound-rule>
respone.encodeURL() triggers, <c:url..> does not!
urlrewri...@googlecode.com
Comment #12 on issue 55 by sylvain.laurent: Outbound rule triggers for
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
@avslesh : it is possible to specify the /context in the <from>, but it's
not very neat because then the
expressions must be updated if the context changes...
@robin : it's not a question of using response.encodeURL() or not, it's the
way it is used :
In your own application, if you want to create a full path to a http
resource in java, you can do one the
following :
relativePath = "/some/path.html?msg=hello world";
fullPath1 = request.getContextPath() + response.encodeURL(relativePath);
fullPath2 = response.encodeURL(request.getContextPath() + relativePath);
<c:url> does the 2nd method, that's why your outbound rule does not match...
I think that this 2nd method is incorrect because the javadoc of
request.getContextPath() says "(...)The
container does not decode this string(...)". So, passing it in encodeURL()
would encode it twice and the value
would be incorrect. I suppose nobody cares because it's unlikely to use a
context with weird characters...
urlrewri...@googlecode.com
Comment #13 on issue 55 by nigel.sim: Outbound rule triggers for
http://code.google.com/p/urlrewritefilter/issues/detail?id=55
Perhaps URF should include a compatible tag library that can replace the
c:url tag?
That is the solution I've implemented overcome this issue.