I think this is probably fine since it's an addition and we aren't going to remove the "g" field from the request. Currently, TinkerPop doesn't really have a notion of server topology and the expectation is that all servers can service requests for any "g". That's kind of the reason it works this way, but if you are building a server that needs this functionality then I'm for making this change. Were there any alternatives you considered? E.g. why not just move "g" from body to header rather than having it as part of the URL?
On Fri, Jul 17, 2026 at 4:35 AM Daniel Worthington-Bodart via dev < [email protected]> wrote: > Hi all, > > I've been building a TinkerPop 4 server ( > https://github.com/bodar/mogwai-db/) > and hit a rough edge in the HTTP protocol I'd like to float. > > Today a request carries everything in the body — the Gremlin string, > bindings, and the traversal-source name (g) that selects the target graph — > against a single endpoint path. That works end-to-end, but the only thing > identifying the target graph lives inside the payload. > > The friction: proxies, gateways, and CDNs route on method + URL + headers, > never the body. So routing by target graph (multi-tenant sharding, > per-graph auth, rate limiting, metrics) means buffering and parsing the > body to extract g — a binary parse at the edge with GraphBinary, which is > exactly what a proxy shouldn't be doing, and in some setups isn't possible > at all. > > Proposal: allow the traversal source in the URL path — e.g. POST > /gremlin/{g} — as an equivalent to sending g in the body. The body form > stays for full backwards compatibility; a path segment simply takes > precedence. Ideally the GLVs would default to the path form so the > ecosystem becomes proxy-routable out of the box. > > It's a small, backwards-compatible change that would make TinkerPop servers > far easier to run behind standard infrastructure. I've implemented the path > form in my own server and it's been a clear win. > > Is this something the project would be open to discussing? If there's > appetite, I'm happy to create Jira / PR as needed. > > Thanks, > Dan >
