Jersey response's reason phrase is inconsistent in tomcat 7 and 8.5

Question

I'm using Tomcat 8.5 in one server and Tomcat 7 in different server and I have the following jersey resource:

@Path("main")
public class MyResource {


@POST
@Path("path")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public PojoResponse sendMailTemplate(PojoRequest paramsMap) throws Exception {
    return service.execute(paramsMap);
}

Which is register to MyApplication (extends ResourceConfig) with @ApplicationPath("root")

When submitting request using JMeter/Postman (to /root/main/path) I'm getting inconsistent HTTP's Reason Phrase

The client is not required to examine or display the Reason- Phrase.

Which isn't mandatory for protocol

The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol.

I see a "valid" response of 200 OK from Tomcat 7 server:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json
Content-Length: 32

and an "invalid" response of 200 200 from Tomcat 7 server (same request) :

HTTP/1.1 200 200
Server: Apache
Content-Type: application/json
Content-Length: 32
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Connection: close
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

When I check Response I don't find any reference to updating reason phrase, So should this inconsistency be ignored or can it be fixed?

EDIT

My application also register JacksonFeature:

register(JacksonFeature.class);

EDIT 2

Actually I found that I have extra jar in second environment:

 jersey-entity-filtering-2.19

Common jars:

jersey-client-2.19.jar
jersey-common-2.19.jar
jersey-container-servlet-2.19.jar
jersey-container-servlet-core-2.19.jar
jersey-guava-2.19.jar
jersey-media-jaxb-2.19.jar
jersey-media-json-jackson-2.6.jar
jersey-server-2.19.jar
jersey-spring3-2.6.jar

EDIT 3

I found a bug in Tomcat 8.5 which saying reason phrase was removed

Christopher Schultz : I was surprised to see that Tomcat actively strips-out the reason phrase. I had initially thought this was simply Tomcat removing reason-phrases from every response generated by Tomcat (e.g. everything coming from the DefaultServlet, various internal errors, etc.), but it's actively stripping reason phrases explicitly-set by applications.

Michael Osipov: No, this does not send any reason phrase. Only the HTML error page. I know, because I have rewritten the ErrorReportValve the last time.

EDIT 4

I found relevant question but I didn't fully understand it

Tomcat 8.5 removed the "HTTP status reason phrase" from the response, so you'll get HTTP 200 instead of HTTP 200 OK in the response. It's possible that your observations are from software that duplicates the status code into the status reason phrase for display.

How are you observing the status code? You may find that if you do a protocol trace, you'll see that there is only a single status code being sent by Tomcat / httpd. Are you sure the "double status code" isn't actually a (normal) status code and a reason phrase that happens to be the same text as the status code?

Answer 1

I just answered a similar question (52821653) two days ago.

In short: the current version of HTTP protocol (HTTP/2) has removed support for the reason phrase.

This feature is gone. Do not rely on it.

UPDATE:

Looking at

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1

and

HTTP/1.1 200 200
Server: Apache

The HTTP connector of current versions of Tomcat 8.5 by default will respond with HTTP/1.1 200 (with no reason phrase). See org.apache.coyote.http11.Http11OutputBuffer.

The AJP connector of current versions of Tomcat 8.5 by default will respond with HTTP/1.1 200 200 (using the status code as the reason phrase), because of limitations of some HTTP servers. See org.apache.coyote.ajp.AjpProcessor.

Both responses are valid ones.

Generating the "OK" string can be enabled in Tomcat 8.5 by setting sendReasonPhrase="true" on a Connector. This option is deprecated.

Answer 2

I think the answer you are looking for may be found in RFC 2616, section 6.

The relevant excerpt:

The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase.

The main take-away is that the reason-phrase should not be relied on in your client code. However, you can and should rely on the Status-Code.

If you wish to convey additional human readable context in your HTTP responses, it is common practice, to place this in a 'custom' response header (e.g. "X-MyApp-Message"). Note that custom headers should begin with 'X-'.

Answer 3

The problem was using Apache Server 2.4.6 which has a bug, One of Changes of Apache 2.4.7 is fixing reason phrase to be returned:

core: Add missing Reason-Phrase in HTTP response headers. PR 54946. [Rainer Jung]

The relevant bug states it's a breaking change:

we would get a http status-line pulled from a standard table like:

HTTP/1.1<sp>200<sp>OK

Now, in Apache 2.2.24 we are getting:

HTTP/1.1<sp>200<sp>

We tracked this down into a change made for apache bug 44995 that caused this new behavior. The bug was a fix to handle custom status codes, but it also ended up breaking standard codes such that it no longer returned standard reason-phrase enhanced responses.

I realize that the RFC2616 specification allows for the HTTP/1.1200 response, but our client is not changeable and crashes on receiving no reason-phrase.