Bug 65921 - Null pointer exception if RewriteRule attempts to set mime type
Summary: Null pointer exception if RewriteRule attempts to set mime type
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 9.0.55
Hardware: PC All
: P2 normal (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-02-28 14:53 UTC by Richard Evans
Modified: 2022-03-01 16:51 UTC (History)
1 user (show)


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Evans 2022-02-28 14:53:24 UTC 
A rewrite rule like:

RewriteRule ^/path/.*$ - [T=text/xml]

fails with a NullPointerException because the contentTypeMB field in the Request object has not initialized.  Request.setContentType should initialize contentTypeMB, or the rewrite valve should call getContentType first.  The former is preferable in case there is no content type in the request.

This always happens with the HTTP/1.1 connector.  With the AJP connector the exeception occurs if the request does not contain a Content-Type header.

Backtrace:

	java.lang.NullPointerException: Cannot invoke "org.apache.tomcat.util.buf.MessageBytes.setString(String)" because "this.contentTypeMB" is null
		at org.apache.coyote.Request.setContentType(Request.java:465)
		at org.apache.catalina.connector.Request.setContentType(Request.java:1057)
		at org.apache.catalina.valves.rewrite.RewriteValve.invoke(RewriteValve.java:448)
		at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
		at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
		at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:359)
		at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:399)
		at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
		at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:889)
		at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1735)
		at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
		at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
		at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
		at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
		at java.base/java.lang.Thread.run(Thread.java:833)
Comment 1 Mark Thomas 2022-03-01 12:59:59 UTC 
This should be setting the content-type on the response rather than the request.
Comment 2 Mark Thomas 2022-03-01 13:07:23 UTC 
Fixed in:
- 10.1.x for 10.1.0-M12 onwards
- 10.0.x for 10.0.18 onwards
- 9.0.x for 9.0.60 onwards
- 8.5.x for 8.5.77 onwards
Comment 3 Richard Evans 2022-03-01 16:30:07 UTC 
The use case here was to fix up the content-type in a request before it reaches he application (the client code was sending the wrong type).

If this RewriteRule mechanism is in fact designed to set the response type, how can the request type be changed?  I can write a custom valve but the rewrite mechanism seemed better.
Comment 4 Mark Thomas 2022-03-01 16:51:02 UTC 
The portable way would be to use a Filter and wrap the HttpServletRequest.