Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can only use one set of ledge options per request? #21

Closed
bakins opened this issue Jul 12, 2012 · 6 comments
Closed

Can only use one set of ledge options per request? #21

bakins opened this issue Jul 12, 2012 · 6 comments
Labels
Milestone

Comments

@bakins
Copy link

bakins commented Jul 12, 2012

I have a situation where I need subrequests that may be ledge requests as well. Should the options, etc, be done on a per request ledge table/object? Something like

local ledge = require "ledge.ledge"
local l = ledge.create()
l.set(......)
l.bind(...)
rack.use(l, { proxy_location = "/__ledge/example.com" })
rack.run()

This may also allow "caching" the ledge "objects" in init_by_lua. Perhaps you have named ledge objects, ie you pass a key to create and can later fetch the object by key.

@pintsized
Copy link
Member

Currently (because we haven't refactored yet based on the outcome of discussions on #11), this isn't possible. But with the suggested mechanism in #11, all options will actually be stored within the ngx.ctx table. This means that they are relevant to the current request only, and this is also true of sub-requests.. which have their own ngx.ctx space.

So in principle, when the new config mechanism is working (soon!), you can have different origin_location or redis_host options for requests and sub-requests.

Does that sound like what you need?

@bakins
Copy link
Author

bakins commented Jul 12, 2012

For now, yes. I'd like to help out if I can.

@pintsized
Copy link
Member

Cool, nice one. I'm in the middle of working on refactoring the config stuff, so I'll get something committed soon.. feedback will be most welcome :)

In general, this whole project is in flux right now, as you will have gathered, but it's starting to make some sense. Do feel free to send pull requests and generally request / discuss features on here. Hopefully it'll be a little less fragile in the coming weeks..

@pintsized
Copy link
Member

I've just committed a first pass of this.. So you can now do something like:

http {
    init_by_lua '
        rack = require "resty.rack"
        ledge = require "ledge.ledge"
        ledge.gset("origin_location", "/__ledge/example.com")
        ledge.gset("redis_host", 192.168.1.234)
    ';

    server {
        location / {
            content_by_lua '
                rack.use(ledge)
                rack.run()
            ';
        }
    }
}

@pintsized
Copy link
Member

I should add that ledge.gset("cache_key_spec", table) isn't supported. Need to think about that a bit.

@pintsized
Copy link
Member

I've sent a pull request to lua-nginx-module which adds ngx.get_phase() to the API. When this is released, we'll drop ledge.gset(). So config parameters can be set either globally during init_by_lua or per-location, both using the uniform ledge.set().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants