Skip to content

Add http client and server implementation#16

Merged
fristonio merged 4 commits intomainfrom
pr/fristonio/http-client-server
Nov 24, 2025
Merged

Add http client and server implementation#16
fristonio merged 4 commits intomainfrom
pr/fristonio/http-client-server

Conversation

@fristonio
Copy link
Copy Markdown
Member

@fristonio fristonio commented Oct 13, 2025

  • Add a new optional flag for client and server commands to specify the protocol - --protocol. Defaults to tcp to keep existing command behavior.
  • Separate out client and server implementation from main command to package per protocol.
  • Add http client and server protocol implementation.

Required for extending cilium cli connection disruption connectivity tests for L7 policy.

Test Docker Image: docker.io/fristonio/test-connection-disruption:v0.0.17
Cilium PR: cilium/cilium#42150
CI validation: https://github.com/cilium/cilium/actions/runs/18918259228

Copy link
Copy Markdown
Contributor

@ti-mo ti-mo left a comment

Choose a reason for hiding this comment

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

Looks good! Please split the move into package tcp into a separate commit to keep the Git history clean and ease reviewing.

internal.ErrExit("http server shutdown", server.Shutdown(waitCtx))
}()

common.MarkServerReady()
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm not 100% sure what these are used for (k8s ready check?), but technically this marks the server ready before the listening socket has been opened, and given sufficient sample size and noisy neighbours in CI this could become a tricky problem to debug.

We could reimplement ListenAndServe to call MarkServerReady() between net.Listen() and server.Serve(). We'd need to verify whether net.Listen() is enough to let the client connect and send its http request; hopefully the socket would buffer the request until server.Serve() is called. I'm not familiar enough with the http package to know for sure.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I'm not 100% sure what these are used for (k8s ready check?), but technically this marks the server ready before the listening socket has been opened, and given sufficient sample size and noisy neighbours in CI this could become a tricky problem to debug.

Yes, its used in k8s readiness checks.
Thats's a good point. I have made the required changes.

We could reimplement ListenAndServe to call MarkServerReady() between net.Listen() and server.Serve(). We'd need to verify whether net.Listen() is enough to let the client connect and send its http request; hopefully the socket would buffer the request until server.Serve() is called. I'm not familiar enough with the http package to know for sure.

Yes, validated that server will buffer the requests until it starts serving.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

On a side note, there is another issue with how we are using signal context in the client implementations.
Client won't react to an OS signal if its slepping(we have some os specific sleeps where we don't take context into account), so reaction to context cancellation will be delayed by the max request interval.
If it sounds relevant, I can do another round of cleanup in a follow up PR.

Signed-off-by: Deepesh Pathak <deepesh.pathak@isovalent.com>
Signed-off-by: Deepesh Pathak <deepesh.pathak@isovalent.com>
* Update go module version to 1.25.x to match Dockerfile base image
  version.

Signed-off-by: Deepesh Pathak <deepesh.pathak@isovalent.com>
@fristonio fristonio force-pushed the pr/fristonio/http-client-server branch from 8aff06c to 49bc8ee Compare November 13, 2025 22:26
@fristonio fristonio requested a review from ti-mo November 19, 2025 20:44
Copy link
Copy Markdown
Contributor

@ti-mo ti-mo left a comment

Choose a reason for hiding this comment

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

Looks good! Does the client use the websocket echo feature of the server?

Signed-off-by: Deepesh Pathak <deepesh.pathak@isovalent.com>
Signed-off-by: Deepesh Pathak <deepeshpathak09@gmail.com>
@fristonio fristonio force-pushed the pr/fristonio/http-client-server branch from 49bc8ee to 0c473ff Compare November 24, 2025 17:50
@fristonio
Copy link
Copy Markdown
Member Author

Looks good! Does the client use the websocket echo feature of the server?

No, not yet. I will add websocket support in a follow up PR, removed the dead code for now.

@fristonio fristonio merged commit fa57b71 into main Nov 24, 2025
@ti-mo ti-mo deleted the pr/fristonio/http-client-server branch November 25, 2025 09:10
@ti-mo
Copy link
Copy Markdown
Contributor

ti-mo commented Nov 25, 2025

Looks good! Does the client use the websocket echo feature of the server?

No, not yet. I will add websocket support in a follow up PR, removed the dead code for now.

Oh, makes sense, thanks!

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.

2 participants