Keep `path` configurable

[cadorn]

Defaulting path to /engine.io will not work in our setup after all. We want to keep a prefix that mounts at the root.

If we make the path prefix a constant on the module it will apply to all engine.io instances in the app which is probably not desirable. It seems that it needs to stay as an option.

It could be an undocumented option or have a different name than path but we will continue to need it.

What do you think?

[rauchg]

@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.

[cadorn]

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.

[rauchg]

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:

1. url fragment
2. 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.

[rauchg]

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}

[cadorn]

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.

[rauchg]

I'll tweak the SPEC. I'm going to state that:

1. the unequivocal way of identifying engine.io requests is by looking for the query string __eio key.
2. 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.

[cadorn]

So resource goes and only path is left? So PR #76 needs to work on the path again?

[rauchg]

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.

[cadorn]

Let's call the option resource then. I find that path confuses people as they think of a filesystem path.

[rauchg]

mount would be better I think, for consistency with the terminology used by connect/express for this similar concept.

[cadorn]

Alright, mount it is.

[cadorn]

@guille FYI, I am away from the office next week.

[rauchg]

Replacing with /mount ticket