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

Few notes about fiber adapter #345

Open
x-user opened this issue Mar 30, 2024 · 0 comments
Open

Few notes about fiber adapter #345

x-user opened this issue Mar 30, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@x-user
Copy link
Contributor

x-user commented Mar 30, 2024

If i understand correctly fiberCtx.SetReadDeadline actually doesn't work and probably will not. Also if at same time we will add ability to get client IP address from huma.Context it will not work with current fiber adapter implementation.

Currently fiberAdapter.ServeHTTP calls App.Test to handle requests. This method uses testConn to mock incoming connection.

But testConn.Set*Deadline methods do nothing (source):

func (*testConn) SetDeadline(_ time.Time) error      { return nil }
func (*testConn) SetReadDeadline(_ time.Time) error  { return nil }
func (*testConn) SetWriteDeadline(_ time.Time) error { return nil }

And testConn.*Addr methods return hardcoded values (source):

func (*testConn) LocalAddr() net.Addr                { return &net.TCPAddr{Port: 0, Zone: "", IP: net.IPv4zero} }
func (*testConn) RemoteAddr() net.Addr               { return &net.TCPAddr{Port: 0, Zone: "", IP: net.IPv4zero} }

About using adaptor middleware

Closure returned by adaptor.handlerFunc serves as fiberAdapter.ServeHTTP, it declares fctx variable and initialize it by calling RequestCtx.Init method.

func handlerFunc(app *fiber.App, h ...fiber.Handler) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		// ...
		var fctx fasthttp.RequestCtx
		fctx.Init(req, remoteAddr, nil)

RequestCtx.Init method calls RequestCtx.Init2 passing fakeAddrer struct as net.Conn value without setting underlying net.Conn to anything

func (ctx *RequestCtx) Init(req *Request, remoteAddr net.Addr, logger Logger) {
	// ...
	c := &fakeAddrer{
		laddr: zeroTCPAddr,
		raddr: remoteAddr,
	}
	// ...
	ctx.Init2(c, logger, true)
	// ...
}
// ...
type fakeAddrer struct {
	net.Conn
	laddr net.Addr
	raddr net.Addr
}

RequestCtx.Init2 sets c field to provided net.Conn value

func (ctx *RequestCtx) Init2(conn net.Conn, logger Logger, reduceMemoryUsage bool) {
	ctx.c = conn

RequestCtx.Conn returns it's c property value (fakeAddrer with underlying net.Conn set to nil)

func (ctx *RequestCtx) Conn() net.Conn {
	return ctx.c
}

fakeAddrer doesn't have it's own SetReadDeadline implementation so it calls SetReadDeadline method of it's underlying net.Conn (nil), because of that c.orig.Context().Conn().SetReadDeadline(deadline) in fiberCtx.SetReadDeadline panics.

IMHO: We can simply return nil from fiberCtx.SetReadDeadline without doing anything because it will not work anyway.

@danielgtaylor danielgtaylor added the enhancement New feature or request label Apr 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants