IPvFuture host literals with uppercase `V`, a multi-digit version or `:` are rejected
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- haskell
- Domain
- backend-api-design
Research direction
The parser and character predicate are in Network/URI.hs; start by reading the ipvFuture definition and its surrounding URI parser code. Check the existing parser tests, then cover uppercase V, multiple version digits, and : in the address. Done when isURI, parseURI, and parseURIReference accept the reported valid forms.
Written by the indexing model from the issue text.
Description
The parser for IPvFuture host literals accepts less than the RFC 3986 §3.2.2 rule
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
>>> isURI "http://[v1.a]/"
True
>>> isURI "http://[v1.a:b]/"
False
>>> isURI "http://[v1F.a]/"
False
>>> isURI "http://[V1.a]/"
False
All four should be True; parseURI and parseURIReference return Nothing for the last three.
The code is in Network/URI.hs:
ipvFuture =
do { _ <- char 'v'
; h <- hexDigitChar
; _ <- char '.'
; a <- many1 (satisfy isIpvFutureChar)
; return $ 'v':h:'.':a
}
isIpvFutureChar c = isUnreserved c || isSubDelims c || (c==';')
(c==';')is where the grammar has":".;is already a sub-delim, so this looks like a typo.- The version is a single
hexDigitChar, the grammar has1*HEXDIG. - Only lowercase
vis accepted. The RFC text says "an IP-literal that starts with "v" (case-insensitive)".
A possible fix:
ipvFuture =
- do { _ <- char 'v'
- ; h <- hexDigitChar
+ do { v <- char 'v' <|> char 'V'
+ ; h <- many1 hexDigitChar
; _ <- char '.'
; a <- many1 (satisfy isIpvFutureChar)
- ; return $ 'v':h:'.':a
+ ; return $ v:h ++ '.':a
}
isIpvFutureChar :: Char -> Bool
-isIpvFutureChar c = isUnreserved c || isSubDelims c || (c==';')
+isIpvFutureChar c = isUnreserved c || isSubDelims c || (c==':')
No IPvFuture format is in use as far as I know, so this is low priority.
Tested with network-uri 2.6.4.2 and current master, GHC 9.6.7.
- Dominant language
- Haskell
- Stars
- 28
- Forks
- 34
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from haskell/network-uri
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
haskell/network-uri#93 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
haskell/network-uri#92 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 65/100
haskell/network-uri#90 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
haskell/network-uri#91 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
haskell/network-uri#81 · 2 comments ·
All issues in haskell/network-uri
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
IntersectMBO/cardano-ledger#6276 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
OpenZeppelin/canton-contracts#92 ·
Maintainers usually reply within 1 day