I've a JS (Angular) client that makes a PUT request (REST API) to server and server sends back a large payload that I'm not using in the client currently.
Is there a way to just fire the request and ignore any response that comes back? The main need here is to avoid the data cost incurred by receiving that payload. I've looked at closing the connection once the request is fired, but am not sure if that's the best way to handle this.
If able, I think the only way to change this would be to change the api endpoint to not include a payload from the put request.
I'm assuming you are using angular's http class and using Observables. But even if you aren't, your angular client is going to need to read the response status sent back from the server to determine whether or not the put request was successful or not. In order to read the status, you'll need to response, and unfortunately the full response sent from the server.
You could close the connection right after the request, but as I've mentioned you'll have no way of knowing whether or not the request was successful.
To ignore the request just don't do anything if the request is successful.
If you don't want the request to exist at all then do it on the backend.
Related
I need to cancel first pending request if another was sent from the same service as the first is outdated already and there is no need to spend time on it as there will be two parallel request from same service.
Could you tell me ways how to do it?
It's GET request from service with #service decorator like:
this.service.get({ id: someId }).then(this.result)
You can't cancel a request from the client's side, once its fired.
You can cancel it from the server's side, once a new request arrives - and identify the duplicate using some key in the request headers or body.
The only thing you can do on the client's side - is ignore the response of the first request.
Actually, I´ve create a Batch HTTP API that receives a JSON array with many different requests to our backend server. The Batch API just call all of these requests to a load balancer, wait for the return of all of them and return a new JSON to the client.
The client receives a huge JSON array response with its indices in the same position as the request, so it is easy to know what response is addressed for what request.
The motivation for this API was to solve the 5 browser simultaneous connections and improve performance as the Batch API has a much more direct access to the server (we do not have a reverse proxy or a SSL server between then).
The service is running pretty well, but now I have some new requirements as it is gaining more use. First, the service can use a lot of memory as it has a buffer for each request that will only be flushed when all responses are ready (I am using an ordered JSON Array). More, since it can take some time to all requests be delivered, the client will need to wait everything be processed before receiving a single byte.
I am planning change the service to return each response as soon it is available (and solve both issues above). And would like to share and validate my ideas with you:
I will change the response from a JSON response to a multipart response.
The server will include, for every part, the index of the response
The server will flush the response once its available
The client XHR will need to understand multipart content type response and be able to process each part as soon as it is available.
I will create a PoC to validate every step, but at this moment I would like to validate the idea and hear some thoughts about it. Here some doubts I have about the solution:
From what I read, I am in doubbt of that content-type is right for the response. multipart/mixed? multipart/digest?
Can I use an accept request header to identify if the client is able to handle the new service implementation? If so, what is the right accept header for this? My plan is to use the same endpoint but very accept header.
How can I develop a XHR client that is able to process many parts of a single response as soon as they are available? I found some ideias on the Web but I am not entirely confident with then.
I will change the response from a JSON response to a multipart
response.
The server will include, for every part, the index of the
response
The server will flush the response once its available
The
client XHR will need to understand multipart content type response and
be able to process each part as soon as it is available.
The XHR protocol will not support this work flow through a single request from the client. Since XHR relies heavily on the HTTP protocol for communications, XHR follows the HTTP connection rules. The first and most important rule: HTTP connections are always initiated by the client. Another rule: XHR returns the entire content-body or fails.
The implications for your workflow is that each part of the multipart response must be requested individually by the client.
From what I read, I am in doubbt of that content-type is right for the
response. multipart/mixed? multipart/digest?
You should be in doubt as there is no provision in the specfication to do this. The response-type attribute is limited to the empty string (default), "arraybuffer", "blob", "document", "json", and "text". it is possible to set the override MIME type header, but that does not change the response type. Event given that case, the XHR spec is very clear about what it will send back. It is one of the types listed above as documented here.
Can I use an accept
request header to identify if the client is able to handle the new
service implementation? If so, what is the right accept header for
this? My plan is to use the same endpoint but very accept header.
Custom HTTP headers are designed to assist us in telling the server what our capabilities are on the client. This is easily done. it doesn't necessarily have to be in the accept header (as that also is a defined list of MIME types).
How
can I develop a XHR client that is able to process many parts of a
single response as soon as they are available? I found some ideias on
the Web but I am not entirely confident with then.
XHR is processed natively by the client and cannot be overridden for all sorts of security reasons. So this is unlikely to be available as a solution for this reason.
Note: ordinarily one might suggest the use of a custom version of Chromium, but your constraints do not allow for that.
A software that i'm using(https://camlytics.com/) sends a request to a webhook whenever a particular event occurs, now i want to process that request but the problem is that the request is sent with the following headers as empty
content-length
content-type
Due to this reason my node code completely ignores the request. I have verified that the request is actually being sent via creating a webhook # webhook.site.
I fail to understand if webhook.site can show and process that request, why cant node do it? the code easily processes all other get requests.
Would appreciate if someone could either
help me process the request as in make it accessible via the code
if somone with experience on camlytics help me configure it in such a way that i can configure the headers of the request.
I have tried this on serverless azure function which is supposed to trigger for all HTTP requests but event that doesnt trigger, neither does it trigger on my local NODE server.
This is the request details that webhook.site shows me
Camlytics webhooks seem to work OK if you add Content-Type application/json to the Headers properties box for the HTTP Response node.
Is there a way to make an $.ajax POST request:
without requiring a response
so the server doesn't even try to return anything
Are there some HTTP headers to accomplish this? The goal would be to track statistics with minimal server and client request processing.
The server should return a HTTP/204 No Content response. That's as close as you can get.
If it is no problem in terms of security, and the amount of data you send is at maximum 2K minus the length of your URL, use a GET request instead. A GET request sends only one TCP packet, instead of two packets as a POST request does (first the header, then the data).
If an http request is made and the caller abandons the request does it get completed anyway? For example an asynchronous JavaScript GET request to log a banner click in the DB then redirect. Does the script need to wait for the response?
How critical is your request? What if the database is not available at that time? What if the server side code throws an exception?
For very critical requests, you may need to implement some sort of message queueing that is able to hold the request data until it can be fully processed. This gets more complicated if you are dealing with grids and clouds (you can't just queue the message on a single node, since the node can potentially have a hardware failure). But this is an extreme case, where you end up with dedicated queue servers.
The client doesn't send any notification to the server that it is canceling the request.
PHP doesn't know if the client has disconnected until it tries to send the client some data (eg., an unbuffered echo() call), so if your script doesn't return any data to the user, it will fully execute. If it does return data it may abort partway through, but this can be changed with ignore_user_abort())
If you're using a different environment, you will have to explore the documentation.
For most cases, once the request is received by the server, it will not stop processing if the client stops listening.
However, the server can always fail while servicing the request, so it's probably not a good idea to assume it completed.
You should wait for it to be safe. You never know when the server is going to get around to processing your request (though it is usually within a couple hundred milliseconds or less), so you won't know if something timed out, failed, or if you were going to receive a different response than expected unless you wait.
You don't have to wait for the response in order for the request to reach the server. The server can check if someone is still listening while processing the request, but processing the request will start even if noone is listening for the response (unless there was an error on the way, of course).
If you want to be sure that the request really was processed, you should wait for the response, but it's not required for the request to go through to the server.