haskell / network-uri Goto Github PK

View Code? Open in Web Editor NEW

24.0 24.0 33.0 174 KB

URI manipulation facilities

License: Other

Haskell 100.00%

network-uri's People

Contributors

Stargazers

Watchers

network-uri's Issues

Cabal's dependency solver gets the network-uri split wrong

As reported in haskell/cabal#2063 Cabal doesn't get the network-uri split right and thus we get module name clashes. We need to release a dummy 2.5 version and update the module docs with a workaround.

Test suite failure when run from Hackage

This does not occur in the Git repo itself, only when running cabal install network-uri --run-tests:

Preprocessing test suite 'uri' for network-uri-2.6.0.1...

tests/uri001.hs:38:8:
    Could not find module ‘Network.URI’
    It is a member of the hidden package ‘network-uri-2.6.0.1’.
    Perhaps you need to add ‘network-uri’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘network-2.5.0.0’.
    Perhaps you need to add ‘network’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.
Failed to install network-uri-2.6.0.1
cabal: Error: some packages failed to install:
network-uri-2.6.0.1 failed during the building phase. The exception was:
ExitFailure 1

network-uri-2.6.0.2 release breaks GHC 6.12.3 support

According to http://hydra.cryp.to/build/790708/nixlog/1/raw, the symbol void is missing:

Network/URI.hs:128:37:
    Module `Control.Monad' does not export `void'

Maybe base-compat can help mitigate this kind of issue without having to resort to CPP?

Make revisions for older network-uri releases

So cabal-install doesn't pick them with GHC-9.0.

In particular, it's only network-uri-2.6.3.0 which seems to need a revision:

                     9.0.1  8.10.3  8.8.4  8.6.5  8.4.4  8.2.2  8.0.2  7.10.3  7.8.4  7.6.3  7.4.2  7.2.2  7.0.4
network-uri-2.6.4.1  OK     OK      OK     OK     OK     OK     OK     OK      OK     OK     OK     OK     OK   
network-uri-2.6.4.0  OK     OK      OK     OK     OK     OK     OK     OK      OK     OK     OK     OK     OK   
network-uri-2.6.3.0  FAIL   OK      OK     OK     OK     OK     OK     OK      OK     OK     OK     OK     OK   
network-uri-2.6.2.0  NO-IP  NO-IP   OK     OK     OK     OK     OK     OK      OK     OK     OK     OK     OK   
network-uri-2.6.1.0  OK     OK      OK     OK     OK     OK     OK     OK      OK     OK     OK     OK     OK

Why the : before the port in the URI record?

I see that putting a : character in front of the port is clearly intentional :
https://github.com/haskell/network-uri/blob/master/Network/URI.hs#L602

Two questions:

Could this be a Maybe Int instead of a string? Most URI implementations store this as an integer and it is far more convenient.
Failing that..
Why is there a : in front of the value? This makes it rather annoying to parse out.

Add a quasiquoter for safely expressing URI literals at compile time

https://hackage.haskell.org/package/network-uri-static-0.1.0.0/docs/Network-URI-Static.html

Please add link to new network-uri-flag package in `.cabal` description

See http://hackage.haskell.org/package/network-uri-flag

The network-uri-flag package is a good alternative so ppl don't have to copy'n'paste the flag(network-uri) boilerplate into every package wanting to support network-2.5, so IMHO this should be mentioned as an alternative in network-uri.cabal's description.

PS: If you prefer, I can submit a PR

Incorrectly (I think) parsed URI from the spec

