Failing test t/apache/pr64339.t

[Rainer Jung <ra...@kippdata.de>]

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

Re: Failing test t/apache/pr64339.t

[Rainer Jung <ra...@kippdata.de>]

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

[Joe Orton <jo...@redhat.com>]

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

[Eric Covener <co...@gmail.com>]

On Tue, Apr 2, 2024 at 6:06 PM Rainer Jung <ra...@kippdata.de> 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
          </Location>
          <Location /modules/xml2enc/front>
              ProxyHTMLEnable on


From the PR, I guess the +xml case is meant to match (it is not the
original mis-applied xform)