So, I want to use node.js and http request pipelining, but I want to use HTTP only as a transport, nothing else. I am interested in exploiting the request pipelining feature. However, one problem that I am running into is that till a send a response to a previous request, the next requests's callback isn't fired by node. I want a way to be able to do this. I shall be handling the ordering of results in the application. Is there a way to do this?
The HTTP RFC mentions that the responses should be in order, but I don't see any reason for node.js to not call the next callback till the 1st one is responded to. The application can in theory send the response to the 2nd query as a response to the 1st one (as long as there is some way for the recipient to know that it is a response to the 2nd one).
The HTTP client in NodeJS does not support pipelining. (Slightly old post from Ryan, but I'm fairly sure it still holds.)
Related
I know that, in principle, HTTP GET requests shouldn't have any side-effects (i.e. idempotent).
But I'm experimenting and, so far, my test HTTP GET requests that change data on a test database work just fine: it doesn't look like the HTTP GET requests ever get re-requested.
Now my tests are not representative of the real world. In the real world, any middle-man (e.g. Cloudflare) could take in consideration the fact that the HTTP request is GET and re-request the HTTP request, for example upon flaky networking. But I wonder if this actually ever happens?
Note that the HTTP requests in question are all browser-side fetch() JSON requests using the Fetch API. (I think that's relevant because while Cloudflare does re-request HTML resources, I don't think Cloudflare would ever re-request a fetch() JSON request.)
My gut feeling says that, while in theory such HTTP GET requests are allowed to be re-requested, it doesn't happen in practice. Am I right or is there a situation showing that I'm wrong?
Context
I'm the author of Telefunc which is a JavaScript/TypeScript RPC implementation and I'd like to make all Telefunc's HTTP request be GET, even when the user makes database changes. I'd like to do this because this would enable Telefunc to support ETag caching for all requests and without the user having to configure anything.
At work I often see people talking about the webhook and postback patterns interchangeably, I'd like to know if there is a difference.
I've also noticed two patterns:
There's one in which you send an HTTP request to an endpoint stating through a header field an address to which the result of the asynchronous operation should be sent;
Another one in which you previously set an address to which the results should be sent. And then, on your HTTP requests, you will not inform this address again, but the results will be sent to the address previously configured.
Could anyone explain the difference, if there is any?
Thanks in advance.
I have read many discussions on this, such as the fact the PUT is idempotent and POST is not, etc. However, doesn't this ultimately depend on how the server is implemented? A developer can always build the backend server such that the PUT request is not idempotent and creates multiple records for multiple requests. A developer can also build an endpoint for a PUT request such that it acts like a DELETE request and deletes a record in the database.
So my question is, considering that we don't take into account any server side code, is there any real difference between the HTTP methods? For example, GET and POST have real differences in that you can't send a body using a GET request, but you can send a body using a POST request. Also, from my understanding, GET requests are usually cached by default in most browsers.
Are HTTP request methods anything more than just a logical structure (semantics) so that as developers we can "expect" a certain behavior based on the type of HTTP request we send?
You are right that most of the differences are on the semantic level, and if your components decide to assign other semantics, this will work as well. Unless there are components involved that you do not control (libraries, proxies, load balancers, etc).
For instance, some component might take advantage of the fact that PUT it idempotent and thus can re retried, while POST is not.
The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients and servers.
HTTP works as a request-response protocol between a client and server.
A web browser may be the client, and an application on a computer that hosts a web site may be the server.
Example: A client (browser) submits an HTTP request to the server; then the server returns a response to the client. The response contains status information about the request and may also contain the requested content.
HTTP Methods
GET
POST
PUT
HEAD
DELETE
PATCH
OPTIONS
The GET Method
GET is used to request data from a specified resource.
GET is one of the most common HTTP methods.
Note that the query string (name/value pairs) is sent in the URL of a GET request.
The POST Method
POST is used to send data to a server to create/update a resource.
The data sent to the server with POST is stored in the request body of the HTTP request.
POST is one of the most common HTTP methods.
The PUT Method
PUT is used to send data to a server to create/update a resource.
The difference between POST and PUT is that PUT requests are idempotent. That is, calling the same PUT request multiple times will always produce the same result. In contrast, calling a POST request repeatedly have side effects of creating the same resource multiple times.
The HEAD Method
HEAD is almost identical to GET, but without the response body.
In other words, if GET /users returns a list of users, then HEAD /users will make the same request but will not return the list of users.
HEAD requests are useful for checking what a GET request will return before actually making a GET request - like before downloading a large file or response body.
The DELETE Method
The DELETE method deletes the specified resource.
The OPTIONS Method
The OPTIONS method describes the communication options for the target resource.
src. w3schools
Client sends a POST or PUT request that includes the header:
Expect: 100-continue
The server responds with the status code:
100 Continue
What does the client send now? Does it send an entire request (the previously send request line and headers along with the previously NOT sent content)? Or does it only send the content?
I think it's the later, but I'm struggling to find concrete examples online. Thanks.
This should be all the information you need regarding the usage of a 100 Continue response.
In my experienced this is really used when you have a large request body. It could be considered to be roughly complementary to the HEAD method in relation to GET requests - fetch just the header information and not the body (usually) to reduce network load. 100 responses are used to determine whether the server will accept the request based purely on the headers - so that, for example, if you try and send a large POST/PUT request to a non-existent server resource it will result in a 404 before the entire request body has been sent.
So the short answer to your question is - yes, it's the latter. Although, you should always read the RFC for a complete picture. RFC2616 contains 99% of the information you would ever need to know about HTTP - there are some more recent RFCs that settle some ambiguities and offer a few small extensions to the protocol but off the top of my head I can't remember what they are.
I'm wondering: if I were a a router, packet inspector, firewall, or other packet-sniffing device (which I'm glad I'm not) would I be able to tell the difference between a traditional HTTP request and an XMLHttpRequest? Less theoretically, is it possible that some ISP or (let's say) cell phone data provider could restrict XMLHttpRequest traffic without interrupting HTTP service?
Thanks.
There's nothing at the packet level to distinguish them because and XMLHttpRequest is an HTTP request. The XML bit refers to the fact that if the response is of an xml Content-Type then the responseXML method will return a DOM Object.
To the best of my knowledge, there is no fundamental difference - so from the point of view of a router etc. you can't tell in general.
But I do believe that most popular Javascript toolkits will add an HTTP header to their XMLHttpRequests to identify them as such. I forget the name, though...
EDIT: Here's an example (top Google hit for "jquery xmlhttprequest header", no quotes) that shows that jQuery apparently sets X-Requested-With to "XMLHttpRequest".
at packet, network, session levels: no.
at application level, that is with an HTTP-specific device like a filtering proxy, maybe.
i'd check the HTTP request headers. they might (just might) have some differences. but i'm sure any difference there would be very browser-specific, and quite probably the right JavaScript code could insert the appropriate headers to make it totally indistinguishable.
in short: check the HTTP headers; but don't expect it to be general, much less useful.