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
{{ message }}
Repository navigation
http: Using URL with http.request (feature suggestion) #20795
Using URL objects is clearly the way to go when it comes to dealing with URLs, and http.request() can take a URL object as input. This is great. But if I want to also send custom headers, I'm stuck. I would like to suggest an option for the options object called url that can be set to URL object and maybe even a string. I don't really want to make an already complex API more complex, but I'm not sure how else we can make it easier to use URL objects with HTTP requests.
Feedback, suggestions, thoughts from @nodejs/collaborators very welcome.
Can you provide some sample code showing the way you would like to be able to write calls to http.request() using this feature? Perhaps with either additional code showing how it has to be done currently?
@benjamingr Yeah, I think the takeaway there is that the URL is basically expected to be (or is cast to) a string, and URL.prototype.toString will do the trick for URL objects. I think that behavior (strings and URL objects) makes sense for us too.
Activity
Trott commentedon May 17, 2018
Can you provide some sample code showing the way you would like to be able to write calls to
http.request()using this feature? Perhaps with either additional code showing how it has to be done currently?bnoordhuis commentedon May 17, 2018
Seems like a reasonable feature to me but what takes precedence when both
.pathand.urlare present? Why?Alternative: overload
http.request()with a 3-arghttp.request(url[, options, callback]).mcollina commentedon May 17, 2018
I'm 👍 for a 3-arg signature.
ronkorving commentedon May 17, 2018
@Trott I was suggesting:
@bnoordhuis Good question, and I think your suggestion for 3-arg is a good alternative that makes the precedence very clear (the URL wins, right? :)).
joyeecheung commentedon May 17, 2018
Fun fact: in
fs.createReadStream(path[, options]), whenoptions.fdis specified,pathgets ignored.benjamingr commentedon May 17, 2018
Slightly related whatwg/fetch#452
ronkorving commentedon May 18, 2018
@benjamingr Yeah, I think the takeaway there is that the URL is basically expected to be (or is cast to) a string, and
URL.prototype.toStringwill do the trick for URL objects. I think that behavior (strings and URL objects) makes sense for us too.http: allow url and options to be passed to http*.request and http*.get
http: allow url and options to be passed to http*.request and http*.get
http: allow url and options to be passed to http*.request and http*.get