You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The FastHTTP client fails to set a default path (/) for request URIs that include only query parameters but no path. This behavior diverges from common web clients (like cURL, Chrome, Firefox) and does not align with the HTTP 1.1 specification.
Expected Behavior
An HTTP GET request for a URI like https://example.com?foo=bar should generate a request header in the format:
GET /?foo=bar
This follows the standard outlined in the HTTP 1.1 spec, section 5.3.1, which states that clients must treat an empty path as /.
Actual Behavior
Currently, FastHTTP generates a header like:
GET ?foo=bar
This can lead to failures with servers that do not default to a path of / when one is not specified.
Suggested Fix
Modify FastHTTP's RequestURI function in http.go to check for an empty path and set it to / if necessary. This ensures compatibility with a wider range of HTTP servers and adherence to the HTTP 1.1 specification.
The text was updated successfully, but these errors were encountered:
Problem Description
The FastHTTP client fails to set a default path (
/
) for request URIs that include only query parameters but no path. This behavior diverges from common web clients (like cURL, Chrome, Firefox) and does not align with the HTTP 1.1 specification.Expected Behavior
An HTTP GET request for a URI like
https://example.com?foo=bar
should generate a request header in the format:This follows the standard outlined in the HTTP 1.1 spec, section 5.3.1, which states that clients must treat an empty path as
/
.Actual Behavior
Currently, FastHTTP generates a header like:
This can lead to failures with servers that do not default to a path of
/
when one is not specified.Suggested Fix
Modify FastHTTP's
RequestURI
function inhttp.go
to check for an empty path and set it to/
if necessary. This ensures compatibility with a wider range of HTTP servers and adherence to the HTTP 1.1 specification.The text was updated successfully, but these errors were encountered: