Flexibility of URI

[bachp]

Currently uri requires a canonical hostname and uses the session as the first element after the path.

Maybe this is a constraint to rigid. Consider the case wehre there are multiple endpoints accessible via http on idfferent urls like this:

• Endpoint A: https://mydomain.com/A
• Endpoint B: https://mydomain.com/B

"/A" and "/B" would conflict with the session part of the URI definiton.

An alternative would be to encode the session as a parameter like csid. This way the whole hirarchical part would be available for the endpoint.

[quartzjer]

Great suggestion, I've already run into this myself and I like that approach of putting the session in the parameters... let me try it out and I'll create a pull req if it works :)

[quartzjer]

@bachp ok, so after looking at this I think it's more of a documentation issue... I remember fully intending the session to work as you describe it already, as an arbitrary path that the router has control over.

It's only called out as a distinct thing to everyone else (and with fixed limits) so that other parties can preserve/cache it as the opaque session value that is only relevant to/for the router. When used in a http/https context it would still just be a path.

The whole URI doc could use some more TLC, including a section on this/session usage too.

[bachp]

@quartzjer Ok it wasn't clear to me what the purpose of the session was. Maybe the name session is misleading as I associate a kind of state with it.

I would love to help with the URI document but I still try to wrap my hand around how everything fits together ;) . Like URI vs Path.json, and how this fits with routers and peer, path and connect channel etc. I think a drawing would be helpful.

[quartzjer]

Definitely need a drawing, @temas was just wanting this too as he's in the middle of the c# implementation, I'm terrible at drawings so maybe he'll help make one :)

The session is in fact a state variable from the router, the URI is only valid for as long as the router can accept/validate a given session when it's sent back to it, this is all good material for an update to the spec, thx!

[quartzjer]

@bachp been thinking about this more (particularly as I've been looking at the OpenID Connect interop), and the way that session and token are re-used here are really confusing.

I'm going to try out a new approach for URIs and start a pull req...

[quartzjer]

URI has been overhauled, feel free to re-open if you don't think this was addressed, and thanks for spurring that work to the top of the TODO list!

[bachp]

URI handling looks good now. Well done. Thanks