Skip to content

Conversation

@bruegth
Copy link

@bruegth bruegth commented Oct 4, 2025

Project changes:

  • splits httpHandler into different sub projects
  • adds NativeHttpHandler

API changes:

  • remove namedPipeConnectTimeout from config and hardcoded to 10s instead of 100ms

Test changes:

  • modify TestFixture to support dind and different clients
  • add dind for tls client tests to ci
  • add parallel test
  • add speed test
  • check for com.docker.service in Docker_IsRunning too (DockerDesktop for Windows)
  • add 1s sleep in MonitorEventsFiltered_Succeeds test

FollowUp:

  • investigate why parallel test for managed/legacy http handler fails when using TLS

add native http handler
add WriteClosableStreamWrapper for native http handler
move WriteClosableStream into base namespace
add HijackStreamHelper for reflection (conflict with System member)
remove namedPipeConnectTimeout from config and hardcoded to 10s instead of 100ms
modify TestFixture to support dind and different clients
add dind for tls client tests to ci
add parallel test
add speed test
check for com.docker.service in Docker_IsRunning too
add 1s sleep in MonitorEventsFiltered_Succeeds test
@bruegth bruegth changed the title Draft: Split handler feat: Split http handler into sub projects Oct 10, 2025
@bruegth
Copy link
Author

bruegth commented Jan 20, 2026

@HofmeisterAn Can you please review this PR too? Otherwise feel free to close this PR.

I'm using this for some months for now and no errors found.

Splitting handler into different packages make sense in my opinion.

With legacy custom http handler implementation, I'm still facing memory and CPU problems, so I will keep using my fork, because for me this is critical.

@HofmeisterAn
Copy link
Collaborator

HofmeisterAn commented Jan 20, 2026

Thanks for the heads-up. I haven't forgotten the PR. I started it but didn't finish because other things kept coming up, and it's a pretty big PR. I'll try to review it in the next few days. Sorry about that.

Splitting handler into different packages make sense in my opinion.

I agree 👍.

@bruegth
Copy link
Author

bruegth commented Jan 20, 2026

Thanks for the heads-up. I haven't forgotten the PR. I started it but didn't finish because other things kept coming up, and it's a pretty big PR. I'll try to review it in the next few days. Sorry about that.

No worries, take your time.

I'm happy that you maintain this project. 👍🏻

Copy link
Collaborator

@HofmeisterAn HofmeisterAn left a comment

Choose a reason for hiding this comment

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

I think I can share the first part already. It would be great if we could reduce the copied classes by using a shared project or directory. This would make the review easier and help me see which classes were simply moved. Then I can continue with the actual content.

bruegth and others added 10 commits January 23, 2026 07:34
Co-authored-by: Andre Hofmeister <9199345+HofmeisterAn@users.noreply.github.com>
Co-authored-by: Andre Hofmeister <9199345+HofmeisterAn@users.noreply.github.com>
Co-authored-by: Andre Hofmeister <9199345+HofmeisterAn@users.noreply.github.com>
Co-authored-by: Andre Hofmeister <9199345+HofmeisterAn@users.noreply.github.com>
Co-authored-by: Andre Hofmeister <9199345+HofmeisterAn@users.noreply.github.com>
…gth/TestContainers.Docker.DotNet into split-handler
@HofmeisterAn
Copy link
Collaborator

@bruegth Thanks for taking care of the suggestions so quickly. I'll review the remaining parts on Sunday when my family is out.

@bruegth
Copy link
Author

bruegth commented Jan 26, 2026

TODOs:

  • Revert test changes
  • Change Readme (new env "DOCKER_DOTNET_USE_NATIVE_HTTP") + changes for packages)

Copy link
Collaborator

@HofmeisterAn HofmeisterAn left a comment

Choose a reason for hiding this comment

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

I think the sources look good. I have a few more questions, and could you please review the recent changes to see if they are OK for you? I will update the tests sometime over the weekend.

Comment on lines +30 to +33
nativeHandler.UseProxy = true;
nativeHandler.AllowAutoRedirect = true;
nativeHandler.MaxAutomaticRedirections = 20;
nativeHandler.Proxy = WebRequest.DefaultWebProxy;
Copy link
Collaborator

Choose a reason for hiding this comment

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

question: Do we need the proxy configuration? I'm not sure if this is compatible with the already existing proxy "configurations":

  • DetermineProxyModeAndAddressLine(HttpRequestMessage)
  • TunnelThroughProxyAsync(HttpRequestMessage, Stream, CancellationToken)

I think we should move this to a separate PR (and make sure it is aligned with the exiting parts).

Copy link
Author

Choose a reason for hiding this comment

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

yes new PR for that will be good.

Also I think the default OS proxy settings also should be overwritten by some new configs in future.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Okay, then we need to clean this up (also remove reflection).

@bruegth
Copy link
Author

bruegth commented Jan 29, 2026

I think the sources look good. I have a few more questions, and could you please review the recent changes to see if they are OK for you? I will update the tests sometime over the weekend.

Sure it's okay for me. Your fine-tuning looks good and makes sense.

@@ -0,0 +1,18 @@
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<AssemblyName>Docker.DotNet.Handler.Abstractions</AssemblyName>
Copy link
Author

@bruegth bruegth Jan 29, 2026

Choose a reason for hiding this comment

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

Was the intention of new .Handler. package hierarchy to use it into e.g. npipe too?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not sure if I understood the question correctly. There will likely be more implementations in the future, for example for SSH or gRPC. My idea was to put everything into the handler project that these implementations need to fulfill.

@HofmeisterAn
Copy link
Collaborator

I think we're almost done. Most tests passed, only 3/4 fail for the native implementation, which we need to check.

Copy link
Collaborator

@HofmeisterAn HofmeisterAn left a comment

Choose a reason for hiding this comment

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

Looks pretty good. Almost done I think.

Comment on lines +30 to +33
nativeHandler.UseProxy = true;
nativeHandler.AllowAutoRedirect = true;
nativeHandler.MaxAutomaticRedirections = 20;
nativeHandler.Proxy = WebRequest.DefaultWebProxy;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Okay, then we need to clean this up (also remove reflection).

Copy link
Collaborator

Choose a reason for hiding this comment

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

We need to update the README once more.

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