Fix Response#sendRedirect() if no request context exists.

[elkman]

If no ROOT context is defined, the context may be null in special cases, e.g. RewriteValve may use Response#sendRedirect() without any application context associated.
In this case, the Tomcat behaviors for the context attributes useRelativeRedirects and sendRedirectBody are assumed, but without considering org.apache.catalina.STRICT_SERVLET_COMPLIANCE.

[elkman]

Hi,

I stumbled across this issue while writing a "RewriteValve" rule that redirects everything based on an HTTP header condition.

This is happening in a development environment where no ROOT context is configured and no reverse proxy ensures that only valid path prefixes are passed to the Tomcat instances. So it is not a real production world problem, but the NPE made me skeptical.

I don't know if there is an easy way to access the actual configured default values from the context.xml and taking into account the STRICT_SERVLET_COMPLIANCE setting. This would be the preferred solution, but the case is also relatively unlikely in production setups and my primary goal is to avoid the NPE.

Cheers,
@elkman

[markt-asf]

This looks like invalid configuration at this point.

Generally, an NPE is preferable to a change that masks a configuration issue.

[elkman]

That is a good point. Do you think the misconfiguration is that a ROOT context should always be configured, or that rewrite rules should only be defined on existing contexts?

[markt-asf]

I can see valid use cases that wouldn't meet at least one of those criteria so I don't think it is quite that simple. Having a concrete use case to discuss might make things a little clearer. Can you provide an example that triggered the NPE (request URI, rewrite rule and any other relevant info)?

[elkman]

A valid UseCase for me would be: Migration of an application to a new context

https://host/myOldApp -> https://host/myNewApp

In this case you would forward both URL prefixes from the load balancer/proxy to the Tomcat and define a rewrite rule that redirects all requests to the old context to the new one.

RewriteRule ^/myOldApp/(.*)$ /myNewApp/legacy/$1 [R=301,L]

But since there exists no context for myOldApp, this would result in an NPE.

(And yes, of course the Tomcat terminates TLS in this case and not the load balancer, otherwise you would do the redirect there of course.)

I would prefer to handle such misconfiguration by the RewriteValve in a understandable way without debugging into Tomcat codebase. But I don't see any practical way for reliable detection by the RewriteValve. Neither when loading the rule configuration, nor at runtime (except to catch the NPE).
Instead of using default values, a specific exception could be generated. Then the error handling could be realized in the calling component, but this would violate the API.

[markt-asf]

Thanks for that example.
The right way to fix this will depend on the answer to the question "If a rewrite valve is configured at the Host level, is it a requirement that a context is present that matches the original request?" If yes, this is a documentation issue. If no, this is a Tomcat bug.
I'm currently leaning towards a "no" based on your use case. I can't really see a justification for requiring either a ROOT context or an myOldApp context.

[rmaucher]

It expands the capability of rewrite a bit, so "no" would be a good option.
Actually I was considering using rewrite for the context path optional feature (until you said this had to be done cleanly ;) ), and this is also the same use case.

[markt-asf]

Based on this discussion, the original fix is correct. I'll merge this shortly.

[elkman]

Thanks for the discussion, time and all your great work on the Tomcat project.