Francisco Lozano, I have a hard time seeing where the fundamental disagreement with our general vision is. We've been discussing this at our team call yesterday, evaluating what we can do to leniently handle clients which are not quite HTTP spec compliant in this respect. We understand that this can be a regression for some scenarios, and we're trying to do the best we can to retain our out-of-the-box 4.2 feature set while also preserving compatibility with such not-quite-compliant clients.
From my perspective, this is simply how modern-day infrastructure evolves. If we would insist on strict 100% compatibility with the behavior of previous versions of the frameworks, we'd be severely constrained with respect to fine-tuning the out-of-the-box experience for new applications. We're aiming for 99.9% and we're usually quite good at finding a balance eventually, even if it takes a few maintenance releases to get there. In contrast to many other projects (be it open source or commercial), we're willing to have a timely and extended discussion, allowing for different opinions that we're then trying to find a balance for, and we're willing to release a fix for the problem pretty much immediately once consensus is reached (and not half a year or even years later).
All in all, I understand your initial frustration - but I have a hard time understanding the outright rejection of a further discussion when we already made the decision to leniently handle scenarios like yours. It's your call, of course, and your time and effort that needs to be justified and managed. In any case, we are going to proceed with our efforts here and I hope that Spring Framework 4.2.3 will at least be closer to the runtime behavior that you were expecting there.