Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for proxying to a Unix socket #40

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

thomasjm
Copy link
Contributor

@thomasjm thomasjm commented May 3, 2022

The crux of this PR is adding a new constructor to the ProxyDest type called ProxyDestUnix, and hooking it up to a call to Data.Conduit.Network.Unix.runUnixClient.

Happy to add a test or two if you think this could be mergeable. Thanks!

Copy link
Member

@snoyberg snoyberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm overall OK with it, but proper API design will be needed, as well as fixing the build on Windows

@@ -75,7 +77,12 @@ import UnliftIO (MonadIO, liftIO, MonadUnliftIO,
data ProxyDest = ProxyDest
{ pdHost :: !ByteString
, pdPort :: !Int
} deriving (Read, Show, Eq, Ord, Generic)
}
| ProxyDestUnix {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a fan of this approach, since it creates partial functions as well as breaking existing code that pattern matches. A new data type would be necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, could you clarify what you have in mind? Avoiding a breaking change would seem to require a lot of duplication. For example, where we have

rawTcpProxyTo :: MonadIO m => ProxyDest -> AppData -> m ()

I could create a parallel universe of functions like

rawTcpProxyToUnix :: MonadIO m => ProxyDestUnix -> AppData -> m ()

but that would require duplicating most of public proxying functions as well as WaiProxyResponse...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately I don't have a specific recommendation in mind.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you accept a full breaking change, renaming the data type and bumping the version number?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would lean towards creating a parallel set of functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants