Comments (6)
Yeah, I got your concern. So if we cannot differentiate b/w request and response timeout, a generic implementation like you have mentioned here #520 (comment) should be ok.
So the main use case for me here is we want to abort all the HTTP calls that takes more than X ms, that are used in the code behind our APIs, the API calls we make using axios or fetch, we can set our own timeout config with axios/fetch instances. But, the calls are made behind the scenes of other libraries/SDKs we don't have control. When we were experiencing high latencies in our APIs, and had no clue what was causing the delay, using this library I was able to trace most of the calls made by these libraries. So this thought came in, if we can trace/log these calls, adding timeout/abort config to it will be very useful.
from interceptors.
Hi, @imewish. Can you give me an example of what you'd use that timeout for? To cancel a request, I presume? Would love to learn more.
from interceptors.
Hey @kettanaito , yes I would like to cancel a request if it's taking more than X Milliseconds. Similar to the timeout specified in AXIOS.
from interceptors.
This is something I'd love to add too. This is the API I was thinking about, what's your opinion on it?
interceptor.on('request', ({ request, abortController }) => {
// Abort this intercepted request if it's taking more than 1s.
setTimeout(() => abortController.abort(), 1000)
})
The problem with this requirement is this: what defines the "taking more than X"? Is it X amount of time as the request is being sent? Before the first byte of the response is received? Before the entire response is received (cannot really cancel afterward)?
Let me know how you'd expect this to behave.
from interceptors.
Hey @kettanaito, this looks good. So ideally one should be able to cancel any requests in both cases you mentioned.
for eg, if the client was not able to make the network connection to the target domain, we should be able to cancel it instead of hanging forever. Also if the connection was made successfully and the response is taking too much of time we should be able to cancel it as well.
Im not sure if this is handled differently in the case of fetch when a user specifies the timeout params.
from interceptors.
eg, if the client was not able to make the network connection to the target domain
If you don't respond with a mock, the request will happen as-is. The connection shouldn't hang in either case.
Also if the connection was made successfully and the response is taking too much of time we should be able to cancel it as well.
My main question is: how do you describe this in the listener? You don't know which stage of the resolution the request is. The listener is called as soon as the request headers are sent. So you can abort while the request body is streaming, once it's done streaming, once it's waiting for the response. The problem is, you cannot differentiate between any of those in the listener because there's no way of knowing that.
Do you see my concern here? For you, the user of the library, it's a bad experience.
from interceptors.
Related Issues (20)
- Support "CONNECT" requests (in proxies) HOT 11
- Support HTTP2 HOT 3
- Intercepted fetch results in the the process never exiting / hangs Mocha tests
- error listener get called twice on mocked error with sync handler HOT 2
- Use "urlToHttpOptions" from "node:url"
- Header keys for requests are being converted to lowercase
- ReferenceError: TextEncoder is not defined when running (jest) tests HOT 4
- Treat exceptions as 500 responses instead of a "Failed to fetch" error HOT 7
- XMLHttpRequestController creates bad URL when location exists but href not set HOT 4
- WebSocket: Outgoing client events have the wrong "currentTarget" HOT 2
- WebSocket: Decide how to handle actual server errors
- Flaky: `modules/http/response/readable-stream.test.ts`
- ClientRequestInterceptor incorrectly encodes basic authentication header HOT 15
- Abstract request emitting logic
- Await all "response" listeners to finish HOT 4
- Protocol "https:" not supported. Expected "http:" when using "proxy-agent" HOT 1
- Simplify the npm package files HOT 2
- XMLHttpRequest upload (upload.onprogress) event is not supported
- Issue with native fetch introduce after 0.25.1? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from interceptors.