Re: [OT] Tomcat bug 53814 - PDF plugin in IE cannot download correctly
Mark Thomas wrote: On 16/10/2012 18:54, David Wall wrote: By the way, the web.xml change we made was suggested in the bug report and seems to resolve it for our IE site visitors. Glad to head that disabling support for range requests works. That seems like a reasonable short-term workaround until someone experiencing this error contacts Adobe. This is not exactly the same issue, but I thought I'd share this. Just to give one an idea of what one is up against (and maybe also the difference between open-source and not-open-source) I found this while searching Google for things related to : Adobe Reader plugin +"Range" +"boundary". http://forums.iis.net/p/1161071/1986957.aspx Summary : - an issue between IIS 7.5 and Adobe Reader plugin, related to byteranges, made it impossible to retrieve PDFs - first reported on Sep 21 2009 - it took MS until Dec 12 2009 (2 months) to come up with an explanation that the problem was in the Adobe plugin - MS hotfix released March 21 2010 (6 months later), in which they apparently acknowledge that the problem was theirs after all (http://support.microsoft.com/kb/979543) - as far as I can tell Adobe never did anything And here is another similar issue on an Adobe forum: http://forums.adobe.com/thread/948331?start=0&tstart=0 - first reported Jan 12 2012 - fix released by Adobe on April 26 2012 (3.5 months later), after strong pressure from some very large organisations (e.g., Citibank) And I'll note that the present thread was opened yesterday, and at least a workaround was provided the same day. And the original bug #53814 took 3 days to be tackled. I wouldn't raise my hopes too high about Adobe ever fixing the underlying bug in the plugin though. It seems it is not only the banks that should be broken up before they get too big to fail. I would suggest that one also includes large dominant software companies. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat bug 53814 - PDF plugin in IE cannot download correctly
On 16/10/2012 18:54, David Wall wrote: > By the way, the web.xml change we made was suggested in the bug report > and seems to resolve it for our IE site visitors. Glad to head that disabling support for range requests works. That seems like a reasonable short-term workaround until someone experiencing this error contacts Adobe. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat bug 53814 - PDF plugin in IE cannot download correctly
On 10/15/2012 6:37 PM, 孙文 wrote: You are not suitable the open source community and you are a selfish guy. Wonderful, helpful and insightful! I egregiously suggested that reverting a line of code back to 7.0.26, which was also standards-compliant, would have been easy and would have helped many who use PDF and IE, an apparently selfish request even though I rarely use IE myself. It seemed practical and helpful to me, in the spirit of open source, a community I respect and contribute to daily. By the way, the web.xml change we made was suggested in the bug report and seems to resolve it for our IE site visitors. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat bug 53814 - PDF plugin in IE cannot download correctly
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
Re: Tomcat bug 53814 - PDF plugin in IE cannot download correctly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 10/15/12 2:04 PM, David Wall wrote: > 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." > > That's a rather unsatisfying answer considering it affects PDFs and > IE, a rather common combination. You didn't like the answer "file a separate enhancement request and we'll handle that separately"? If you can't be bothered to file an enhancement request then how do you expect anyone to bother to "fix" this? > 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. By all means, downgrade. Unfortunately, you'll have to suffer all the regressions where fixed bugs make the new versions of Tomcat incompatible with old versions. All new releases could potentially introduce new "problems". This new behavior is not a regression. It is standards-compliant. The client is broken. Anyone can write a broken client. Should Tomcat implement fixes for all broken clients? > Putting the space separator back in seems so straightforward > unless removing the space actually fixes something else. Care to test with all clients and get back to us? This is what standards are for. You're right: the change is straightforward. So is filing an enhancement request. > 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. > > 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. There is no argument whether the space would or not be a spec violation. The question is why the Adobe PDF plug-in requires the space to be there (which is not 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. I think you're being overly sensitive. You can't expect Tomcat to fix (or break) nothing between 7.0 and 7.1. > 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! It's not MSIE's fault, here. It's the PDF plug-in from Adobe (who often takes liberties with standards as well). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB8Yx8ACgkQ9CaO5/Lv0PB70ACdEFoeioV0vxwB9VBP7vmtIiG2 rr8AnihXgHID3h3l/Grj4ZZub+Tbeq65 =4DLC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat bug 53814 - PDF plugin in IE cannot download correctly
2012/10/15 David Wall : > 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." > > That's a rather unsatisfying answer considering it affects PDFs and IE, a > rather common combination. > > 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. > > 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. > > 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. > > 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. > > 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 essence of Comment 5 in bug 53814 is that one has to contact Adobe first for their comment. Thus far (a month passed) it seems that nobody who is affected by this issue have have tried that. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat bug 53814 - PDF plugin in IE cannot download correctly
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." That's a rather unsatisfying answer considering it affects PDFs and IE, a rather common combination. 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. 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. 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. 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. 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! David
