rdelaage
/
gmid
mirror of https://github.com/omar-polo/gmid.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
gmid/Makefile

23 lines
378 B
Makefile
Raw Normal View History

initial commit
2020-10-02 19:39:00 +02:00
CC = cc
CFLAGS = -Wall -Wextra -g
LDFLAGS = -ltls
implement a valid RFC3986 (URI) parser 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?).
2020-12-25 13:13:12 +01:00
.PHONY: all clean test
initial commit
2020-10-02 19:39:00 +02:00
all: gmid TAGS README.md
switch to Bjoern Hoehrmann UTF-8 decoder It's correct, while my hacked valid_multibyte_utf8 would allow things that aren't technically UTF8.
2021-01-09 21:32:23 +01:00
gmid: gmid.o uri.o utf8.o
${CC} gmid.o uri.o utf8.o -o gmid ${LDFLAGS}
initial commit
2020-10-02 19:39:00 +02:00
switch to Bjoern Hoehrmann UTF-8 decoder It's correct, while my hacked valid_multibyte_utf8 would allow things that aren't technically UTF8.
2021-01-09 21:32:23 +01:00
TAGS: gmid.c uri.c utf8.c
-etags gmid.c uri.c utf8.c || true
initial commit
2020-10-02 19:39:00 +02:00
clean:
implement a valid RFC3986 (URI) parser 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?).
2020-12-25 13:13:12 +01:00
rm -f *.o gmid
switch to Bjoern Hoehrmann UTF-8 decoder It's correct, while my hacked valid_multibyte_utf8 would allow things that aren't technically UTF8.
2021-01-09 21:32:23 +01:00
uri_test: uri_test.o uri.o utf8.o
${CC} uri_test.o uri.o utf8.o -o uri_test ${LDFLAGS}
implement a valid RFC3986 (URI) parser 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?).
2020-12-25 13:13:12 +01:00
test: uri_test
./uri_test