Strategy regarding dropping of http support in libxml2

[Augustin Trancart]

Hi!

libxml2 is dropping http support soon. I was wondering what is the strategy concerning libspatialite?

The question arose on nixpkgs here:  https://github.com/NixOS/nixpkgs/pull/347724

The proposed solution is this patch : https://github.com/NixOS/nixpkgs/pull/347724/files#diff-5d5f554caa9a966f99e6dc6f4a90eb4dc50e2e9b23758a0442dc22b6004ba63b

While this fixes the build, I'm worrying about the runtime consequences. What do you think?

Thanks!

Augustin T.

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

Hello Augustin,

I've spent some time investigating the problem and I can tell
you what I've discovered so far.

starting from release 2.13.0 the public API of the nanohttp
module has been deprecated.

note: this does not mean at all that nanohttp is no longer
supported internally, it literally means that the <nanohttp.h>
header is no longer supported.

in practice, when you call the xmlReadFile() API it continues
to accept either a pathname or a URL, and in this case it
continues to use nanohttp internally without raising the
slightest exception.

the only thing that is no longer possible to do is call
the xmlNanoHTTPCleanup() API which is no longer supported;
with the unpleasant consequence that memory leaks are thus
created.

-----------------------------------

Searching the web I was unable to find any more detailed
reference, the only information provided is that meager
note in the release notes of 2.13.0 which announces the
deprecation of the public API of nanohttp.

It is not at all clear to me whether in the future they
intend to radically remove all http support or not.

Practical consequences for SpatiaLite:

1. for now just eliminate the single call to
xmlNanoHTTPD Cleanup(), possibly using conditional
macros like in your patch.
there will definitely be memory leaks but it has
become impossible to avoid them.

2. if instead http support were to be radically
removed sooner or later the consequences would
be decidedly worse.
SpatiaLite uses libxml2 essentially for only
two purposes where the simplest expat support
is not sufficient:
1 - to download and parse the WFS datasets
2 - to carry out the formal validation of
XML documents against their declared
XSD schemata
if libxml2 were to stop supporting http, the
possibility of continuing to support both
would disappear.
but consequently there would also be no reason
to continue using libxml2 because from our point
of view it would no longer have anything useful
to offer us.

bye Sandro

[Even Rouault]

Hi,

my own "selfish" vision of the role of Spatialite in the FOSS4G
ecosystem is that its main value lies in bringing spatial functions for
SQLite-based databases, either in Spatialite or GPKG formats.

Dealing with Shapefile, DXF, KML, GML, WFS, etc. is a bit of "side"
exercice that other components such as GDAL are probably better
positioned to take care of.

Even

--
http://www.spatialys.com
My software is free, but my time generally not.
Mostly a fool, sometimes acting like a professional (or vice versa)

[Augustin Trancart]

Hi,

Thanks both of you for your answers.

Apparently it does not create memory leak (the author of this comment is one of the maintainers if I'm not mistaken), so I guess nixpkgs will apply this patch for now, until spatialite upgrades to recent version of libxml2.

That being said, it seems that they are quite sure about removing this support: https://gitlab.gnome.org/GNOME/libxml2/-/issues/160#note_1377455 and https://gitlab.gnome.org/GNOME/libxml2/-/issues/631. They did mention that they need to provide some form of support for an alternative solution, but it's still very vague. Good luck for the maintenance work to come, Sandro :-/

Cheers,

Augustin