e1091b9c0d
* Put LD_LIBRARY_PATH set back into Linux `nix-shell` ...as we need it for `ghci` workflows inside the shell(s). * Add (failing) test case to check MetadataMap ordering * Remove SortedList value-component from MetadataMap ...which fixes the failing test case introduced by `85a2d13`. This is a potentially breaking change that warrants a library rev bump. I'm not sure what the original reason was for the sorted list component of `MetadataMap` (i.e., header values), but that implementation choice makes it so that determining the "last provided" header value associated with a duplicate key cannot be recovered. That is, it is in violation of this requirement from the [spec](https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md): ``` Custom-Metadata header order is not guaranteed to be preserved except for values with duplicate header names. ``` I'm guessing that the original motivation might have been to ensure that the Eq instance was not sensitive to ordering of values for duplicate keys. I think we can drop the existing `Eq` assumption about order-insensitive values for duplicate keys (there is order sensitivity after all), and if we end up discovering a common use case for an order-insensitive equality on values, we should address that via a utility function (instead via the type's `Eq` instance). So, this commit changes the value component of the `MetadataMap` type to be a list of `ByteString` values instead of `SortedList ByteString`, and removes the `sorted-list` package as a dependency, as it has no other uses in the library. Note that this commit is not claiming we are now spec-compliant w.r.t. header treatment after this change. In particular (and at least), 1. We do not yet support base64-encoded binary data via the special `-bin` key suffix. 2. As far as I am aware, we do not (yet) interpret comma-separated header values the same as duplicate header keys for each of those values. 3. As far as I am aware, we do not (yet) do any validation of header names nor whitespace handling as per the request grammar from the spec. * Extend Arbitrary MetadataMap to explicitly encode key duplication Duplicate keys were allowed by the previous implementation, but this commit makes key duplication more explicit and more frequent. * Add metadata map ordering QC prop * Drop qualified use of @?= since it's so common in this module * Extend checkMetadataOrdering to check instance Eq MetadataMap ...and use the appropriate bracketing wrapper. * Relocate MetadataMap type to its own module * Add some helper functions for MetadataMap lookup; documentation * Extend testMetadataOrdering w/ use of lookup{All,Last} * Bump grpc-haskell{,-core} -> 0.2.0 |
||
|---|---|---|
| .github/workflows | ||
| bench | ||
| bin | ||
| core | ||
| examples | ||
| nix | ||
| src/Network/GRPC | ||
| tests | ||
| .gitignore | ||
| LICENSE | ||
| README.md | ||
| Setup.hs | ||
| default.nix | ||
| grpc-haskell.cabal | ||
| nixpkgs.nix | ||
| release.nix | ||
| shell.nix | ||
| stack.yaml | ||
README.md
Attribution
This library is a fork of https://github.com/aloiscochard/grpc-haskell that we
have extended and released under the same LICENSE
Installation
The current version of this library requires gRPC version 1.34.1. Newer versions may work but have not been tested.
Usage
There is a tutorial here
Building and testing
nix-build release.nix -A grpc-haskell will build and test the whole thing and
put the completed package into the nix store. nix-shell can be used to give
you a development environment where you can use cabal for development and
testing:
$ nix-shell
[nix-shell]$ cabal configure --enable-tests && cabal build && cabal test
Using the Library
You must compile with -threaded, because we rely on being able to execute
Haskell while blocking on foreign calls to the gRPC library. If not using code
generation, the recommended place to start is in the
Network.GRPC.HighLevel.Server.Unregistered module, where serverLoop provides
a handler loop.