Thanks for the quick reply!
On header vs. path: I did consider the header, and it'd work fine. I lean
toward the path because the graph really is a resource here, not just
routing metadata. POST /gremlin/{g} reads as "run this query against this
graph," with the graph as a first-class addressable thing — idiomatically
RESTful rather than using HTTP as a tunnel.
The practical payoff of that framing: the graph identity shows up where
HTTP infrastructure already looks — cache keys, access logs, CDN path rules
— without parsing the body or knowing a custom header.
Not an either/or hill to die on; a header's a reasonable middle ground. But
if we're picking a default, my vote's the path.
On Fri, 17 Jul 2026 at 18:16, Ken Hu <[email protected]> wrote:
> 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
> >
>
