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

Public URLs? #5

Open
maxcountryman opened this issue Sep 4, 2013 · 5 comments
Open

Public URLs? #5

maxcountryman opened this issue Sep 4, 2013 · 5 comments

Comments

@maxcountryman
Copy link

Hi again,

Sorry to bother you again with what is probably a very dumb question, but I'm not able to figure out how to get the public URL out of a container.

For instance, I've created a container "foo" via swift.api/create-container. I am able to put things in this container, list them and see them, but I don't see a public URL (or even an internal one) in any of the calls. There doesn't seem to be any way to find the public or internal URLs associated with this container.

Am I going about this the wrong way?

@ddillinger
Copy link
Contributor

The context map that is returned from authenticating includes what you need to know to derive those.

The :x-storage-url key is the (internal) base URL that your account has been assigned, for the region you asked for. Therefore, assuming you've bound that result to config and your container name to container your url is effectively just (str (:x-storage-url config) "/" container)

The publicURL can be found in there too. The :response key includes the full clj-http response map that was returned from the Cloudfiles server. Anything you might need that isn't directly called out will still be in there; check the docs for what that stuff all is here: http://docs.rackspace.com/files/api/v1/cf-devguide/content/Authentication-d1e2929.html -- in particular, 'publicURL' is in that json response. That's there to cover the "well, can't anticipate every possible need, let's make sure it's all there, you never know!" case.

@maxcountryman
Copy link
Author

I'm not sure that's quite what I want or maybe I'm still not understanding the API properly.

In the Python wrapper, the container itself has a URL associated with it, e.g. container.cdn_ssl_uri. Then you'd do something like container.cnd_ssl_uri + '/' + 'id'; this would be a permalink to the uploaded file. This is what I'd like to retrieve so I can point to the file I uploaded in the container. I see a number of public URLs in the config :response map but none of them seem to be related to a specific container. I think there's supposed to be a header like x-cdn-ssl-uri associated with each container?

In Python I'm producing urls that look like this: https://1377e9d4d919ca2a3b06-b8c4b5af8ab853358943b3df59213319.ssl.cf2.rackcdn.com/5227ae24deca3d06becd72cb-5227ae28deca3d5884bc8091-320x240-F8zb4lPNDTyd

@maxcountryman
Copy link
Author

By the way, it looks like this is how the Python wrapper is achieving that: https://github.com/rackspace/pyrax/blob/82aed3979d042b62b218b9533e0f4d7c49aecdb1/pyrax/cf_wrapper/container.py#L58

I think that's making a HEAD request against the container name. Is something similar possible with Apodini?

@ddillinger
Copy link
Contributor

The publicURL entry in the config response is for all containers in the region. You'd need to append the container you're interested in, to construct the full path.

There's definitely not been explicit support added yet for CDN headers, if CDN support is what you're specifically after. That being said, the return value for both put-object and create-container is the clj-http response map, which will include :headers as a key. So, at container or object creation time you should have access to any headers that are returned, including any x-cdn-* headers cloudfiles includes.

@maxcountryman
Copy link
Author

Yeah I need a way to enable CDN access per-container and then retrieve that public uri. It sounds like that isn't yet possible with Apodini?

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

No branches or pull requests

2 participants