Hi guys, 8.5 just being almost a N-1 spec version of tomcat 9 I think they should stay aligned as much as possible. Also note that fixing it in 8.5 will just delay the issue for 9.x. I'm not sure I see the blocking point to add a configuration for that (agree it is not spec compliant but it is a nice feature for broken clients which are widely spread in some languages) but please keep 8.5 and 9 aligned since migrations are expected (and are) smooth for now.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2017-01-25 11:27 GMT+01:00 Rainer Jung <rainer.j...@kippdata.de>: > Am 25.01.2017 um 11:09 schrieb Rainer Jung: > >> Am 24.01.2017 um 21:03 schrieb Mark Thomas: >> >>> On 24/01/2017 19:08, Christopher Schultz wrote: >>> >>> I'm wondering what the wider community thinks about this change and >>>> whether or not we should consider reverting it for Tomcat 8.5.x. >>>> >>> >>> 8.5.x has been out for 10 months and stable for 7. It is probably still >>> early enough that we are seeing issues from the early adopters. We >>> might, therefore, see more issues moving forwards. >>> >>> This change is listed in the change-log for 8.5.0. >>> >>> The root cause is non-specification compliant clients. I generally don't >>> view specification non-compliance in third party code a good reason to >>> make a change in Tomcat. >>> >>> Overall I am -0 on reverting the change for 8.5.x. >>> >> >> For 8.5 we should be aware of the fact, that 8.5 was meant as a quick >> replacement for 8.0 with a reduced support time for 8.0. We also used >> wording like "superseded" on the "Which version" page and probably the >> overall impression is people should soon switch from 8.0 to 8.5 and the >> switch is an easy one to do as long as you do not start to use the new >> features. >> >> Dropping the reason phrase probably is mostly motivated by the new >> language "A client SHOULD ignore the reason-phrase content." in RFC 7230 >> section 3.1.2. Although also the older RFC 2616 already allowed an empty >> reason phrase "Reason-Phrase = *<TEXT, excluding CR, LF>" the language >> was less strict: "The client is not required to examine or display the >> Reason-Phrase.". >> >> IMHO it was only later that servers actually started to drop the reason >> phrase to save a few bytes. Originally it was deemed useful as the old >> spec states "The Reason-Phrase is intended to give a short textual >> description of the Status-Code. The ... Reason-Phrase is intended for >> the human user." >> >> The compatibility break with clients who do not confirm to the newer >> http spec and instead demand the reason phrase will break any >> communication with them. It is not a "be strict in what you send" >> situation for us as a server, because the spec does not require us to >> send an empty reason phrase. >> >> So given the fact that there's no workaround for people who need to >> support clients which require a non-empty reason phrase and also that >> our story for users of 8.0 is to migrate soon and easy to 8.5, I would >> be +1 for a configurable option to bring back reason phrases. Default >> would be "no reason phrases". >> > > I forgot: an option only for 8.5. Dropping it in 9.0 is fine for me. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
