4

We have a legacy client consuming a servlet deployed on tomcat 8.5. This legacy client is waiting for the content-type header response in this format (note the whitespace between the semicolon and 'charset'):

Content-type: text/xml; charset=utf-8

However, in the server side, Tomcat is always trimming this whitespace, althought we force it in the servlet:

response.setContentType("text/xml; charset=utf-8");

Or even in a filter with a custom extension of HttpServletResponseWrapper, as suggested in this question.

Whatever I try, the content-type header is always returned without the whitespace.

Content-type: text/xml;charset=utf-8

As a reference, I found this in the tomcat official documentation:

Tomcat removes blank chars between the ';' and the 'charset' keyword

I know the http standard says that the whitespace is optional after the semicolon, as mentioned in this other SO post but as the client with the problem runs a legacy version, I'm wondering if there is any way to force tomcat to keep this whitespace.

I'm thinking about other choices such as modifying the content-type header in apache or nginx (above tomcat), but if it's possible I would prefer a solution at tomcat level.

Any help would be appreciated.

LeoLozes
  • 1,238
  • 1
  • 15
  • 26
troig
  • 6,257
  • 4
  • 35
  • 60
  • 2
    It looks like the [source code for this part of tomcat](https://github.com/apache/tomcat/blob/8f85c08925bc3dc39210f24b484aab30b4ed2b93/java/org/apache/coyote/Response.java#L548) indicates there's not an option to disable it – Zachary Craig Mar 21 '18 at 16:30
  • Hi @zack6849! Thanks for the comment. I see it, but as both getter and setter methods for contentType are publics, I'm wondering if there is any kind of workaround to override them or something like that. Thanks anyway. – troig Mar 21 '18 at 17:33
  • If your legacy client allowed special characters such as quotes, you could break the hard-coded trim, but from what you say your client doesn't allow that. RFC 2616 says LWS in header values can be replaced by one SPACE, it doesn't say that SPACE in header values may be removed. The legacy client is only half guilty. – Eugène Adell Mar 21 '18 at 20:21
  • Thanks @EugèneAdell. What do you mean when you say "break the hard-coded trim"? To be honest, I'm not sure if the legacy client allows quotes or not, so maybe I should give it a try to your suggestion – troig Mar 21 '18 at 21:01
  • 1
    @zack6849 showed Tomcat's code where the trim function removes this space that you need. I upvoted his comment for that. If instead of SPACE_charset=.. you had "SPACE_charset=..." or 'SPACE_charset=...' the trim function would do nothing because the value would not be starting by spaces anymore. – Eugène Adell Mar 21 '18 at 21:21

1 Answers1

1

As is posted in the comments, this is something that we cannot avoid as it's hardcoded in the tomcat source code

In our particular use case, we finally have been able to change a little bit the legacy-client, so now it can process the content type header in the standard format (without space).

Thanks @zack6849 por pointing that.

troig
  • 6,257
  • 4
  • 35
  • 60