Commits
- Commit:
19e7bd00a3d1b2574e3ed149fa354d45e83a8b50
- From:
- Omar Polo <op@omarpolo.com>
- Date:
[iri] accept also : and @
again, to be RFC3986 compliant.
- Commit:
8404ec301fed4f0bb5a3d1e7b5a2e184a93cc4e5
- From:
- Omar Polo <op@omarpolo.com>
- Date:
don't %-decode the query
- Commit:
2fafa2d23e5607def335902b7a9d10a9de5247a9
- From:
- Omar Polo <op@omarpolo.com>
- Date:
bring the CGI implementation in par with GLV-1.12556
- Commit:
57d0d0adba61856956191554a9624334f083c2f6
- From:
- Omar Polo <op@omarpolo.com>
- Date:
ensure iri.host isn't NULL
- Commit:
117ac52cdd4f45bd5402686b9d4f1d91c32cb1dd
- From:
- Omar Polo <op@omarpolo.com>
- Date:
accept a wider range of UNICODE codepoints while parsing hostnames
- Commit:
9a672b37122cd24931aee82617b30200637b287c
- From:
- Omar Polo <op@omarpolo.com>
- Date:
legibility: use p[n] instead of (*(p + n))
- Commit:
c4f682f8559b184d64b04aece37d3d2980859832
- From:
- Omar Polo <op@omarpolo.com>
- Date:
trim_req_iri: set error string
- Commit:
42bbdc7978acc6be9beb5baa7d94fedb7c211b49
- From:
- Omar Polo <op@omarpolo.com>
- Date:
trim initial forward slashes
this parse gemini://example.com///foo into an IRI whose path is
"foo". I'm not 100% this is standard-compliant but:
1. it seems a logical consequence of the URI/IRI cleaning algo (where
we drop sequential slashes)
2. practically speaking serving file a sequence of forward slashes
doesn't really make sense, even in the case of CGI scripts
- Commit:
881dc835d05029b30bcb7dd229d2a0583fa6e360
- From:
- Omar Polo <op@omarpolo.com>
- Date:
wording
- Commit:
b777bf4b2be13429a31eaefdc89ceaf9fe252f24
- From:
- Omar Polo <op@omarpolo.com>
- Date:
check also that the port number matches
- Commit:
f7b816dc398efba2fb1cd4e2982ee3b23eed624f
- From:
- Omar Polo <op@omarpolo.com>
- Date:
style
- Commit:
e4d82becb71b1b8f9c843a5f0f8657bc6b93c67b
- From:
- Omar Polo <op@omarpolo.com>
- Date:
normalize host name when parsing the IRI
RFC3986 3.2.2 "Host" says that
> Although host is case-insensitive, producers and normalizers should
> use lowercase for registered names and hexadecimal addresses for the
> sake of uniformity, while only using uppercase letters for
> percent-encodings.
so we cope with that.
- Commit:
de428fff65f1ef1a337a1caafb3d580433c73fc9
- From:
- Omar Polo <op@omarpolo.com>
- Date:
normalize schema when parsing the IRI
RFC3986 in section 3.1 "Scheme" says that
> Although schemes are case-insensitive, the canonical form is
> lowercase and documents that specify schemes must do so with
> lowercase letters. An implementation should accept uppercase
> letters as equivalent to lowercase in scheme names (e.g., allow
> "HTTP" as well as "http") for the sake of robustness but should only
> produce lowercase scheme names for consistency.
so we cope with that. The other possibility would have been to use
strcasecmp instead of strcmp when checking on the protocol, but since
the "case" version, although popular, is not part of any standard
AFAIK I prefer downcasing while parsing and be done with it.
- Commit:
6a9ae707737d978bccbabdc36beae509151a7be2
- From:
- Omar Polo <op@omarpolo.com>
- Date:
remove infinite loop
- Commit:
3c1cf9d07cb679ba444566159538b510902f2de9
- From:
- Omar Polo <op@omarpolo.com>
- Date:
s/uri/iri since we accept IRIs