Handle request URI containing query parameters but no path.

[skidder]

Fixes #1659

When returning a request URI, check whether it begins with a query (i.e. ?), in which case we should apply a default path of /). This is required to conform to the HTTP 1.1 specification.

"If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target."

[erikdubbelboer]

This would cause an allocation, which we always try to avoid in fasthttp. I'm wondering if it isn't better to add the / here when needed:

fasthttp/header.go

Line 2815 in 699af40

h.requestURI = append(h.requestURI[:0], b[:n]...)

[skidder]

Ah, great point. I've updated the change to modify the request URI when set through either the SetRequestURI or SetRequestURIBytes functions.

[erikdubbelboer]

I'm sorry but I don't think SetRequestURI and SetRequestURIBytes need to be fixed. Users have control over these and can append the / themselves.

Your issue was with clients sending a GET ?foo=bar request. In that case this is not going to fix it. You need to fix it here in the request parsing code:

fasthttp/header.go

Line 2815 in 699af40

h.requestURI = append(h.requestURI[:0], b[:n]...)

[skidder]

I'm sorry but I don't think SetRequestURI and SetRequestURIBytes need to be fixed. Users have control over these and can append the / themselves.

Ah, I see. I'm only using the FastHTTP client, not the FastHTTP server. My expectation was that the FastHTTP client would handle URLs using this format since that's the behavior of the built-in net/http client. I've been able to implement a work-around in my application, but thought this might be worth covering in FastHTTP.

[erikdubbelboer]

I'm a little bit afraid to make backwards breaking changes like this. I'll leave this pull request open for now and see if anyone else runs into this.