https://bz.apache.org/bugzilla/show_bug.cgi?id=63867
--- Comment #3 from Mark Thomas <ma...@apache.org> --- First, some observations. By choosing a Spring Boot based solution on the server side (which implies regularly updating) and a client side that is essentially fixed, this design is making a number of assumptions: 1. That the protocol(s) supported on the client side will remain supported on on the server side for the life of the product. 2. That no protocol implementation issues requiring client side changes will be discovered on the client side for the life of the product. 3. The no other bugs requiring client side changes will be discovered for the life of the product. 4. That no security vulnerabilities requiring client side changes will be discovered for the life of the product. I think that assumption 1 is a reasonable assumption to make where those protocols are HTTP/1.1 and/or HTTP/2 and/or TLS. I do not think assumption 2, 3 nor 4 are reasonable. Even if the server side was similarly fixed, assumptions 3 and 4 would still apply and would still be unreasonable. I think I would be a good thing (long term) for a number of companies to be forced to go through a multi-million dollar hardware fix / replacement program so that the next time a system like this is designed more thought it is given to the question "What happens when (not if) the client needs to be updated?". The lack of reason phrase and the reasoning behind that decision has been discussed, at length, previously. See bug 60362 for one such discussion. In terms of possible workarounds, several ideas come to mind: a) Add a reverse proxy. Whether this helps will depend on the proxy but there might be one out there that inserts reason phrases. b) Spring Boot supports multiple embedded Servlet containers. Maybe one of the alternatives is more compatible with the clients. c) Figure out why Tomcat 8.5.x doesn't work with Spring Boot 2.2.x and fix it. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
