tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitry Gusev (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (TAP5-2074) Extra leading slashes in URLs in HTTP 404 error pages
Date Sat, 23 Feb 2013 19:12:12 GMT

     [ https://issues.apache.org/jira/browse/TAP5-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dmitry Gusev updated TAP5-2074:
-------------------------------

    Description: 
When implementing custom HTTP error page in Tapestry5 (like HTTP 404 error page described
here: http://tapestry.apache.org/error-page-recipe.html ), all client URLs contain extra leading
slashes, which makes those links invalid.

By client URLs I mean URLs generated by tapestry for t:pagelink and all the assets (js, css,
images, etc.).

I had this bug in Tapestry 5.3.6 application deployed at Tomcat 7.0.29 as the ROOT context.

The problem seems to be in HttpServletRequest.getContextPath() which returns "/" when request
has been handled by ERROR dispatcher.

Here's the javadoc of org.apache.tapestry5.services.Request.getContextPath():

/**
     * Returns the context path. This always starts with a "/" character and does not end
with one, with the exception
     * of servlets in the root context, which return the empty string.
     */
    String getContextPath();

Default implementation of Tapestry5's RequestImpl.getContextPath() is simply delegates contextPath
retrieval to servlet API:

    public String getContextPath()
    {
        return request.getContextPath();
    }

Not sure if this is Tomcat or Tapestry bug, but Tapestry should definitely handle this situation.

As a temporary workaround I had to implement MethodAdvice for Request.getContextPath() in
my AppModule like this:


    @Match("Request")
    public void adviseRequestContextPath(MethodAdviceReceiver receiver) throws SecurityException,
NoSuchMethodException
    {
        if (!receiver.getInterface().equals(Request.class))
        {
            return;
        }
        
        @SuppressWarnings("unchecked")
        Method method = receiver.getInterface().getDeclaredMethod("getContextPath");
        
        receiver.adviseMethod(method, new MethodAdvice()
        {
            @Override
            public void advise(MethodInvocation invocation)
            {
                MethodInvocation proceed = invocation.proceed();
                
                if ("/".equals(proceed.getReturnValue()))
                {
                    proceed.setReturnValue("");
                }
            }
        });
    }

  was:
When implementing custom HTTP error page in Tapestry5 (like HTTP 404 error page described
here: http://tapestry.apache.org/error-page-recipe.html), all client URLs contain extra leading
slashes, which makes those links invalid.

By client URLs I mean URLs generated by tapestry for t:pagelink and all the assets (js, css,
images, etc.).

I had this bug in Tapestry 5.3.6 application deployed at Tomcat 7.0.29 as the ROOT context.

The problem seems to be in HttpServletRequest.getContextPath() which returns "/" when request
has been handled by ERROR dispatcher.

Here's the javadoc of org.apache.tapestry5.services.Request.getContextPath():

/**
     * Returns the context path. This always starts with a "/" character and does not end
with one, with the exception
     * of servlets in the root context, which return the empty string.
     */
    String getContextPath();

Default implementation of Tapestry5's RequestImpl.getContextPath() is simply delegates contextPath
retrieval to servlet API:

    public String getContextPath()
    {
        return request.getContextPath();
    }

Not sure if this is Tomcat or Tapestry bug, but Tapestry should definitely handle this situation.

As a temporary workaround I had to implement MethodAdvice for Request.getContextPath() in
my AppModule like this:


    @Match("Request")
    public void adviseRequestContextPath(MethodAdviceReceiver receiver) throws SecurityException,
NoSuchMethodException
    {
        if (!receiver.getInterface().equals(Request.class))
        {
            return;
        }
        
        @SuppressWarnings("unchecked")
        Method method = receiver.getInterface().getDeclaredMethod("getContextPath");
        
        receiver.adviseMethod(method, new MethodAdvice()
        {
            @Override
            public void advise(MethodInvocation invocation)
            {
                MethodInvocation proceed = invocation.proceed();
                
                if ("/".equals(proceed.getReturnValue()))
                {
                    proceed.setReturnValue("");
                }
            }
        });
    }

    
> Extra leading slashes in URLs in HTTP 404 error pages
> -----------------------------------------------------
>
>                 Key: TAP5-2074
>                 URL: https://issues.apache.org/jira/browse/TAP5-2074
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.3.6
>            Reporter: Dmitry Gusev
>
> When implementing custom HTTP error page in Tapestry5 (like HTTP 404 error page described
here: http://tapestry.apache.org/error-page-recipe.html ), all client URLs contain extra leading
slashes, which makes those links invalid.
> By client URLs I mean URLs generated by tapestry for t:pagelink and all the assets (js,
css, images, etc.).
> I had this bug in Tapestry 5.3.6 application deployed at Tomcat 7.0.29 as the ROOT context.
> The problem seems to be in HttpServletRequest.getContextPath() which returns "/" when
request has been handled by ERROR dispatcher.
> Here's the javadoc of org.apache.tapestry5.services.Request.getContextPath():
> /**
>      * Returns the context path. This always starts with a "/" character and does not
end with one, with the exception
>      * of servlets in the root context, which return the empty string.
>      */
>     String getContextPath();
> Default implementation of Tapestry5's RequestImpl.getContextPath() is simply delegates
contextPath retrieval to servlet API:
>     public String getContextPath()
>     {
>         return request.getContextPath();
>     }
> Not sure if this is Tomcat or Tapestry bug, but Tapestry should definitely handle this
situation.
> As a temporary workaround I had to implement MethodAdvice for Request.getContextPath()
in my AppModule like this:
>     @Match("Request")
>     public void adviseRequestContextPath(MethodAdviceReceiver receiver) throws SecurityException,
NoSuchMethodException
>     {
>         if (!receiver.getInterface().equals(Request.class))
>         {
>             return;
>         }
>         
>         @SuppressWarnings("unchecked")
>         Method method = receiver.getInterface().getDeclaredMethod("getContextPath");
>         
>         receiver.adviseMethod(method, new MethodAdvice()
>         {
>             @Override
>             public void advise(MethodInvocation invocation)
>             {
>                 MethodInvocation proceed = invocation.proceed();
>                 
>                 if ("/".equals(proceed.getReturnValue()))
>                 {
>                     proceed.setReturnValue("");
>                 }
>             }
>         });
>     }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message