User Metadata keys with Underscore get translated to dash

[Douglas Soltesz]

User keys with an _ in them get translated to -. This occurs for Account, Container, and Object keys.

While this may not be a huge issue in swift as the translation is consistent, it matters for use with Swift3. When using Swift3 the client must sign all headers. The signature on the client side is calculated on an underscore, but the Swift3 system calculates based on the translated dash. As a result, it is not possible to access a swift backend using keys with underscores as the signature will always fail.

Below is an example:
$ curl -i -X POST -H "$token" -H "X-Object-Meta-xattr_cnt: 0 " $surl/test/hello.txt
HTTP/1.1 202 Accepted
Content-Length: 76
Content-Type: text/html; charset=UTF-8
X-Trans-Id: txd00a4cecda624157a4050-005584defb
Date: Sat, 20 Jun 2015 03:33:15 GMT

$ curl -i -X HEAD -H "$token" $surl/test/hello.txt
HTTP/1.1 200 OK
Content-Length: 12
X-Object-Meta-Xattr-Cnt: 0
Accept-Ranges: bytes
Last-Modified: Sat, 20 Jun 2015 03:33:16 GMT
Etag: ed076287532e86365e841e92bfc50d8c
X-Timestamp: 1434771195.67249
Content-Type: application/octet-stream
X-Trans-Id: txb8edee8726d34536852b2-005584df3c
Date: Sat, 20 Jun 2015 03:34:20 GMT

[Samuel Merritt (torgomatic)]

I'm not sure that either OpenStack Swift or Swift3 can fix this one; the translation is happening down at the Eventlet level. It's not just Eventlet that does it; I looked at gunicorn's WSGI server, and they do it too.

In fact, it looks like this translation is required(!) by PEP 3333. The section "Environment Variables" refers to the CGI specification, which is RFC 3875 (https://www.ietf.org/rfc/rfc3875). Section 4.1.18 there says:

    Meta-variables with names beginning with "HTTP_" contain values read
    from the client request header fields, if the protocol used is HTTP.
    The HTTP header field name is converted to upper case, has all
    occurrences of "-" replaced with "_" and has "HTTP_" prepended to
    give the meta-variable name.

So, that thing with the dashes and underscores? Required by the standard. See also <http://wompwompwomp.com/>.

[John Dickinson (notmyname)]

Marking this invalid for swift3 because it's not a problem there. It's the interaction between HTTP (and assumptions about it) and the WSGi spec.

Also, if someone weren't using swift3 at all but instead the Swift API directly, then the user may still have a complaint that we are not returning the metadata keys they sent.

[John Dickinson (notmyname)]

Because of the conflicting specs, there's not a lot we can do here.

However, we should *definitely* write this down in the docs.

[John Dickinson (notmyname)]

http://tools.ietf.org/html/rfc7230#section-3.2.6 <-- _ and - are both allowed by HTTP

As above, the WSGI spec translates the - to _, and thus information is lost that can't be recovered.

[John Dickinson (notmyname)]

Seems we might be able to fix this, but upstream in the wsgi server. Re-opening to track that progress so we know when to upgrade dependencies.

[Tim Burke (1-tim-z)]

We can find a way to fix this if we bump our minimum eventlet to 0.19.0 -- see https://github.com/eventlet/eventlet/commit/67ec999. Swift3 has a patch outstanding at https://review.openstack.org/#/c/345739/ to use that when calculating signatures.

[Tim Burke (1-tim-z)]

That swift3 patch eventually merged, and we still carry it now that we've got s3api in-tree again. We could consider trying to do something similar for the Swift API, but at this point, I'd be too worried about breaking clients that may *expect* the translation.