mirror of
https://github.com/omar-polo/gmid.git
synced 2024-08-28 23:27:19 +02:00
33d32d1fd6
Up until now I used a "poor man" approach: the uri parser is barely a parser, it tries to extract the path from the request, with some minor checking, and that's all. This obviously is not RFC3986-compliant. The new RFC3986 (URI) parser should be fully compliant. It may accept some invalid URI, but shouldn't reject or mis-parse valid URI. (in particular, the rule for the path is way more relaxed in this parser than it is in the RFC text). A difference with RFC3986 is that we don't even try to parse the (optional) userinfo part of a URI: following the Gemini spec we treat it as an error. A further caveats is that %2F in the path part of the URI is indistinguishable from a literal '/': this is NOT conforming, but due to the scope and use of gmid, I don't see how treat a %2F sequence in the path (reject the URI?).
26 lines
416 B
Makefile
26 lines
416 B
Makefile
CC = cc
|
|
CFLAGS = -Wall -Wextra -g
|
|
LDFLAGS = -ltls
|
|
|
|
.PHONY: all clean test
|
|
|
|
all: gmid TAGS README.md
|
|
|
|
gmid: gmid.o uri.o
|
|
${CC} gmid.o uri.o -o gmid ${LDFLAGS}
|
|
|
|
TAGS: gmid.c uri.c
|
|
-etags gmid.c uri.c || true
|
|
|
|
README.md: gmid.1
|
|
mandoc -Tmarkdown gmid.1 | sed -e '1d' -e '$$d' > README.md
|
|
|
|
clean:
|
|
rm -f *.o gmid
|
|
|
|
uri_test: uri_test.o uri.o
|
|
${CC} uri_test.o uri.o -o uri_test ${LDFLAGS}
|
|
|
|
test: uri_test
|
|
./uri_test
|