[swipl 8.0.2] : load_html => Domain error: `http_encoding' expected, found `gzip'

[didier31]

On toplevel shell, try :

?- use_module(library(http/http_open)).
?- use_module(library(sgml)).
?- use_module(library(xpath)).
?- use_module(library(aggregate)).
?- user::load_html('https://releases.llvm.org/7.0.0/tools/clang/docs/ClangCommandLineReference.html', _, []).

It conducts to :

ERROR: Domain error: `http_encoding' expected, found `gzip'
ERROR: In:
ERROR:   [19] throw(error(domain_error(http_encoding,gzip),_43240))
ERROR:   [17] http_open:try_http_proxy(direct,[uri('https://releases.llvm.org/7.0.0/tools/clang/docs/ClangCommandLineReference.html'),...|...],_43280,[cacert_file(...),...|...]) at c:/program files/swipl/library/http/http_open.pl:425
ERROR:   [14] iostream:open_any('https://releases.llvm.org/7.0.0/tools/clang/docs/ClangCommandLineReference.html',read,_43348,_43350,[dialect(html5),...|...]) at c:/program files/swipl/library/iostream.pl:146
ERROR:   [13] <meta call>
ERROR:   [12] '$sig_atomic'(sgml:open_any('https://releases.llvm.org/7.0.0/tools/clang/docs/ClangCommandLineReference.html',read,_43430,_43432,...)) <foreign>
ERROR:   [11] setup_call_catcher_cleanup(sgml:open_any('https://releases.llvm.org/7.0.0/tools/clang/docs/ClangCommandLineReference.html',read,_43478,_43480,...),sgml:load_structure_from_stream(_43492,_43494,...),_43462,sgml:close_any(_43506)) at c:/program files/swipl/boot/init.pl:469
ERROR:    [7] <user>
ERROR: 
ERROR: Note: some frames are missing due to last-call optimization.
ERROR: Re-run your program in debug mode (:- debug.) to get more detail.
   Exception: (14) iostream:open_any('https://releases.llvm.org/7.0.0/tools/clang/docs/ClangCommandLineReference.html', read, _35566, _35568, [dialect(html5), dtd(dtd(1981736, html5)), max_errors(-1), syntax_errors(quiet), type(binary)]) ?

[JanWielemaker]

Does not reproduce, i.e., works fine here (removing user::). Seems the server replied with a gzip document instead of HTML. It should not do so as the client does not indicate it accepts gzip transfer encoding. Seems a non-reproducible non-conforming behaviour of the server.

Note that automatic decompression can be used using the http:encoding_filter/3 hook. There is no default implementation for gzip. I recall this was problematic due to the many poorly configured servers.

[didier31]

Does not reproduce, i.e., works fine here (removing user::)

Nota Bene: (user::) because of logtalk wrapping.

Seems the server replied with a gzip document instead of HTML.

Right. That was my guess.

It should not do so as the client does not indicate it accepts gzip transfer encoding.

Roger.

Seems a non-reproducible non-conforming behaviour of the server.

I experience that, at this time.

Note that automatic decompression can be used using the http:encoding_filter/3

Roger.

I recall this was problematic due to the many poorly configured servers.

As a result, I should close this issue. And sorry for disturbing.

Thank you a lot, Jan and for your response, especially. Have a nice week.