On 15/10/2012 19:04, David Wall wrote: As the person who closed Bug 53814 as invalid, I thought it would be useful to expand on my reasoning for doing so.
> In researching a bug our users are now suffering, I found that it was > reported already as *Bug 53814****- Could not display PDF file on Tomcat > 7.0.27 above.* > > Sadly, it also shows that's it's considered "invalid" and won't be fixed > because the change made between 7.0.26 and 7.0.27 is "standards compliant." There is more to it than that. It has been a general rule for as long as I have been involved in the project that Tomcat does not implement workarounds for bugs in clients, JVMs, operating systems, databases or any other component with which it interacts. There are several reasons for this position. In no particular order: - the workarounds are an additional maintenance burden - if is more efficient to fix the root cause than to implement a workaround in every application that interacts with the buggy one - it encourages standards compliance which is a good thing - why would anyone volunteer to clean up someone else's mess? - it isn't unknown for different applications to have conflicting bugs that can't both be worked around There have, however, been exceptions to the rule... > That's a rather unsatisfying answer considering it affects PDFs and IE, > a rather common combination. Bugs that affect large numbers of users and are from vendors that are known to be very slow fixing them (or who just ignore them) have been workaround in the past. They are assessed on a case by case basis. Since there is no evidence that a) Adobe have been made aware of this bug and b) Adobe have refused to fix this bug then I will remain -1 on implementing a workaround. > The change was made in the 7.0.27 release, causing the bug to appear. > Yes, the bug is in fact in the PDF reader of IE, but it is sad when a > bug release (not going from 7.0 to 7.1, but 7.0.26 to 7.0.27) introduces > new problems. The Tomcat team generally test that changes are standards compliant. We can't possibly test every possible client to ensure that Tomcat is consistent with their particular, incorrect version of the standard. > Putting the space separator back in seems so straightforward unless > removing the space actually fixes something else. It is not clear in the > bug report if the change was made for a particular reason or not since > bug 52811 doesn't appear to be an issue with 'boundary' at all. Yes the work around is simple. That has little impact on the likelihood of it being implemented. > It is not clear that having the space would not be compliant with the > spec. The comment in the bug report even says that all of the examples > in the specification have a whitespace before parameter. Adding the space is standard compliant. > I guess I can understand a change like this that will break working > systems if the change were required to be standards compliant and > standards-compliant browsers had trouble because of the space being > there, but if not, it shouldn't occur in such a late patch release > (7.0.27) rather than a new minor release like 7.1. Tomcat 7.0.26 is compliant with RFC 2616. Tomcat 7.0.27 is complaint with RFC 2616. A system that does not follow the standard is not fully working. It just happens to work with some combinations. I could equally say it was responsibility of the developers depending on the Adobe plug-in to fully test that that component was standards compliant and that the problems they are now seeing are the direct result of their failure to do so. That would be just as unreasonable as expecting the Tomcat team to do such testing. > I hope that keeping things working is the prevailing idea behind patch > releases. Of course, it's not surprising that IE would be the one > browser to have this problem handling standards-compliant syntax! The primary aims of each point release are to fix bugs without introducing regressions. Regressions do happen and I have been guilty of creating a few of them. However, BZ 53814 is not a regression; it is a bug in a third party component. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
