grpc-haskell{-core} -> 0.2.0: Fix MetadataMap duplicate-key ordering (#132)
* 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
2021-07-01 03:32:33 +02:00
|
|
|
{-# LANGUAGE OverloadedStrings #-}
|
|
|
|
{-# LANGUAGE TypeApplications #-}
|
2016-08-01 21:38:35 +02:00
|
|
|
{-# LANGUAGE ScopedTypeVariables #-}
|
2017-03-16 18:42:51 +01:00
|
|
|
{-# OPTIONS_GHC -fno-warn-orphans #-}
|
2016-05-24 23:27:15 +02:00
|
|
|
|
2016-08-01 21:38:35 +02:00
|
|
|
module UnsafeTests (unsafeTests, unsafeProperties) where
|
2016-05-24 23:27:15 +02:00
|
|
|
|
grpc-haskell{-core} -> 0.2.0: Fix MetadataMap duplicate-key ordering (#132)
* 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
2021-07-01 03:32:33 +02:00
|
|
|
import Control.Exception (bracket_)
|
|
|
|
import Control.Monad
|
|
|
|
import qualified Data.ByteString as B
|
|
|
|
import qualified Data.Map as M
|
|
|
|
import Data.List.NonEmpty (NonEmpty((:|)))
|
|
|
|
import Foreign.Marshal.Alloc
|
|
|
|
import Foreign.Storable
|
|
|
|
import GHC.Exts
|
|
|
|
import Network.GRPC.LowLevel.GRPC (MetadataMap (..), threadDelaySecs)
|
|
|
|
import qualified Network.GRPC.LowLevel.GRPC.MetadataMap as MD
|
|
|
|
import Network.GRPC.Unsafe
|
|
|
|
import Network.GRPC.Unsafe.ByteBuffer
|
|
|
|
import Network.GRPC.Unsafe.ChannelArgs
|
|
|
|
import Network.GRPC.Unsafe.Metadata
|
|
|
|
import Network.GRPC.Unsafe.Security
|
|
|
|
import Network.GRPC.Unsafe.Slice
|
|
|
|
import Network.GRPC.Unsafe.Time
|
|
|
|
import System.Clock
|
|
|
|
import Test.QuickCheck.Gen
|
|
|
|
import Test.Tasty
|
|
|
|
import Test.Tasty.HUnit as HU (Assertion, testCase, (@?=))
|
|
|
|
import Test.Tasty.QuickCheck as QC
|
2016-05-24 23:27:15 +02:00
|
|
|
|
|
|
|
unsafeTests :: TestTree
|
2016-05-25 19:04:48 +02:00
|
|
|
unsafeTests = testGroup "Unit tests for unsafe C bindings"
|
2016-08-17 18:54:46 +02:00
|
|
|
[ roundtripSliceUnit "\NULabc\NUL"
|
|
|
|
, roundtripSliceUnit largeByteString
|
|
|
|
, roundtripByteBufferUnit largeByteString
|
2016-07-11 20:20:13 +02:00
|
|
|
, roundtripTimeSpec (TimeSpec 123 123)
|
2016-05-24 23:27:15 +02:00
|
|
|
, testMetadata
|
grpc-haskell{-core} -> 0.2.0: Fix MetadataMap duplicate-key ordering (#132)
* 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
2021-07-01 03:32:33 +02:00
|
|
|
, testMetadataOrdering
|
|
|
|
, testMetadataOrderingProp
|
2016-05-24 23:27:15 +02:00
|
|
|
, testNow
|
|
|
|
, testCreateDestroyMetadata
|
|
|
|
, testCreateDestroyMetadataKeyVals
|
|
|
|
, testCreateDestroyDeadline
|
2016-06-22 22:07:38 +02:00
|
|
|
, testCreateDestroyChannelArgs
|
2016-08-17 18:55:06 +02:00
|
|
|
, testCreateDestroyClientCreds
|
|
|
|
, testCreateDestroyServerCreds
|
2016-05-24 23:27:15 +02:00
|
|
|
]
|
|
|
|
|
2016-08-01 21:38:35 +02:00
|
|
|
unsafeProperties :: TestTree
|
|
|
|
unsafeProperties = testGroup "QuickCheck properties for unsafe C bindings"
|
2016-08-17 18:54:46 +02:00
|
|
|
[ roundtripSliceQC
|
|
|
|
, roundtripByteBufferQC
|
|
|
|
, roundtripMetadataQC
|
|
|
|
, metadataIsList
|
grpc-haskell{-core} -> 0.2.0: Fix MetadataMap duplicate-key ordering (#132)
* 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
2021-07-01 03:32:33 +02:00
|
|
|
, roundtripMetadataOrdering
|
2016-08-17 18:54:46 +02:00
|
|
|
]
|
2016-08-01 21:38:35 +02:00
|
|
|
|
|
|
|
instance Arbitrary B.ByteString where
|
|
|
|
arbitrary = B.pack <$> arbitrary
|
|
|
|
|
|
|
|
instance Arbitrary MetadataMap where
|
2016-08-17 18:54:46 +02:00
|
|
|
arbitrary = do
|
grpc-haskell{-core} -> 0.2.0: Fix MetadataMap duplicate-key ordering (#132)
* 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
2021-07-01 03:32:33 +02:00
|
|
|
-- keys are not allowed to contain \NUL, but values are.
|
|
|
|
let key = arbitrary `suchThat` B.notElem 0
|
|
|
|
ks0 <- listOf key
|
|
|
|
duplicateKeys <- arbitrary
|
|
|
|
ks <- if duplicateKeys
|
|
|
|
then (ks0 <>) . concat . replicate 2 <$> listOf1 key
|
|
|
|
else pure ks0
|
|
|
|
fromList . zip ks <$> vector (length ks)
|
2016-08-17 18:54:46 +02:00
|
|
|
|
|
|
|
roundtripMetadataKeyVals :: MetadataMap -> IO MetadataMap
|
|
|
|
roundtripMetadataKeyVals m = do
|
2016-08-17 23:12:22 +02:00
|
|
|
(kvPtr, l) <- createMetadata m
|
|
|
|
m' <- getAllMetadata kvPtr l
|
2016-08-17 18:54:46 +02:00
|
|
|
metadataFree kvPtr
|
|
|
|
return m'
|
|
|
|
|
|
|
|
roundtripMetadataQC :: TestTree
|
|
|
|
roundtripMetadataQC = QC.testProperty "Metadata roundtrip" $
|
|
|
|
\m -> QC.ioProperty $ do m' <- roundtripMetadataKeyVals m
|
|
|
|
return $ m === m'
|
2016-08-01 21:38:35 +02:00
|
|
|
|
|
|
|
metadataIsList :: TestTree
|
|
|
|
metadataIsList = QC.testProperty "Metadata IsList instance" $
|
|
|
|
\(md :: MetadataMap) -> md == (fromList $ toList md)
|
|
|
|
|
grpc-haskell{-core} -> 0.2.0: Fix MetadataMap duplicate-key ordering (#132)
* 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
2021-07-01 03:32:33 +02:00
|
|
|
roundtripMetadataOrdering :: TestTree
|
|
|
|
roundtripMetadataOrdering = QC.testProperty "Metadata map ordering" $
|
|
|
|
QC.ioProperty . checkMetadataOrdering
|
|
|
|
|
2016-06-22 22:07:38 +02:00
|
|
|
largeByteString :: B.ByteString
|
|
|
|
largeByteString = B.pack $ take (32*1024*1024) $ cycle [97..99]
|
|
|
|
|
2016-08-17 18:54:46 +02:00
|
|
|
roundtripSlice :: B.ByteString -> IO B.ByteString
|
|
|
|
roundtripSlice bs = do
|
2016-05-24 23:27:15 +02:00
|
|
|
slice <- byteStringToSlice bs
|
|
|
|
unslice <- sliceToByteString slice
|
|
|
|
freeSlice slice
|
2016-08-17 18:54:46 +02:00
|
|
|
return unslice
|
|
|
|
|
|
|
|
roundtripSliceQC :: TestTree
|
|
|
|
roundtripSliceQC = QC.testProperty "Slice roundtrip: QuickCheck" $
|
|
|
|
\bs -> QC.ioProperty $ do bs' <- roundtripSlice bs
|
|
|
|
return $ bs == bs'
|
2016-05-24 23:27:15 +02:00
|
|
|
|
2016-08-17 18:54:46 +02:00
|
|
|
roundtripSliceUnit :: B.ByteString -> TestTree
|
|
|
|
roundtripSliceUnit bs = testCase "ByteString slice roundtrip" $ do
|
|
|
|
unslice <- roundtripSlice bs
|
grpc-haskell{-core} -> 0.2.0: Fix MetadataMap duplicate-key ordering (#132)
* 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
2021-07-01 03:32:33 +02:00
|
|
|
unslice @?= bs
|
2016-08-17 18:54:46 +02:00
|
|
|
|
|
|
|
roundtripByteBuffer :: B.ByteString -> IO B.ByteString
|
|
|
|
roundtripByteBuffer bs = do
|
2016-05-24 23:27:15 +02:00
|
|
|
slice <- byteStringToSlice bs
|
|
|
|
buffer <- grpcRawByteBufferCreate slice 1
|
|
|
|
reader <- byteBufferReaderCreate buffer
|
|
|
|
readSlice <- grpcByteBufferReaderReadall reader
|
|
|
|
bs' <- sliceToByteString readSlice
|
|
|
|
freeSlice slice
|
|
|
|
byteBufferReaderDestroy reader
|
|
|
|
grpcByteBufferDestroy buffer
|
|
|
|
freeSlice readSlice
|
2016-08-17 18:54:46 +02:00
|
|
|
return bs'
|
|
|
|
|
|
|
|
roundtripByteBufferQC :: TestTree
|
|
|
|
roundtripByteBufferQC = QC.testProperty "ByteBuffer roundtrip: QuickCheck" $
|
|
|
|
\bs -> QC.ioProperty $ do bs' <- roundtripByteBuffer bs
|
|
|
|
return $ bs == bs'
|
|
|
|
|
|
|
|
roundtripByteBufferUnit :: B.ByteString -> TestTree
|
|
|
|
roundtripByteBufferUnit bs = testCase "ByteBuffer roundtrip" $ do
|
|
|
|
bs' <- roundtripByteBuffer bs
|
grpc-haskell{-core} -> 0.2.0: Fix MetadataMap duplicate-key ordering (#132)
* 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
2021-07-01 03:32:33 +02:00
|
|
|
bs' @?= bs
|
2016-05-24 23:27:15 +02:00
|
|
|
|
2016-07-11 20:20:13 +02:00
|
|
|
roundtripTimeSpec :: TimeSpec -> TestTree
|
|
|
|
roundtripTimeSpec t = testCase "CTimeSpec roundtrip" $ do
|
|
|
|
p <- malloc
|
|
|
|
let c = CTimeSpec t
|
|
|
|
poke p c
|
|
|
|
c' <- peek p
|
|
|
|
c' @?= c
|
|
|
|
free p
|
|
|
|
|
2016-05-24 23:27:15 +02:00
|
|
|
testMetadata :: TestTree
|
2016-05-25 19:04:48 +02:00
|
|
|
testMetadata = testCase "Metadata setter/getter roundtrip" $ do
|
2016-05-24 23:27:15 +02:00
|
|
|
m <- metadataAlloc 3
|
|
|
|
setMetadataKeyVal "hello" "world" m 0
|
|
|
|
setMetadataKeyVal "foo" "bar" m 1
|
|
|
|
setMetadataKeyVal "Haskell" "Curry" m 2
|
|
|
|
k0 <- getMetadataKey m 0
|
|
|
|
v0 <- getMetadataVal m 0
|
|
|
|
k1 <- getMetadataKey m 1
|
|
|
|
v1 <- getMetadataVal m 1
|
|
|
|
k2 <- getMetadataKey m 2
|
|
|
|
v2 <- getMetadataVal m 2
|
grpc-haskell{-core} -> 0.2.0: Fix MetadataMap duplicate-key ordering (#132)
* 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
2021-07-01 03:32:33 +02:00
|
|
|
k0 @?= "hello"
|
|
|
|
v0 @?= "world"
|
|
|
|
k1 @?= "foo"
|
|
|
|
v1 @?= "bar"
|
|
|
|
k2 @?= "Haskell"
|
|
|
|
v2 @?= "Curry"
|
2016-05-24 23:27:15 +02:00
|
|
|
metadataFree m
|
|
|
|
|
grpc-haskell{-core} -> 0.2.0: Fix MetadataMap duplicate-key ordering (#132)
* 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
2021-07-01 03:32:33 +02:00
|
|
|
testMetadataOrdering :: TestTree
|
|
|
|
testMetadataOrdering = testCase "Metadata map ordering (simple)" $ do
|
|
|
|
let m0 = fromList @MetadataMap [("foo", "bar"), ("fnord", "FNORD")]
|
|
|
|
let m1 = fromList @MetadataMap [("foo", "baz")]
|
|
|
|
let lr = m0 <> m1
|
|
|
|
let rl = m1 <> m0
|
|
|
|
M.lookup "foo" (unMap lr) @?= Just ["bar", "baz"]
|
|
|
|
M.lookup "foo" (unMap rl) @?= Just ["baz", "bar"]
|
|
|
|
toList lr @?= [("fnord", "FNORD"), ("foo", "bar"), ("foo", "baz")]
|
|
|
|
toList rl @?= [("fnord", "FNORD"), ("foo", "baz"), ("foo", "bar")]
|
|
|
|
M.lookup "foo" (unMap (lr <> rl)) @?= Just ["bar", "baz", "baz", "bar"]
|
|
|
|
MD.lookupAll "foo" lr @?= Just ("bar" :| ["baz"])
|
|
|
|
MD.lookupLast "foo" lr @?= Just "baz"
|
|
|
|
MD.lookupAll "foo" rl @?= Just ("baz" :| ["bar"])
|
|
|
|
MD.lookupLast "foo" rl @?= Just "bar"
|
|
|
|
|
|
|
|
testMetadataOrderingProp :: TestTree
|
|
|
|
testMetadataOrderingProp = testCase "Metadata map ordering prop w/ trivial inputs" $
|
|
|
|
mapM_ (checkMetadataOrdering . fromList)
|
|
|
|
[ [("foo", "bar"), ("fnord", "FNORD"), ("foo", "baz")]
|
|
|
|
, [("foo", "baz"), ("fnord", "FNORD"), ("foo", "bar")]
|
|
|
|
]
|
|
|
|
|
|
|
|
checkMetadataOrdering :: MetadataMap -> Assertion
|
|
|
|
checkMetadataOrdering md0 = do
|
|
|
|
let ikvps = toList md0 `zip` [0..]
|
|
|
|
let ok md = unMap md @?= M.unionsWith (<>) [M.singleton k [v] | ((k, v), _i) <- ikvps]
|
|
|
|
ok md0
|
|
|
|
md1 <- do
|
|
|
|
let n = length ikvps
|
|
|
|
withMetadataKeyValPtr n $ \m -> do
|
|
|
|
let deref i = (,) <$> getMetadataKey m i <*> getMetadataVal m i
|
|
|
|
mapM_ (\((k, v), i) -> setMetadataKeyVal k v m i) ikvps
|
|
|
|
mapM_ (\(kvp, i) -> deref i >>= (@?= kvp)) ikvps
|
|
|
|
getAllMetadata m n
|
|
|
|
ok md1
|
|
|
|
-- Check Eq instance
|
|
|
|
mapM_ (uncurry (@?=)) [(x, y) | x <- [md0, md1], y <- [md0, md1]]
|
|
|
|
|
2016-05-24 23:27:15 +02:00
|
|
|
currTimeMillis :: ClockType -> IO Int
|
|
|
|
currTimeMillis t = do
|
|
|
|
gprT <- gprNow t
|
|
|
|
tMillis <- gprTimeToMillis gprT
|
|
|
|
timespecDestroy gprT
|
|
|
|
return tMillis
|
|
|
|
|
|
|
|
testNow :: TestTree
|
2016-05-25 19:04:48 +02:00
|
|
|
testNow = testCase "Create/destroy various clock types" $ do
|
2016-05-24 23:27:15 +02:00
|
|
|
_ <- currTimeMillis GprClockMonotonic
|
|
|
|
_ <- currTimeMillis GprClockRealtime
|
|
|
|
_ <- currTimeMillis GprClockPrecise
|
|
|
|
return ()
|
|
|
|
|
|
|
|
testCreateDestroyMetadata :: TestTree
|
2016-05-25 19:04:48 +02:00
|
|
|
testCreateDestroyMetadata = testCase "Create/destroy metadataArrayPtr" $ do
|
2016-05-26 00:41:37 +02:00
|
|
|
grpc $ withMetadataArrayPtr $ const $ return ()
|
2016-05-24 23:27:15 +02:00
|
|
|
|
|
|
|
testCreateDestroyMetadataKeyVals :: TestTree
|
2016-05-25 19:04:48 +02:00
|
|
|
testCreateDestroyMetadataKeyVals = testCase "Create/destroy metadata key/values" $ do
|
2016-05-26 00:41:37 +02:00
|
|
|
grpc $ withMetadataKeyValPtr 10 $ const $ return ()
|
2016-05-24 23:27:15 +02:00
|
|
|
|
|
|
|
testCreateDestroyDeadline :: TestTree
|
2016-05-25 19:04:48 +02:00
|
|
|
testCreateDestroyDeadline = testCase "Create/destroy deadline" $ do
|
2016-05-26 00:41:37 +02:00
|
|
|
grpc $ withDeadlineSeconds 10 $ const $ return ()
|
|
|
|
|
2016-06-22 22:07:38 +02:00
|
|
|
testCreateDestroyChannelArgs :: TestTree
|
|
|
|
testCreateDestroyChannelArgs = testCase "Create/destroy channel args" $
|
|
|
|
grpc $ withChannelArgs [CompressionAlgArg GrpcCompressDeflate] $
|
|
|
|
const $ return ()
|
|
|
|
|
2016-08-17 18:55:06 +02:00
|
|
|
testCreateDestroyClientCreds :: TestTree
|
|
|
|
testCreateDestroyClientCreds = testCase "Create/destroy client credentials" $
|
|
|
|
grpc $ withChannelCredentials Nothing Nothing Nothing $ const $ return ()
|
|
|
|
|
|
|
|
testCreateDestroyServerCreds :: TestTree
|
|
|
|
testCreateDestroyServerCreds = testCase "Create/destroy server credentials" $
|
|
|
|
grpc $ withServerCredentials Nothing
|
|
|
|
"tests/ssl/testServerKey.pem"
|
|
|
|
"tests/ssl/testServerCert.pem"
|
|
|
|
SslDontRequestClientCertificate
|
|
|
|
$ const $ return ()
|
|
|
|
|
2016-05-26 00:41:37 +02:00
|
|
|
assertCqEventComplete :: Event -> IO ()
|
|
|
|
assertCqEventComplete e = do
|
grpc-haskell{-core} -> 0.2.0: Fix MetadataMap duplicate-key ordering (#132)
* 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
2021-07-01 03:32:33 +02:00
|
|
|
eventCompletionType e @?= OpComplete
|
|
|
|
eventSuccess e @?= True
|
2016-05-26 00:41:37 +02:00
|
|
|
|
|
|
|
grpc :: IO a -> IO ()
|
2019-08-22 18:12:21 +02:00
|
|
|
grpc = bracket_ grpcInit grpcShutdownBlocking . void
|
2016-07-11 20:20:13 +02:00
|
|
|
|
2016-07-27 00:21:35 +02:00
|
|
|
_nowarnUnused :: a
|
|
|
|
_nowarnUnused = assertCqEventComplete `undefined` threadDelaySecs
|