sparqlvirtuosohttp-compression

How to compress query results?

A large part of the network data and time of our app startup is used by SPARQL query responses sent over the network in uncompressed JSON.

Firefox (dev edition 129.0b9) sends the appropriate request headers but Virtuoso does not seem to accept them. The requests are sent using standard JavaScript fetch requests with URIs of the shape https://ourdomain.de/sparql?query=[...]&format=json.

Is there a way to enable query result compression either on the client side or in our virtuoso server (Docker image from Docker Hub "openlink/virtuoso-opensource-7")?

I am not an expert in HTTP requests and responses but to me it seems as if compression is requested:

Request Headers

GET /sparql?query=[...]format=json HTTP/1.1
Host: www.snik.eu
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Referer: https://www.snik.eu/graph/
DNT: 1
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=4
Pragma: no-cache
Cache-Control: no-cache

Response Headers

HTTP/1.1 200 OK
Date: Thu, 01 Aug 2024 07:43:11 GMT
Server: Virtuoso/07.20.3239 (Linux) x86_64-ubuntu_bionic-linux-gnu
Accept-Ranges: bytes
Content-disposition: filename=sparql_2024-08-01_07-43-11Z.json
Content-Type: application/sparql-results+json
Content-Length: 2766401
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

screenshot of the Firefox Developer Edition Network Tab

Solution

  • Check your active INI file (default is virtuoso.ini).

    You should find EnabledGzipContent in the [HTTPServer] stanza. As documented --

    EnabledGzipContent = 0. This sets the default behavior of HTTP transmission. If set to 1 The Virtuoso HTTP server will send GZipped content to user agents. Otherwise content will be sent as is. The function http_enable_gz() lets you change the server mode on the fly.

    Squaring the circle: There was a bug in the code, which has been resolved, as discussed at issue #1308. The answer above remains accurate, and now it works. :-)