libxml2 2.15 will drop HTTP & LZMA support

[Bas Couwenberg]

libxml2 2.15 will drop support for HTTP & LZMA [0], this will break the spatialite build when libxml2 support is enabled as reported in Debian Bug #1106621 [1].

The Debian bugreport was forwarded to Fossil [2], but that got no response unfortunately.

I've forwarded a patch in the Fossil ticket, also available in Debian package git repo [3].

And I would like a second pair of eyes on that patch.

The initial version inverted the logic using OMIT_LIBXML2_NANOHTTP but while that got set in confdefs.h the ifndef blocks around the nanohttp code where still triggered.

[0] https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.14.0

[1] https://bugs.debian.org/1106621

[2] https://www.gaia-gis.it/fossil/libspatialite/tktview/ac85f0fca35de00b9aaadb5078061791fc799d9c

[3] https://salsa.debian.org/debian-gis-team/spatialite/-/blob/38481157178415322d78a3a45dab18f0c1d45daa/debian/patches/libxml2-nanohttp.patch

[a.fu...@lqt.it]

On Thu, 14 Aug 2025 08:16:27 -0700 (PDT), Bas Couwenberg wrote:
> The Debian bugreport was forwarded to Fossil [2], but that got no
> response unfortunately.
>
> I've forwarded a patch in the Fossil ticket, also available in Debian

> package git repo.
>

Hi Bas,

I apologize for not having read your ticket on Fossil, but I have a
bad habit of only considering open tickets in the very last stages
before a new version release.
Typically more than 90% of bug reports come to me through personal
emails or are reported on the mailing list, and as a result, over
the years I've grown accustomed to holding the "official" bug tracker
in low regard.
I can't promise you that I'll try to change my habits in the future,
because I'm almost 70, and you know well that older people become
creatures of habit.
If you have something urgent to bring to my attention, the best
way is always to post a message on the mailing list.

> And I would like a second pair of eyes on that patch.
>

Yes, I confirm that your patch is correct, but it can be made even
simpler.
There is a single line in the entire SpatiaLite code that causes
problems with newer versions of LibXML2.

In the source -/src/wfs/wfs_in.c in the function body
void reset_wfs_http_connection (void)
where the xmlNanoHTTPCleanup() function is called: this
API was first deprecated and then permanently discontinued.
To get SpatiaLite to compile smoothly with newer versions
of LibXML2, you simply need to make that single line of code
ineffective by commenting it out or removing it.

something like this:
--------------------------------------
SPATIALITE_DECLARE void
reset_wfs_http_connection (void)
{
/* xmlNanoHTTPCleanup (); */
}
--------------------------------------

Note however that this is only a rough patch that allows to
build SpatiaLite.
The fact that LibXML2 suddenly decided to remove the traditional
and well-established support for NanoHTTP still has a decidedly
negative impact on SpatiaLite.

1. WFS support is dropped: any operation simply fails.
2- XML schema validation via XSD no longer works; any calls to
it also fail.

Fortunately, these are two fairly niche features that are little
used by most users, but the damage remains and is unfortunately
irreparable at the moment.

bye Sandro

[Bas Couwenberg]

On Saturday, August 16, 2025 at 4:24:57 PM UTC+2 a.fu...@lqt.it wrote:

> And I would like a second pair of eyes on that patch.

Yes, I confirm that your patch is correct, but it can be made even
simpler.
There is a single line in the entire SpatiaLite code that causes
problems with newer versions of LibXML2.

In the source -/src/wfs/wfs_in.c in the function body
void reset_wfs_http_connection (void)
where the xmlNanoHTTPCleanup() function is called: this
API was first deprecated and then permanently discontinued.
To get SpatiaLite to compile smoothly with newer versions
of LibXML2, you simply need to make that single line of code
ineffective by commenting it out or removing it.

something like this:
--------------------------------------
SPATIALITE_DECLARE void
reset_wfs_http_connection (void)
{
/* xmlNanoHTTPCleanup (); */
}
--------------------------------------

Note however that this is only a rough patch that allows to
build SpatiaLite.

Unconditionally disabling the code didn't seem like a good solution that could be upstreamed, my approach doesn't change anything with older versions of libxml2 while also allow building successfully with libxml2 without its HTTP support.

Which approach would you incorporate into the next SpatiaLite release?

 

The fact that LibXML2 suddenly decided to remove the traditional
and well-established support for NanoHTTP still has a decidedly
negative impact on SpatiaLite.

It seems that they are reducing the attack surface of the codebase while also reducing the workload of its maintainer.

For some context see: https://lwn.net/Articles/1025971/

 

1. WFS support is dropped: any operation simply fails.

This does not seem to be within the scope of an XML library.

 

2- XML schema validation via XSD no longer works; any calls to
it also fail.

While this most certainly is.

The libxml2 maintainer suggests users who need this to implement their own entity loader, that would enable them support HTTPS for example which libxml2 never did:

 https://gitlab.gnome.org/GNOME/libxml2/-/issues/160#note_1005256

 

Fortunately, these are two fairly niche features that are little
used by most users, but the damage remains and is unfortunately
irreparable at the moment.

I suspect a combination of libcurl & libxml2 would make WFS support possible. But I do question whether SpatiaLite needs WFS support, it seems to me that would be the domain of the application using SpatiaLite.

Kind Regards,

Bas

[a.fu...@lqt.it]

Hi Bas,

> The libxml2 maintainer suggests users who need this to implement
> their own
> entity loader, that would enable them support HTTPS for example which
> libxml2
> never did

> I suspect a combination of libcurl & libxml2 would make WFS support
> possible.
>

It's absolutely true: I've already done some preliminary testing.
It's a bit tricky to implement, it will require significant development
time,
but it undoubtedly works.

The hardest obstacle remains the formal validation of XSD schemas.
This works for simpler cases, but fails when there are long, deeply
branching chains of <include>.
Unfortunately, this is precisely the case with the XSD schemas defined
by OGC (see SLD/SE styles) which are the ones we are directly
interested in.
I haven't yet found a satisfactory solution, but it's also true that
I haven't invested much time in it. I don't despair of succeeding in
the next future.

> Unconditionally disabling the code didn't seem like a good solution
> that
> could be upstreamed, my approach doesn't change anything with older
> versions of libxml2 while also allow building successfully
> with libxml2 without its HTTP support.
> Which approach would you incorporate into the next SpatiaLite
> release?
>

I see only two possible alternatives:

A) If it will be not possible to achieve satisfactory validation of XSD
schemas, then all support for WFS and SLD/SE will be radically
removed
from SpatiaLite.

B) If this will be possible, then libcurl will become a required
dependency
to enable SpatiaLite's WFS and SLD/SE support.

bye Sandro