Summary: | sendRedirect does not support protocol relative URLs | ||
---|---|---|---|
Product: | Tomcat 7 | Reporter: | Heikki Vesalainen <heikki.vesalainen> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 7.0.22 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All |
Description
Heikki Vesalainen
2011-10-05 21:31:50 UTC
The JavaDoc for sendRedirect requires that anything that starts with '/' is treated as server relative. I'm not sure if that is what was intended but it is certainly what the spec currently requires. I don't see any reason not to allow protocol relative URLs. I'll see if I can get some clarification from the Servlet EG. Discussion on this topic within the Servlet EG can be followed here: http://java.net/jira/browse/SERVLET_SPEC-27 Given that I am in favour of supporting protocol relative URLs, I will look at adding this support to Tomcat 7 ready for the next release. I would also suggest using the java.net.URI to resolve things in place of any home-brewn code. private String toAbsolute(String href) { URI base = URI.create(requestURI); // original request URI, including protocol return base.resolve(URI.create(href)).toASCIIString(); } And not just in this case, but all over tomcat where URIs are handled. The home-brew code is used for a good reason - performance. It is currently ~2x faster than the alternative proposed. 100% difference sounds dramatic, but how many percent of the total response time is spent in this code? How bad would it make things if the slower (but more reliable) version was used? Is it like the home-brewn code is 0,1% of total time and the URI takes 0,2% of total time? That would sound trivial and not worth the optimization. The amount of time spend in the sendRedirect code is likely to be only a small proportion of the overall request time but there are lots of places where URIs are manipulated in the Tomcat codebase. Switching all of them to URI is very likely to impact performance. If you want to argue for this change then you'll need to present some hard numbers to the dev list (that cover both request processing time and GC) that show that there is no noticeable impact in making this change. This has been fixed in trunk and 7.0.x and will be included in 7.0.23 onwards. |