Hi, I definitely value the feedback and thoughts.
I understand and I agree it's unlikely to be a real world use case. I am happy to give it a try to improve the flag and submit a PR for it. I'll make sure to fire a new TCK build with everything (servlet, jsp, etc) so we have more confidence in the fix. Thanks Le jeu. 15 avr. 2021 à 10:57, Mark Thomas <ma...@apache.org> a écrit : > On 15/04/2021 09:03, Jean-Louis MONTEIRO wrote: > > I've got an answer from JSTL team. > > Here it is > > <snip/> > > >> 1. Jakarta Tags Specification Section 7.4 details the <c:import> > tag: > >> c:import > >> < > https://github.com/eclipse-ee4j/jstl-api/blob/master/spec/src/main/asciidoc/jakarta-stl.adoc#74-cimport > > > >> > >> Within this, it details the following: Character Encoding : The > >> <c:import/> for import-encoded.txt does not include an encoding so the > >> default encoding is used: ISO-8859-1 > > </snip> > > >> At this point from a Jakarta Tags perspective, I believe the golden file > >> is correct. > > Thanks for passing that on. > > The Default Servlet improvements were written from the perspective of > including static content with a variety of encodings where the correct > encoding was not always known (or maintaining an accurate mapping of > encoding to resource would impose a significant overhead). > > JSTL is coming from the perspective that the encoding of the included > target is always known. > > Currently Tomcat provides the 'useBomIfPresent' option to control the > BoM handling. The current values are: > > - true - BoM is stripped if present and any BoM found used to determine > the encoding used to read the resource. This is the default. > > - false - BoM is stripped and resource is read using the configured file > encoding (which will be the platform default if not explicitly > configured) > > If we wanted to address this and provide a way to allow JSTL to have the > control over the included content required to pass this TCK test then we > could modify 'useBomIfPresent' as follows: > > - true - no change - remains the default > > - false - no change > > - ignore - as current false but does not strip the BoM from the output > > This would have no impact on existing users but using the new ignore > option would allow the JSTL TCK to pass. > > I do wonder if this use case has any real world consequences. For that > to be that case there would need to be an application where: > - JSTL was importing static resources > - the content of static resource started with the same bytes as a valid > BoM > > That seems unlikely as the BoM values look to have been chosen to avoid > this. While it is (very?) unlikely, it isn't impossible so I'm not > against this change. Normally, I'd worry about regressions but the test > case coverage is good in this area. > > Any objections to implementing this? Thoughts on a better solution? > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- Jean-Louis
