Just today, I found the “amusing” fact that Tomcat server developers have taken it upon themselves to delete support for the HTTP Status Reason.
Think “200 OK” or “404 Not Found”. Even for applications sending a reason & clients expecting it, Tomcat is coded to explicitly drop the value — sending just a bald 200 or 404.
Unsurprisingly for those with the slightest knowledge of protocol compatibility, this is now breaking clients in the wild.
I stumbled across this while prototyping a REST HTTP proxy behavior. The correct starting point for a proxy would be, obviously, to answer all data (headers, status, content) as it was received.
However, Tomcat mysteriously didn’t seem to want to do that — discarding the Status Reason instead. When I dug into this, I found that support for this long-standing HTTP/1.x feature had just been deleted.
What??
As far as I can see, Tomcat developers feel that:
- “because HTTP/2 will not support Reason”,
- “Reason is optional in HTTP/1.x and primarily intended for human use”, and
- “smart developer knows HTTP status codes already & doesn’t need explanatory text”
They can just delete support for it.
From my perspective of protocol compatibility and systems integration, I think this is quite astoundingly wrong. My perspective would be, that so long as HTTP/1.x is supported, all features of HTTP/1.x (whether somebody else thinks a client “should” use these features or not) should be supported.
Sadly, a whole bunch of system integrators (embedded systems, WebDAV clients, other software) are now reporting that Tomcat upgrades have broken their systems. Many of which are embedded, with firmware which is not possible to upgrade.
My belief would be that it should only be the overall system owner’s decision — encompassing the client & server applications, as well as Tomcat — who makes the decision that they do or don’t need Status Reason.
Tomcat developers are not responsible for these overall systems and, from my perspective, should not be making decisions to delete commonly-expected features of protocols they claim to support which break what they are not responsible for.
However, that seems to be their approach. It’s really just a bit sad. And not the first time they’ve made strange design decisions either.
- https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
- https://markmail.org/message/pqzvca26hihiysiu
- https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
For a last bit of humour, I refer you to RFC-7807 ‘Problem Details’ specification — which the Tomcat devs suggest is intended to replace Status Reasons. All the examples of which include a Status Reason.