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

CloudFiles set_temp_url_key and get_temp_url_key Bug #613

Open
bormesh opened this issue Jul 29, 2016 · 2 comments
Open

CloudFiles set_temp_url_key and get_temp_url_key Bug #613

bormesh opened this issue Jul 29, 2016 · 2 comments

Comments

@bormesh
Copy link

bormesh commented Jul 29, 2016

Hi,

so I'm running into a bug when trying to get a previously set Temp_URL_Key.

I do something like the following:

cf = pyrax.cloudfiles
cf.set_temp_url_key('testurlkey')
cf.get_temp_url_key(cached=False)

'get_temp_url_key' is calling the underlying 'get_account_metadata' which returns a dictionary like this:

cf.get_account_metadata()
{'X_Account_Meta_Temp_Url_Key': 'testurlkey'}

But, the method, 'get_temp_url_key' uses the key 'temp_url_key' to index into the above returned dictionary (see below)

    def get_temp_url_key(self, cached=True):
    """
    Returns the current TempURL key, or None if it has not been set.

    By default the value returned is cached. To force an API call to get
    the current value on the server, pass `cached=False`.
    """
    meta = self._cached_temp_url_key
    if not cached or not meta:
        key = "temp_url_key"
        meta = self.get_account_metadata().get(key)
        self._cached_temp_url_key = meta
    return meta

Therefore, 'cf.get_temp_url_key' is returning None, as we're indexing by the wrong key.

Looks like a simple fix would be to change key = 'X_Account_Meta_Temp_Url_Key'.

Thanks for looking into this!

@tjensen
Copy link

tjensen commented Oct 1, 2016

I have also encountered this problem but I believe the issue is related to the requests library. If I pip install requests==2.7.0, get_temp_url_key works correctly. If I upgrade to requests==2.8.0 or newer, I observe the problem described above.

Downgrading requests to 2.7.0 seems like an okay work around, for now, but I think pyrax needs a real fix so that it can work with newer versions of requests.

@spiralman
Copy link

Just to add some further details: the problem is caused by new versions of requests returning the headers with the same case as they were received "over the wire" (previously it lowercased them before returning them to the caller).

The code for parsing the headers and looking for the metadata assumes the headers are already lowercased (although, it looks like that is actually a typo, as it is also lowercasing the header names itself, just not using it everywhere it should).

Presumably, https://github.com/pycontribs/pyrax/blob/master/pyrax/object_storage.py#L914 should read:

# note: lowkey.replace instead of hkey.replace
cleaned = lowkey.replace(low_prefix, "").replace("-", "_")

We added another library which required a newer version of requests, so we were no longer able to stick with requests 2.7.x.

We worked around the issue by manually re-implementing temp_url_key(), then passing that key in explicitly when calling get_temp_url() (we had been relying on get_temp_url to auto-determine the temporary URL key).

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

3 participants