Is it OK that AbstractBuiltResponse effectively ignores provided reasonPhrase?

[jakubzytka]

Please bear with me if this was clarified gazillion times already...

Consider the following (minimized for brevity):

response = Response.status(500, "bulbulator ran out of water").build();

assertEquals("bulbul....", response.getStatusInfo().getReasonPhrase()); <-- fails; the reason phrase is "Internal Server Error" 

this is due to:

resteasy/resteasy-core/src/main/java/org/jboss/resteasy/specimpl/AbstractBuiltResponse.java

Lines 132 to 160 in 1cca43b

	@Override
	public StatusType getStatusInfo()
	{
	StatusType statusType = Status.fromStatusCode(status);
	if (statusType == null)
	{
	statusType = new StatusType()
	{
	@Override
	public int getStatusCode()
	{
	return status;
	}
	@Override
	public Status.Family getFamily()
	{
	return Status.Family.familyOf(status);
	}
	@Override
	public String getReasonPhrase()
	{
	return reason;
	}
	};
	}
	return statusType;
	}

I.e. the provided reasonPhrase is ignored when a status code is defined as a "commonly used" one by javax.ws.rs.core.Response.Status.

Is it OK? It is surprising and the code itself looks like conflicting decisions had been made:

• on one hand, the API supports providing a reason phrase
• on the other, AbstractBuiltResponse is happy to ignore it
• there is a public String AbstractBuiltResponse::getReasonPhrase() method, but the reason phrase is really a property of the status info (StatusType)
• finally, AbstractBuiltResponse ignores the reason phrase when a Status with the same status code is defined in an enum Status. This enum looks more like an entity for convenience (it's a non-exhaustive list of common statuses), and which, potentially, can be extended at any time, breaking backward compatibility (reason phrase disappears for some newly added enum value)

[jamezp]

This seems a bit odd to me as well. It looks like it was introduced in RESTEASY-1991, #1835. @rsearls this was a while ago, but do you recall if there was a reason for this?

[jamezp]

Something like this seems more correct jamezp@7c59d68.