HTTP_X_NEWEST requests require objects to have a timestamp header

Bug #837428 reported by Doug Weimer
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
Fix Released

Bug Description

In proxy/ GETorHEAD_base, the code block to find the newest object will never select a source if the objects don't have x-put-timestamp or x-timestamp headers. I ran into this issue when testing the upgrade from Cactus (using swauth) to 1.4.2 (using swauth 1.0.3-dev). The swauth user objects don't have timestamps set and the authentication process fails when GETorHEAD_base returns a 404.

The issue is that the 'pts > ts' condition never sets source if all of the object timestamps are 0. Always setting source to possible_source when source is undefined would fix this issue, but it would change the behavior of HTTP_X_NEWEST requests. I'm not sure how strict HTTP_X_NEWEST was intended to be.

(line 647 in current trunk)
if newest:
    ts = 0
    if source:
        ts = float(source.getheader('x-put-timestamp') or
                      source.getheader('x-timestamp') or 0)

    pts = float(possible_source.getheader('x-put-timestamp') or
                   possible_source.getheader('x-timestamp') or 0)

    if pts > ts:
        source = possible_source

Related branches

Revision history for this message
Doug Weimer (dweimer) wrote :

The linked branch will set 'source = possible_source' if source does not exist. Regardless of whether or not a timestamp is present.

Revision history for this message
John Dickinson (notmyname) wrote :

if you are done coding on your linked branch, please propose it for merging

Revision history for this message
gholt (gholt) wrote :

Ah interesting. I suppose we never noticed this as we upgrade our object servers before we upgrade our proxy servers. Thanks for the report and patch!

Thierry Carrez (ttx)
Changed in swift:
milestone: none → 1.4.3
status: New → Fix Committed
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.