ignore powerpc failure, unrelated and debugging.

@runcom @thaJeztah ping

LGTM ping @cpuguy83

Thanks! Is is possible to have a test for this?

PowerPC failures are not related

nit: perhaps would be good to have the description of #36516 in the commit-message

It would be good to only implement CloseWrite if the underlying conn does.

Also we should think about removing this, I think?

Codecov Report

❗ No coverage uploaded for pull request base (master@592a15b). Click here to learn what that means.
The diff coverage is 0%.

@@            Coverage Diff            @@
##             master   #36517   +/-   ##
=========================================
  Coverage          ?   35.13%           
=========================================
  Files             ?      613           
  Lines             ?    45639           
  Branches          ?        0           
=========================================
  Hits              ?    16036           
  Misses            ?    27462           
  Partials          ?     2141

Repushed adding a type assertion and improving the commit message. Beyond the type assertion I can't see a straightforward test case for this?

@runcom still LGTY?

Yup!

test-failing is unrelated

Just to note that in a couple of other places we have something like this instead:

and this:

Looking at this, I have two conflicting thoughts:

1. we could use the same technique (i.e. call CloseWrite() if available, otherwise do nothing) for hijackedConn instead of implementing a separate hijackedConnCloseWriter.

2. However, the code quoted above may not work right in this scenario:
   

   moby/api/server/httputils/httputils.go

   Lines 36 to 47 in c3b3be5

   	// CloseStreams ensures that a list for http streams are properly closed.
   	func CloseStreams(streams ...interface{}) {
   	for _, stream := range streams {
   	if tcpc, ok := stream.(interface {
   	CloseWrite() error
   	}); ok {
   	tcpc.CloseWrite()
   	} else if closer, ok := stream.(io.Closer); ok {
   	closer.Close()
   	}
   	}
   	}

So, should we instead change the above two places to a hack similar to the one in this PR?

update: improve wording

@kolyshkin I think so. But we probably don't need as complicated fix. For tlsClientCon it seems that it is only needed if CloseWrite is supported. For HijackedResponse I really do not understand why this method(or Close) is defined at all. Conn is public and all clients can check it directly. I'd just remove it (at least CloseWrite).

We don't need tlsClientConn anymore since go1.8. I'm working on a PR to remove it but having some issues with my unit test hanging trying to setup the hijack.