The spec has these examples of URIs:

      ftp://ftp.is.co.za/rfc/rfc1808.txt

      [http://www.ietf.org/rfc/rfc2396.txt](https://www.ietf.org/rfc/rfc2396.txt)

      ldap://[2001:db8::7]/c=GB?objectClass?one

      mailto:[email protected]

      news:comp.infosystems.www.servers.unix

      tel:+1-816-555-1212

      telnet://192.0.2.16:80/

      urn:oasis:names:specification:docbook:dtd:xml:4.1.2

Some of them are parsed incorrectly (I think):

ghci> uriPath <$> parseURIReference "mailto:[email protected]"
Just "[email protected]"
ghci> uriPath <$> parseURIReference "news:comp.infosystems.www.servers.unix"
Just "comp.infosystems.www.servers.unix"

Is this indeed wrong?
Could these be added to the test suite?

Typo in documentation for normalizePathSegments

Path segment normalization; cf. RFC3986 section 6.2.2.4

I think it should be section 6.2.2.3.

Dependency parsec method not exposed

Hi while compiling my project I get the error in parsec dependency

Text\Parsec\Prim.hs:203:5: error:
parsec > fail' is not a (visible) method of class Monad'
parsec > |
parsec > 203 | fail msg = parserFail msg

cabal file:
build-depends: base >= 4.7 && < 5,
mongoDB,
text,
network-uri,
split

Using: stack

Allow deepseq-1.5 (is going to be bundled with GHC-9.8)

Export URI parser

The library exports String -> Maybe URI functions, but this is not easy to compose with other parsers. For example, I'm writing a tokeniser that needs to identify URIs and a bunch of other stuff. I have to do some tedious gymnastics to fit parseURI in, but if I had access to the actual Parser itself, it would be much easier.

Possibility of Data.Text implementation of parseURI

Would it be possible to have a Data.Text / Data.ByteString implementation of parseURI? I'm a bit native to the work required to implement this, but parsing urls seems to be one of a common reason for me having to cast between Data.Text / Data.ByteString and String.

Clarification: Should the strings in a `URI` type from this package be considered already escaped or not?

When manipulating URIs, it's important to know whose responsibility it is to call encodeURI, decodeURI, and friends. I'm not clear on whether the responsibility to do URI escaping falls on the person creating the Network.URI.URI, or the person rendering it. For example, does URI "http:" Nothing "/ø" "" "" construct an invalid instance of URI, or should whoever's rendering it be responsible for producing "http:/%C3%B8"?

GitHub Release?

Is there any intention to tag releases for this on github?

IPv6 zoneid is not supported

Please see snoyberg/http-client#256

The ipv4address parser depends on broken behaviour of Parsec's notFollowedBy

See haskell/parsec#8; if this issue should be fixed in Parsec, it would trigger the bug in network-uri in turn.

A straightforward fix is to replace notFollowedBy regName by notFollowedBy ( unreservedChar <|> escaped <|> subDelims ). It would probably be better to extract the argument of notFollowedBy into a separate definition which would be used by regName as well.

`parseQuery` should split on `?` as well

According to https://tools.ietf.org/html/rfc3986#section-3.4, the query parameters are possible to be separated by ? marks. In fact, this is the main separator, while & is an application-specific sub-separator that happens to be often used for HTTP URIs.

https://kythe.io/docs/kythe-uri-spec.html uses ?s for separators, which is RFC-compatible. For example: kythe://something?root=bin/bla?path=foobar#anchor.

isUnescapedInURI '%' should not be False

Since % is routinely present unescaped in a URI (and such is required to have any escapes!)

Add RelURI, AbsURI

UriAuth is under Maybe - as I understood due to wrap relative/absolute URIs under one type. If I have abs. URI I will propagate those Maybe anywhere. Better may be to distinguish abs. and rel. URIs - with different types. When I parse rel. URI (reference) - no any auth. In this case combining URIs will be checked on type level: rel+rel, abs+rel, but no abs+abs.

Parse queries to a map of `String` to `String` using `'&'` and `'='`

This would be a really useful utility function to have, though since I don't think & and = are actually part of the official URI specification I understand if you want to leave it out.

Parsing URIs with unicode symbols fails

Prelude Network.URI> parseURI "http://ex.com/?drink=Øl"
Nothing

Build failure with GHC 9.0.1

[1 of 3] Compiling Network.URI      ( Network/URI.hs, dist/build/Network/URI.o, dist/build/Network/URI.dyn_o )

Network/URI.hs:10:14: warning: [-Wtrustworthy-safe]
    ‘Network.URI’ is marked as Trustworthy but has been inferred as safe!
   |
10 | {-# LANGUAGE Trustworthy #-}
   |              ^^^^^^^^^^^
[2 of 3] Compiling Network.URI.Lens ( Network/URI/Lens.hs, dist/build/Network/URI/Lens.o, dist/build/Network/URI/Lens.dyn_o )

Network/URI/Lens.hs:20:1: warning: [-Wunused-imports]
    The import of ‘Control.Applicative’ is redundant
      except perhaps to import instances from ‘Control.Applicative’
    To import instances alone, use: import Control.Applicative()
   |
20 | import           Control.Applicative
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[3 of 3] Compiling Network.URI.Static ( Network/URI/Static.hs, dist/build/Network/URI/Static.o, dist/build/Network/URI/Static.dyn_o )

Network/URI/Static.hs:59:34: error:
    • Couldn't match type: Language.Haskell.TH.Syntax.Code m1 URI
                     with: Language.Haskell.TH.Syntax.Q
                             (Language.Haskell.TH.Syntax.TExp URI)
      Expected: TExpQ URI
        Actual: Language.Haskell.TH.Syntax.Code m1 URI
    • In the Template Haskell quotation [|| u ||]
      In the expression: [|| u ||]
      In an equation for ‘staticURI’:
          staticURI (parseURI -> Just u) = [|| u ||]
   |
59 | staticURI (parseURI -> Just u) = [|| u ||]
   |                                  ^^^^^^^^^

Network/URI/Static.hs:112:64: error:
    • Couldn't match type: Language.Haskell.TH.Syntax.Code m0 URI
                     with: Language.Haskell.TH.Syntax.Q
                             (Language.Haskell.TH.Syntax.TExp URI)
      Expected: TExpQ URI
        Actual: Language.Haskell.TH.Syntax.Code m0 URI
    • In the Template Haskell quotation [|| ref ||]
      In the expression: [|| ref ||]
      In an equation for ‘staticRelativeReference’:
          staticRelativeReference (parseRelativeReference -> Just ref)
            = [|| ref ||]
    |
112 | staticRelativeReference (parseRelativeReference -> Just ref) = [|| ref ||]
    |                                                                ^^^^^^^^^^^

Is `isUnescapedInURI` written incorrectly?

isUnescapedInURI documentation says:

Returns True if the character is allowed unescaped in a URI.

However, its implementation is:

isUnescapedInURI c = isReserved c || isUnreserved c

where isReserved documentation says:

Returns True if the character is a "reserved" character in a URI. To include a literal instance of one of these characters in a component of a URI, it must be escaped.

So, it seems to me that if isReserved returns True, then isUnescapedInURI ought to return False.

parseURI does not treat brackets properly

Hi.
I found parseURI returns Nothing when input string contains '[' or ']'.
Since isAllowedInURI returns True for '[' and ']', parseURI should not be fail for uri that contains bracket character.

Depend on network

Is the motivation of this package to get rid of the parsec dependency on network? If so, there is a way to make this work without requiring every client package to use cabal flags: Just depend on network and either re-export or provide the own implementation (depending on the version of network).

The downside of this is that network is installed even if it's not needed. The advantage is that client code does not need to use cabal flags.

Considering that cabal flags in test suite sections break some older versions of cabal-install in a severe way, I would vote for depending on network.

"\65535" not handled by escape/unescape

As reported by a random test failure, https://travis-ci.org/haskell/network-uri/jobs/652033164, the string "\65535" is apparently not correctly handled in an escape/unescape round-trip. It's a bit of an edge case, for sure, but let's track it down.

Fix compilation warnings

Dunno, somehow cabal builds network-uri very often on my system, and I always see the same warnings (see below).
Could these warnings be fixed?

Building library for network-uri-2.6.4.1..
[1 of 3] Compiling Network.URI      ( Network/URI.hs, dist/build/Network/URI.o, dist/build/Network/URI.dyn_o )

Network/URI.hs:10:14: warning: [-Wtrustworthy-safe]
    ‘Network.URI’ is marked as Trustworthy but has been inferred as safe!
   |
10 | {-# LANGUAGE Trustworthy #-}
   |              ^^^^^^^^^^^

Network/URI.hs:1418:23: warning: [-Woperator-whitespace-ext-conflict]
    The prefix use of a ‘$’ would denote an untyped splice
      were the TemplateHaskell extension enabled.
    Suggested fix: Add whitespace after the ‘$’.
     |
1418 | authority = dropss . ($"") . uriAuthToString id . uriAuthority
     |                       ^

Blacklist 2.7.0.0 and release as 2.6.2.0

based on changelog entries

Merge network-uri-static (Network.URI.Static) into this package
Add Lenses for the URI types
Optimize isReserved and related character-class functions
Add Generic instances for the URI type

none of these are breaking changes, so the major bump seems to be unnecessary and only causes churn on the Hackage.

All of these additions fall into

Non-breaking change. Otherwise, if only new bindings, types, classes, non-orphan instances or modules (but see below) were added to the interface, then A.B MAY remain the same but the new C MUST be greater than the old C. Note that modifying imports or depending on a newer version of another package may cause extra non-orphan instances to be exported and thus force a minor version change.

Migrating from String to Text

Is there a reason why Network.URI is implemented sing String representations instead of Text? I'd like to migrate some types in the rdf4h library to use more of network-uri. We currently use Text extensively in our URI representation. Using the URI validation is something we'd like to adopt, but possibly not at the expense of performance of using Strings. Are there any plans to migrate network-uri from String to Text representations?

network-uri-2.6.0.1 test suite doesn't compile

Preprocessing test suite 'uri' for network-uri-2.6.0.1...

tests/uri001.hs:38:8:
    Could not find module ‘Network.URI’
    It is a member of the hidden package ‘network-uri-2.6.0.1’.
    Perhaps you need to add ‘network-uri’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

URI queries should not include `?`

At least if I'm reading the diagram here right: https://tools.ietf.org/html/rfc3986#section-3

network-uri-2.7.0.0 has no breaking changes versus 2.6.2.0

As noted by in this comment on commercialhaskell/stackage#5116, network-uri-2.7.0.0 was released even though it is strictly additive (ref. this changelog entry.

This is causing quite a bit of churn for packages that have overly-restrictive upper bounds on network-uri (this is magnified versus other libraries since overly-restrictive upper bounds are relatively common thanks to the PVP, and since network-uri is quite a central library within the Haskell ecosystem).

Is there a reason why these changes necessitated a major version bump?

Add Hashable instance.

I see using URI's quite often as HashMap keys, so it seems reasonable to add Hashable instance to URI.

can't parse [] in request parameters

[ and ] should be allowed in request parameters but it seems that they are not.

network-uri 2.6.0.1 test suite failure

Citing from http://hydra.cryp.to/build/185979/nixlog/1/raw:

tests/uri001.hs:38:8:
    Could not find module ‘Network.URI’
    It is a member of the hidden package ‘network-uri-2.6.0.1’.
    Perhaps you need to add ‘network-uri’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Incorrect parsing of URIs without scheme and with port number

Here is a ghci session to demonstrate my point:

> parseURIReference "domain.org/" -- (1)
Just domain.org/
> let Just x = parseURIReference "domain.org:80/" -- (2)
> x
domain.org:80/
> uriAuthority x
Nothing
> uriScheme x
"domain.org:"
> uriPath x
"80/"
> parseURIReference "1domain.org:80/" -- (3)
Nothing
> parseURIReference "http://1domain.org:80/" -- (4)
Just http://1domain.org:80/

Clearly, the parser is trying to interpret everything before the : character as the URI scheme:

case (2) succeeds, but actually interprets domain.org as the scheme, and 80/ as the path;
case (3) fails because the first character of a scheme cannot be a digit.

It seems that the parser has trouble distinguishing between scheme and domain. Is this a known limitation, or a bug ?

Type errors under GHC 9.0 due to the change to Code in Template Haskell.

In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3358, a bunch of types were changed involving TExp and so on. As a result, this package fails to build under GHC 9.0 due to type errors, at least in Network.URI.Static:

Network/URI/Static.hs:59:34: error:
    • Couldn't match type: Language.Haskell.TH.Syntax.Code m1 URI
                     with: Language.Haskell.TH.Syntax.Q
                             (Language.Haskell.TH.Syntax.TExp URI)
      Expected: TExpQ URI
        Actual: Language.Haskell.TH.Syntax.Code m1 URI
    • In the Template Haskell quotation [|| u ||]
      In the expression: [|| u ||]
      In an equation for ‘staticURI’:
          staticURI (parseURI -> Just u) = [|| u ||]
   |
59 | staticURI (parseURI -> Just u) = [|| u ||]
   |                                  ^^^^^^^^^

Network/URI/Static.hs:112:64: error:
    • Couldn't match type: Language.Haskell.TH.Syntax.Code m0 URI
                     with: Language.Haskell.TH.Syntax.Q
                             (Language.Haskell.TH.Syntax.TExp URI)
      Expected: TExpQ URI
        Actual: Language.Haskell.TH.Syntax.Code m0 URI
    • In the Template Haskell quotation [|| ref ||]
      In the expression: [|| ref ||]
      In an equation for ‘staticRelativeReference’:
          staticRelativeReference (parseRelativeReference -> Just ref)
            = [|| ref ||]
    |
112 | staticRelativeReference (parseRelativeReference -> Just ref) = [|| ref ||]
    |                                                                ^^^^^^^^^^^

I made an effort to fix this myself, but I don't understand TH and its panoply of types very well and didn't really get anywhere.

s390x support for network-uri

Trying to upgrade cabal from 1.24.0.2 to 3.2 and the network-uri package build fails with ghc: setNumCapabilities: not supported on this platform. This does seem like a ghc bug so I opened one here and want to track/test this once that's fixed.

[network-uri-2.6.4.1]$ cabal build

Building network-uri-2.6.4.1...
Preprocessing library network-uri-2.6.4.1...
ghc: setNumCapabilities: not supported on this platform
[1 of 3] Compiling Network.URI      ( Network/URI.hs, dist/build/Network/URI.o )

Network/URI.hs:1380:1: error:
    • Can't find interface-file declaration for variable Language.Haskell.TH.Lib.appE
        Probable cause: bug in .hi-boot file, or inconsistent .hi file
        Use -ddump-if-trace to get an idea of which file caused the error
    • In the expression:
        Language.Haskell.TH.Lib.appE
          (Language.Haskell.TH.Lib.appE

`x-partial` warnings with GHC 9.8

The blessings of the new x-partial warning will be bestowed unto you by GHC 9.8:

Network/URI.hs:1131:12: warning: [GHC-63394] [-Wx-partial]
    In the use of ‘head’
    (imported from Prelude, but defined in GHC.List):
    "This is a partial function, it throws an error on empty lists. Use pattern matching or Data.List.uncons instead. Consider refactoring to use Data.List.NonEmpty."
     |
1131 |         if head (uriPath ref) == '/' then
     |            ^^^^

Network/URI.hs:1437:16: warning: [GHC-63394] [-Wx-partial]
    In the use of ‘tail’
    (imported from Prelude, but defined in GHC.List):
    "This is a partial function, it throws an error on empty lists. Replace it with drop 1, or use pattern matching or Data.List.uncons instead. Consider refactoring to use Data.List.NonEmpty."
     |
1437 | query = orNull tail . uriQuery
     |                ^^^^

Network/URI.hs:1441:19: warning: [GHC-63394] [-Wx-partial]
    In the use of ‘tail’
    (imported from Prelude, but defined in GHC.List):
    "This is a partial function, it throws an error on empty lists. Replace it with drop 1, or use pattern matching or Data.List.uncons instead. Consider refactoring to use Data.List.NonEmpty."
     |
1441 | fragment = orNull tail . uriFragment
     |                   ^^^^

These are all false alarms:

network-uri/Network/URI.hs

Lines 1148 to 1149 in 4012e57

    
           | isDefined ( uriPath ref ) = 
        
               if head (uriPath ref) == '/' then

network-uri/Network/URI.hs

Lines 1453 to 1463 in 4012e57

    
           {-# DEPRECATED query "use uriQuery, and note changed functionality" #-} 
        
           query :: URI -> String 
        
           query = orNull tail . uriQuery 
        
           {-# DEPRECATED fragment "use uriFragment, and note changed functionality" #-} 
        
           fragment :: URI -> String 
        
           fragment = orNull tail . uriFragment 
        
           orNull :: ([a]->[a]) -> [a] -> [a] 
        
           orNull _ [] = [] 
        
           orNull f as = f as

	\| isDefined ( uriPath ref ) =
	if head (uriPath ref) == '/' then

	{-# DEPRECATED query "use uriQuery, and note changed functionality" #-}
	query :: URI -> String
	query = orNull tail . uriQuery

	{-# DEPRECATED fragment "use uriFragment, and note changed functionality" #-}
	fragment :: URI -> String
	fragment = orNull tail . uriFragment

	orNull :: ([a]->[a]) -> [a] -> [a]
	orNull _ [] = []
	orNull f as = f as

haskell / network-uri Goto Github PK

network-uri's People

Contributors

Stargazers

Watchers

Forkers

network-uri's Issues

Recommend Projects

Recommend Topics

Recommend Org