Re: Failing test t/apache/pr64339.t
Am 03.04.24 um 09:52 schrieb Joe Orton: On Tue, Apr 02, 2024 at 08:46:46PM -0400, Eric Covener wrote: This could be due to none of these happening: - mod_mime didn't send a charset from backend - no BOM - no xml2EncDefault (8859-1 effectively by default) on frontend To make the conf match the test code, this works for me to address mod_mime on the backend: Yup. Sorry for wasting your time on this. Thanks for the commit, I had the same change uncommitted locally still and missed it. Thanks Eric for analyzing and fixing and Joe for confirming. The patch fixes it for me as well. Best regards, Rainer
Re: Failing test t/apache/pr64339.t
On Tue, Apr 02, 2024 at 08:46:46PM -0400, Eric Covener wrote: > This could be due to none of these happening: > - mod_mime didn't send a charset from backend > - no BOM > - no xml2EncDefault (8859-1 effectively by default) on frontend > > To make the conf match the test code, this works for me to address > mod_mime on the backend: Yup. Sorry for wasting your time on this. Thanks for the commit, I had the same change uncommitted locally still and missed it.
Re: Failing test t/apache/pr64339.t
On Tue, Apr 2, 2024 at 6:06 PM Rainer Jung wrote: > > Hi there, > > in preparation of the relase I am running the test framework against > recent httpd 2.4.x head. > > I am seeing test failures in t/apache/pr64339.t: > > # testing : content-type header test for /doc.xml > # expected: 'application/xml; charset=utf-8' > # received: 'application/xml;charset=utf-8' > not ok 2 Me too. >From some debugging, this comment doesn't match my logging: ``` # Backend sends Content-Type: application/xml; charset=utf-8 ['/doc.xml', "application/xml; charset=utf-8", "fóó\n" ], ``` >From t/logs/error_log: ``` Backend: Content-Type: application/xml Frontend: Content-Type: application/xml;charset=utf-8 ``` Based on the whitespace, It seems that the charset is added by mod_xml2enc (frontend/proxy) instead of mod_mime. Looking a t/conf there is no AddCharset for XML. >From the next failure, the length really does grow from 6 bytes to 10. I think mod_xml2enc decides to convert the UTF-8 bytes "from" 8859-1 to UTF-8, but it's already UTF-8. This could be due to none of these happening: - mod_mime didn't send a charset from backend - no BOM - no xml2EncDefault (8859-1 effectively by default) on frontend To make the conf match the test code, this works for me to address mod_mime on the backend: Index: t/conf/extra.conf.in === --- t/conf/extra.conf.in (revision 1916756) +++ t/conf/extra.conf.in (working copy) @@ -1527,6 +1527,8 @@ AddType text/html isohtml AddCharset ISO-8859-1 .isoxml AddCharset ISO-8859-1 .isohtml + AddCharset UTF-8 .xml + AddCharset UTF-8 .fooxml ProxyHTMLEnable on >From the PR, I guess the +xml case is meant to match (it is not the original mis-applied xform)
Failing test t/apache/pr64339.t
Hi there, in preparation of the relase I am running the test framework against recent httpd 2.4.x head. I am seeing test failures in t/apache/pr64339.t: # testing : content-type header test for /doc.xml # expected: 'application/xml; charset=utf-8' # received: 'application/xml;charset=utf-8' not ok 2 # testing : content test for /doc.xml # expected: 'fóó # ' # received: 'fÃ<83>³Ã<83>³ # ' not ok 3 and the same for tests 5 and 6. The header differences are hopefully easy to fix, probably in adjusting the expected test response? Unfortunately I have no idea, why the other test fails. Maybe related to the header differences, it seems the received answer has more (double?) bytes than expected, so might be an encoding issue? It might also be a question, how the local perl interpretes the bytes in the test file respectively received via the net. Am I the only one seeing this issue? Best regards, Rainer