PDK: Path related function relative to router matches and service path

In the Plugin Development Kit, there are function to get the URI path (kong.pdk.request.get_path) and set the URI path (kong.service.request.set_path) which operates directly on ngx.var.request_uri and ngx.var.upstream_uri respectively. This means the path returned from get_path will include the router-matched path while set_path will also replace the service path configured via the admin api. Is there any way to get the request path excluding the router-matched path and set the path with the service path part’s persist?


  • if configured router paths is [/request], strip_path is true, and request uri is /request/idx/1?safe=true, then how to get only the /idx/1 part without harcoding the “/request” part in the plugin logic
  • if configured router paths is [/request], strip_path is true, configured service paths is /service, and request uri is /request/idx/1, then how to safely set the path so that request will be forwarded to /service/idxes/2 without harcoding the “/request” and “/service” part in the plugin logic
1 Like

Depending on your use case (whether your plugin is designed to connect to routes, services or either), you can get the route/service ID either from the plugin conf table (conf.route_id or conf.service_id) or from the dynamic execution context (ngx.ctx.route.id or ngx.ctx.service.id). With those IDs you can then get the configuration of those entities using kong.db, as in kong.db.routes:select({ id = conf.route_id }). This will allow you to get to the route’s paths field or to the service’s path field.

Thank you for the early feedback on the Plugin Dev Kit! In this first iteration, we focused on the request and response operations, and we didn’t modify the execution flow logic of plugins (hence things like ngx.ctx.route.id still show). Learning about the ways people use the PDK will definitely help us along the way for improving it!

I see. i sure hope that kong’s entity such as route, service, consumer, etc will be included in the PDK so that custom plugin operations depending on those entities are forward-compatible. Thanks