Comments (13)
@cadorn if we make it configurable we lose the ability to identify engine.io requests beyond the scope of this project. Like I explained in the other ticket, an external piece of software/hardware, like a load balancer, should be able to analyze an incoming request and say "this is an engine.io request". Keep in mind we can't add specific identifying HTTP headers such as X-Requested-With
to websocket or jsonp requests.
I'd like to understand why the path being configurable is a desirable thing in your setup. Alternatively we can also discuss maybe introducing a fixed query string EIO=1 or something along those lines.
from engine.io.
an external piece of software/hardware, like a load balancer, should be able to analyze an incoming request and say "this is an engine.io request"
This is nice but I wonder how practical it is in practice. I don't think anybody is going to hardcode a load-balancer route with /engine.io
and distribute it without making it configurable. Load balancer routes are typically under the control of the organization running the system and thus configurable. Any third party service will most likely add a configurable route (especially in the case where an alternative engine.io SPEC implementation is used and mounted to /alternative.io
).
For discoverability I would much rather prefer something like:
/interfaces.json ~ {
"/alternative.io": {
"spec": "https://github.com/LearnBoost/engine.io-client/blob/0.2.2/SPEC.md"
}
}
This elevates discoverability to a common place (to be standardized) and allows system authors to structure their URI namespace as they wish.
Everything can default to /engine.io
and you will get the results you are looking for by default. If a system author chooses to change the prefix they understand that they may no longer be compatible with certain configurations & services (which as I mentioned will likely offer config options anyway). Telling this system author that he cannot use engine.io
unless he prefixes with /engine.io
will likely get a I'll monkey-patch or use X library instead
response.
I'd like to understand why the path being configurable is a desirable thing in your setup.
We mount everything to /<user>/<project>/<service>
. engine.io
would be the only exception to this and while possible introduces extra code and URL routing in our setup which is not desirable.
Playing the devil's advocate: Who are you to tell me how to configure my URI namespace? I know what I am doing, am fully aware of the consequences and don't give a crap about anyone else!
From experience, trying to push standardization from the POV of one project never works. In this case I see the only out an approach equivalent to /interfaces.json
that is supported by a larger group of implementers.
from engine.io.
What I want is the ability to identify the protocol/service by just looking at the traffic. This is what HTTP headers are for. It's a very simple intent. Unfortunately, we can't add custom headers in 2 out of our 3 transports.
Options left that I can think of:
- url fragment
- query string
Since the SPEC is already in place for (1), I wanted to hear arguments against (1) / for (2), or an idea for (3) that I'm missing. I don't get where interfaces.json
comes into play.
from engine.io.
Actually I'm sold on (2): it gives us the chance to also include the protocol revision number as part of requests.
__eio={protocol revision number}
from engine.io.
1 url fragment
Who are you to force me to use a specific URI scheme to mount my services to?
2 query string
No objections. Anything after <path>/<resource>/
is domain of engine.io.
interfaces.json
You would request /interfaces.json
and look for your spec https://github.com/LearnBoost/engine.io-client
to determine the route to watch.
from engine.io.
I'll tweak the SPEC. I'm going to state that:
- the unequivocal way of identifying engine.io requests is by looking for the query string
__eio
key. - the path fragment under which the engine.io request is sent is configurable, but the default for server implementations should be
/engine.io
.
This effectively merges path
and resource
into one thing: path
, which is documented as the "mounting point" of a engine.io server instance. We drop the concept of default
in the URL.
Overall, we're adding extra information to the request (protocol revision), we're dropping server complexity (one less option to maintain, test and document), and default conventional URLs will look shorter.
from engine.io.
So resource
goes and only path
is left? So PR #76 needs to work on the path
again?
from engine.io.
Yeah. You could also articulate it as resource get renamed to path and defauls to /engine.io
and path goes away, considering we still want your patches for regular expression / string / fn support.
from engine.io.
Let's call the option resource
then. I find that path
confuses people as they think of a filesystem path.
from engine.io.
mount
would be better I think, for consistency with the terminology used by connect/express for this similar concept.
from engine.io.
Alright, mount
it is.
from engine.io.
@guille FYI, I am away from the office next week.
from engine.io.
Replacing with /mount
ticket
from engine.io.
Related Issues (20)
- [TS] socket.send / socket.write arguments HOT 1
- Wrong Tag version HOT 2
- Socket instance doesn't wait for all the packets in writeBuffer to be sent before closing the websocket transport. HOT 2
- Downgrade engine_socket transport error "polling request overlap" to 4xx from 5xx HOT 3
- feature: `BaseServer.corsMiddleware` should be publicliy modifiable HOT 3
- data coming from socket io is stopped after 10 minutes when we request call socket io at every 10-10 milisecond backend : node js frontend : angular js HOT 1
- Typescript: engine = undefined HOT 2
- TypeError: Cannot destructure property 'Server' of '_engineIo.default' HOT 5
- Customize response headers with Express middleware HOT 6
- Possible error in websocket code HOT 2
- clientsCount property of server... why need to keep this private, HOT 1
- ReferenceError: TextDecoder is not defined HOT 5
- Node.js versions below 10.2 are not compatible with the latest version 6.5.1. HOT 1
- WebTransport If the length of the data block exceeds maxDatagramSize, the server will be unable to receive the complete message (the client will not send the complete message). HOT 2
- Upgrading from polling to webtransport will report engine invalid WebTransport handshake. HOT 8
- The cache busting t query parameter does not work if multiple connections to the server are made HOT 3
- Add support for Node.js built-in WebSocket? HOT 7
- Send callback may not be called if message is sent during upgrade window HOT 2
- Cannot set `socket.request` to `null` because the property is read-only HOT 2
- `websocket`: `send` callbacks are not all called if multiple messages are sent rapidly HOT 1
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 engine.io.