notroj / litmus Goto Github PK
View Code? Open in Web Editor NEWWebDAV test suite.
Home Page: https://notroj.github.io/litmus/
License: GNU General Public License v2.0
WebDAV test suite.
Home Page: https://notroj.github.io/litmus/
License: GNU General Public License v2.0
Describe the bug
I'm trying to build it on macOS.
Environment
To Reproduce
autoconf
./configure
, which yields:
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /opt/homebrew/bin/ginstall -c
./configure: line 3455: syntax error near unexpected token `0,'
./configure: line 3455: `NE_REQUIRE_VERSIONS(0, 27 28 29 30 31 32)'
How can I fix it?
There is a fork https://github.com/tolsen/litmus
It has some changes that probably are useful. Could you please grab them?
Hi 👋
I’m trying to build on macOS:
$ sw_vers
ProductName: macOS
ProductVersion: 12.6
BuildVersion: 21G115
and getting this error from ./configure
:
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /opt/homebrew/bin/ginstall -c
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /opt/homebrew/bin/ggrep
checking for egrep... /opt/homebrew/bin/ggrep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for inline... inline
checking for an ANSI C-conforming const... yes
checking for size_t... yes
checking for off_t... yes
checking for uname... Darwin
checking size of int... 4
checking size of long... 8
checking size of long long... 8
checking for gcc -Wformat -Werror sanity... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking stdarg.h usability... yes
checking stdarg.h presence... yes
checking for stdarg.h... yes
checking for string.h... (cached) yes
checking for stdlib.h... (cached) yes
checking size of size_t... 8
checking how to print size_t... lu
checking size of off_t... 8
checking how to print off_t... lld
checking size of ssize_t... 8
checking how to print ssize_t... ld
checking size of time_t... 8
checking how to print time_t... ld
checking for pid_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for ar... /usr/bin/ar
checking for ranlib... /usr/bin/ranlib
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for stdint.h... (cached) yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking for pipe... yes
checking for isatty... yes
checking for usleep... yes
checking for shutdown... yes
checking for setlocale... yes
checking for gethostname... yes
checking whether byte ordering is bigendian... no
checking whether strerror_r is declared... yes
checking for strerror_r... yes
checking whether strerror_r returns char *... no
checking for snprintf... yes
checking for vsnprintf... yes
checking for neon-config... /opt/homebrew/bin/neon-config
checking linking against neon... yes
configure: incompatible neon library version 0.32.4: wanted 0.25 26 27 28 29
configure: using bundled neon (0.29.6)
checking for sys/time.h... (cached) yes
checking for limits.h... yes
checking for sys/select.h... yes
checking for arpa/inet.h... yes
checking for libintl.h... no
checking for signal.h... (cached) yes
checking for sys/socket.h... yes
checking for netinet/in.h... yes
checking for netinet/tcp.h... yes
checking for netdb.h... yes
checking for sys/poll.h... yes
checking for sys/limits.h... no
checking for fcntl.h... yes
checking for iconv.h... yes
checking for timezone global... yes
configure: LFS support unnecessary, off_t is not 32-bit
checking for strtoll... yes
checking for strcasecmp... yes
checking for signal... yes
checking for setvbuf... yes
checking for setsockopt... yes
checking for stpcpy... yes
checking for poll... (cached) no
checking for fcntl... yes
checking for getsockopt... yes
checking whether stpcpy is declared... yes
checking for library containing socket... not found
zsh: exit 1 ./configure
Is this a known issue?
Random properties placed in the "set" are not necessarily allowed on the server.
It is therefore normal that a multistatus response with a code 207 is generated and for some tests this should be enough!
Even if the content of the multistatus contains errors (unknown or unauthorized properties)
Some examples:
In this case a 207 response should be accepted (the properties are not allowed)
Same for the propmanys test.
In Golang webdav implementation I found this
Section 7.5.1 says that a COPY only needs to lock the destination,
not both destination and source. Strictly speaking, this is racy,
even though a COPY doesn't modify the source, if a concurrent
operation modifies the source. However, the litmus test explicitly
checks that COPYing a locked-by-another source is OK.
https://github.com/golang/net/blob/9f24bb44e6dfa4fadbda1cd143a46d288ba89ae5/webdav/webdav.go#L356
Can you please clarify it this is expected or maybe the Litmus test can be improved
Describe the bug
Make basic test with URL specified, for example, to http://localhost:9999/api/fileserver/webdav/
Get an error on test 6: FAIL (PUT to create resource MUST return 201 [RFC9110ẞ9.3.4])
That's because put_location does not treat url and makes request to /dav/put%23test
Environment
To Reproduce
make URL=http://localhost:12345/some/path check
Debugging output
Running pre_send hooks
Sending request headers:
PUT /dav/put%23test HTTP/1.1
User-Agent: litmus/0.15 neon/0.33.0
Connection: TE
TE: trailers
Host: localhost:12345
Content-Length: 5
X-Litmus: basic: 6 (put_location)
Sending request-line and headers:
Sending request body:
Body block (5 bytes):
[hello]
Request sent; retry is 1.
[status-line] < HTTP/1.1 404 Not Found
Line 404 in f261220
Line 405 in f261220
Line 409 in f261220
Line 412 in f261220
From https://datatracker.ietf.org/doc/html/rfc4918#section-10.4.8:
"DAV:no-lock" is known to never represent a current lock token
The expected response code is therefore 204 in this case since the resource is not locked
The other solution is to use (Not <DAV:no-lock>)
to make it consistent.
Describe the bug
litmus props
does not sent Content-Type: application/xml
with PROPFIND
and PROPPATCH
non-zero request bodies
Environment
litmus git master HEAD
NEWS
for litmus 0.14)$ git submodule status
258301b2fb85398ed478386faf220228457ec3b5 neon (0.32.3-29-g258301b)
$ openssl version
OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
To Reproduce
lighttpd mod_webdav returns 415 Unsupported Media Type for litmus tests sending PROPFIND
or PROPPATCH
requests with a non-zero request body when litmus is run against lighttpd mod_webdav. The tests pass if I disable lighttpd mod_webdav strict enforcement that request body to PROPFIND
and PROPPATCH
with non-zero length must have Content-Type: application/xml
or Content-Type: text/xml
.
When XML is used for a request or response body, the Content-Type
type SHOULD be application/xml. Implementations MUST accept both
text/xml and application/xml in request and response bodies. Use of
text/xml is deprecated.
While the wording could be a bit more explicit, I read the above as implying that one of Content-Type: application/xml
or Content-Type: text/xml
is required, or at least that the server is allowed to reject anything other than the two types that were stated as types the server MUST accept for those XML request or response bodies.
Are you aware of any WebDAV clients (besides litmus) which omit Content-Type
in PROPFIND
or PROPPATCH
requests containing a non-zero request body? Do you think that I should downgrade lighttpd mod_webdav strict enforcement and "assume" that the request body is Content-Type: application/xml
if Content-Type
is not provided?
Debugging output
2. propfind_invalid...... FAIL (PROPFIND with non-well-formed XML request body got 415 response not 400)
3. propfind_invalid2..... FAIL (PROPFIND with invalid namespace declaration in body (see FAQ) got 415 response not 400)
15. propnullns............ FAIL (PROPPATCH of property with null namespace (see FAQ))
16. propget............... FAIL (No value given for property {}nonamespace)
17. prophighunicode....... FAIL (PROPPATCH of property with high unicode value)
18. propget............... FAIL (No value given for property {http://example.com/neon/litmus/}high-unicode)
19. propremoveset......... FAIL (PROPPATCH remove then set)
20. propget............... FAIL (No value given for property {http://example.com/neon/litmus/}removeset)
21. propsetremove......... FAIL (PROPPATCH remove then set)
23. propvalnspace......... FAIL (PROPPATCH of property with value defining namespace)
I think litmus is not compatible with openssl 3
./configure --with-ssl
configure: Configured to build litmus 0.13:
Install prefix: /usr/local
Compiler: gcc
neon library: included libneon (0.29.6)
XML parser: expat
SSL library: SSL support enabled, using OpenSSL (0.9.7 or later)
But building fails
make
gcc -DHAVE_CONFIG_H -I. -I./lib -I./src -I./test-common -g -O2 -I./lib/neon -c src/basic.c -o src/basic.o
make[1]: Verzeichnis „/tmp/litmus/litmus-0.13/lib/neon“ wird betreten
gcc -DHAVE_CONFIG_H -I../.. -I../../lib -g -O2 -I../../lib/neon -c ne_request.c -o ne_request.o
gcc -DHAVE_CONFIG_H -I../.. -I../../lib -g -O2 -I../../lib/neon -c ne_session.c -o ne_session.o
gcc -DHAVE_CONFIG_H -I../.. -I../../lib -g -O2 -I../../lib/neon -c ne_basic.c -o ne_basic.o
gcc -DHAVE_CONFIG_H -I../.. -I../../lib -g -O2 -I../../lib/neon -c ne_string.c -o ne_string.o
gcc -DHAVE_CONFIG_H -I../.. -I../../lib -g -O2 -I../../lib/neon -c ne_uri.c -o ne_uri.o
gcc -DHAVE_CONFIG_H -I../.. -I../../lib -g -O2 -I../../lib/neon -c ne_dates.c -o ne_dates.o
gcc -DHAVE_CONFIG_H -I../.. -I../../lib -g -O2 -I../../lib/neon -c ne_alloc.c -o ne_alloc.o
gcc -DHAVE_CONFIG_H -I../.. -I../../lib -g -O2 -I../../lib/neon -c ne_md5.c -o ne_md5.o
gcc -DHAVE_CONFIG_H -I../.. -I../../lib -g -O2 -I../../lib/neon -c ne_utils.c -o ne_utils.o
gcc -DHAVE_CONFIG_H -I../.. -I../../lib -g -O2 -I../../lib/neon -c ne_socket.c -o ne_socket.o
ne_socket.c: In Funktion »writev_raw«:
ne_socket.c:574:15: Warnung: Implizite Deklaration der Funktion »writev«; meinten Sie »write«? [-Wimplicit-function-declaration]
574 | ret = writev(sock->fd, vec, count);
| ^~~~~~
| write
ne_socket.c: In Funktion »ne_sock_sessid«:
ne_socket.c:1845:23: Fehler: falsche Verwendung des unvollständigen typedef »SSL_SESSION« {alias »struct ssl_session_st«}
1845 | *buflen = sess->session_id_length;
| ^~
ne_socket.c:1849:23: Fehler: falsche Verwendung des unvollständigen typedef »SSL_SESSION« {alias »struct ssl_session_st«}
1849 | if (*buflen < sess->session_id_length) {
| ^~
ne_socket.c:1853:19: Fehler: falsche Verwendung des unvollständigen typedef »SSL_SESSION« {alias »struct ssl_session_st«}
1853 | *buflen = sess->session_id_length;
| ^~
ne_socket.c:1854:21: Fehler: falsche Verwendung des unvollständigen typedef »SSL_SESSION« {alias »struct ssl_session_st«}
1854 | memcpy(buf, sess->session_id, *buflen);
| ^~
make[1]: *** [Makefile:71: ne_socket.o] Fehler 1
make[1]: Verzeichnis „/tmp/litmus/litmus-0.13/lib/neon“ wird verlassen
make: *** [Makefile:97: subdirs] Fehler 2
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.