Semantic meaning of response (res) and request (req) in Endpoint handlers #1605
-
|
First off I love this project and so far it’s worked amazing! I’m just a little bit confused about the endpoint handlers (the functions / lambdas passed after the endpoint URL when creating the uWS App). Does the httpResponse parameter mean the server’s response to the client, or the clients response to the server? I’m confused because we use res.ondata to read the post body FROM the client, which means it can be considered the clients REQUEST to a server, but then we also write (and add headers etc to send back to the client) to it which means it can be considered as the server’s response to the client… Semantically I’d expect the httpRequest method to have the ondata function as the clients REQUEST to the server should contain the post data, and for it to also have the headers of the client request, the httpresponse being the servers response to the client containing the associated headers and such. Basically I’m wondering why httpRESPONSE contains the clients REQUEST data, and we also use it to send the servers RESPONSE to a client. I’ve used caps to attempt to highlight the wording that’s confusing me. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
|
Request object is for initial event, everything else like onData goes with Response so that the Request object can be immediately discarded after route is first triggered |
Beta Was this translation helpful? Give feedback.
-
|
I see, so does that mean when the route first triggers, the request object holds data about the client request (like headers etc), or nothing at all and the response object handles all of it? If it contains nothing, then does it have any uses / purposes of being there? |
Beta Was this translation helpful? Give feedback.
-
|
HttpRequest has headers, parameters, url and everything that belongs to the HEAD of the request but none of the body |
Beta Was this translation helpful? Give feedback.
-
|
I can understand the confusion - HttpResponse should not have .onData because it's not part of the response, it's part of the request. All other JS servers put their equivalent of .onData in the request. We can't do this because the lifetime of HttpRequest is way shorter than that of HttpResponse. So better naming would be: HttpRequest becomes HttpHead and HttpResponse becomes HttpConnection Then you have a naming that goes like head, connection rather than req, res. |
Beta Was this translation helpful? Give feedback.
-
|
Ah! Okay, that clears it up, thank you so much! |
Beta Was this translation helpful? Give feedback.
I can understand the confusion - HttpResponse should not have .onData because it's not part of the response, it's part of the request. All other JS servers put their equivalent of .onData in the request.
We can't do this because the lifetime of HttpRequest is way shorter than that of HttpResponse. So better naming would be:
HttpRequest becomes HttpHead and HttpResponse becomes HttpConnection
Then you have a naming that goes like head, connection rather than req, res.