Fiber Example Returns 500 Internal Server Error

[mcblair]

I was having issues after implementing my lambda with the fiber adapter returning 500 from fiberLambda.ProxyWithContext.

So i blew it all away and built the example alone, uploaded it to a brand new function in AWS, and the behavior is exactly the same.

When I dump routes, I don't even see the expected GET that we wire up.

Example: https://github.com/awslabs/aws-lambda-go-api-proxy/blob/bf16974733133c4d9c4cf6778503f60a703ced9b/examples/fiber/main.go

[sophatvathana]

Hi @mcblair, I was having the same issue. There is a missing port in the address https://github.com/awslabs/aws-lambda-go-api-proxy/blob/bf16974733133c4d9c4cf6778503f60a703ced9b/fiber/adapter.go#L132 which make fiber server cannot serve. I've just fixed it by fork and concat the port with r.RemoteAddr. then everything is working fine.

[ruralcoder]

I had the same issue with 0.14, had to revert back to 0.13.3

[pablodz]

Same error here

  ~  curl https://abc.execute-api.us-east-1.amazonaws.com/default/go-app/health
Internal Server Error

Downgrading to 0.13.3 fixed it

[marvin-w]

Can confirm this error, can we get the fix merged here and publish a new release?

[acidjazz]

Hi @mcblair, I was having the same issue. There is a missing port in the address

https://github.com/awslabs/aws-lambda-go-api-proxy/blob/bf16974733133c4d9c4cf6778503f60a703ced9b/fiber/adapter.go#L132

which make fiber server cannot serve. I've just fixed it by fork and concat the port with r.RemoteAddr. then everything is working fine.

Can I see your fork/PR?

[acidjazz]

This issue might be linked to https://github.com/awslabs/aws-lambda-go-api-proxy/issues/175

[marvin-w]

181 will fix this. Until it is released, I'm using.

replace github.com/awslabs/aws-lambda-go-api-proxy => github.com/marvin-w/aws-lambda-go-api-proxy v0.14.1

Feel free to do the same.

[acidjazz]

@mcblair why was this marked closed? i don't see a fix anywhere, last release was in Feb

[k-dahl]

@marvin-w this breaks on IPv6 addresses as there's brackets required there when formatting with a port.

This seems to resolve it:

type IpInfo struct {
    IsIPv4  bool
    IsIPv6  bool
    HasPort bool
}

func IsIPv4(address string) bool {
    return strings.Count(address, ":") < 2
}

func IsIPv6(address string) bool {
    return strings.Count(address, ":") >= 2
}

func IpHasPort(address string) bool {
    return strings.HasSuffix(address, ":80")
}

func GetIpInfo(address string) IpInfo {
    return IpInfo{
        IsIPv4:  IsIPv4(address),
        IsIPv6:  IsIPv6(address),
        HasPort: IpHasPort(address),
    }
}

...

func (f *FiberLambda) adaptor(w http.ResponseWriter, r *http.Request) {
...
    // Get info about IP.
    ipInfo := GetIpInfo(r.RemoteAddr)

    var addrWithPort string

    if ipInfo.IsIPv4 && !ipInfo.HasPort {
        addrWithPort = r.RemoteAddr + ":80" // assuming a default port
    }

    if ipInfo.IsIPv6 && !ipInfo.HasPort {
        addrWithPort = fmt.Sprintf("[%s]%s", r.RemoteAddr, ":80")
    }

    remoteAddr, err := net.ResolveTCPAddr("tcp", addrWithPort)
    if err != nil {
        fmt.Printf("could not resolve TCP address for addr %s\n", r.RemoteAddr)
        log.Println(err)
        http.Error(w, utils.StatusMessage(fiber.StatusInternalServerError), fiber.StatusInternalServerError)
        return
    }
...

The error messages I was seeing were:

too many colons in address

and

could not resolve TCP address for addr

... for whatever reason the r.RemoteAddr never seems to have the port. The check for the colon then finds the colons in the IPv6 address and skips appending it - though even if it did the proper formatting for an IPv6 address with a port is to put the address within brackets like [ffff:ffff:ffff:ffff]:80.

... as long as I don't run into any issues with my 'fix' I will submit a PR in a few days.