Which struct could be used to replace net.http.httputil.ServerConn

Getting Help
1

With same port, my server not only for http, but also for tcp.

So I used function func NewServerConn(c net.Conn, r *bufio.Reader) *ServerConn to create httputil.ServerCoon by net.Conn

but as doc:

type ServerConn
ServerConn is an artifact of Go's early HTTP implementation. It is low-level, old, and unused by Go's current HTTP stack. We should have deleted it before Go 1.

Deprecated: Use the Server in package net/http instead.

I don’t know which struct could be used to replace httputil.ServerConn.
What can I do?

Thanks

2

Take a look at the net package if you want to do raw TCP.

1 Like
3

This is unclear. What is it you want to do? Speak HTTP and also something else on the same port, depending on something?

1 Like
4

yes,
with same port, my server can receive http request, and client also can send request by telnet to the port.

following is my code:

//if the connection is for http, will get httputil.ServerConn
sc := httputil.NewServerConn(conn, buf)

the httputil.ServerConn is good for me, but it is Deprecated, and I can not find the replacement

5

So today you have something that accepts a connection, determines somehow if it’s a telnet or HTTP connection, and passes it to either httputil.NewServerConn or something else? First of all, if this works, go with it. ServerConn may be deprecated, but it has to be around “forever” due to the compatibility promise. It may not be the most beautiful thing to depend on, but honestly this thing is a bit of a hack to begin with anyway.

The other way to do it would be to wire up a custom net.Listener. One could imagine one where Accept() just wraps another (real) listeners Accept, and if the socket is supposed to become a telnet socket send it on a channel and Accept() again instead of returning. When the socket should become a HTTP socket, return it as usual to the http.Server that called Accept().

You could also make a net.Listener where you can register patterns of some kind and get back another listener that only returns sockets matching. You then split your listener into one that returns HTTP sockets and give that to a http.Server, and another listener that you give to your telnet loop.

If you need to read from the connections to determine what they are, you’ll need to wrap the connections in something when passing them on so the next thing to read from them also gets the initial bytes.

6

Thanks

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.