Atmos filename special characters support...

Unicode characters in paths must be URL escaped when sending a request.  This should happen *after* the signature has been generated (so the signature is on the actual UTF-8 bytes).  Also be sure to lowercase the entire path when signing.  This may be tricky if you're doing it manually using codepages, but most languages take care of this for you.

Our SDKs and utilities all take care of this automatically.  Please note that if you're using AtmosFox, you need version 1.2, which may not have been reviewed by Mozilla, so it doesn't appear as the "latest version".  You can find it here:

https://addons.mozilla.org/en-us/firefox/addon/atmosfox/versions/

Thanks Raj & Chris.  Here is more detailed info:   As explained on page 15 of Atmos Programmer's Guide, we are using Listable User Metadata (x-emc-listable-tags) for easy indexing, searching and retrieval of objects.

page 25 decribes usage of x-emc-listable-tags.

==========================================

x-emc-listable-tags: tag_name1

[,tag_name2...]

Used in responses to return listable metadata tags for an object

(which are set with the

x-emc-listable-meta header).

SPECIAL CHARACTERS: if a metadata tag name

contains a character that is not in the iso-8859-1

character set, that character is replaced with a

question mark (?) character for display purposes. For

example, consider a metadata tag name Beta

(containing the Greek letter Beta).  The Beta Character

may not be sent as a HTTP header, so it is replaced in

the returned list as follows:x-emc-tags: mykey1, mykey2, ?eta

========================================================

It seems like the x-emc-listable-tags can contain only iso-8859-1 character set and not UTF8. Since we are using the filename as metadata, setting a special character text in this headers is throwing an error. Do you concur with this?

Kind Regards,

Leo

Your original post implied you were using the namespace API, whose paths are specified in the URL itself.  Tags/metadata are specified in headers.  To enable unicode support in metadata, URL-encode the metadata name and value (if present) and add the following header:

x-emc-utf8=true

Do this *before* signing the request.

You also need to specify x-emc-utf8=true in READ requests for objects that have Unicode metadata.  This header tells Atmos to URL-encode the characters since non-latin characters are not supported in HTTP headers.  So you will need to URL-decode the metadata names and values from the response.

The tool you're using does not appear to do that.

If x-emc-utf8=true is not present, then Atmos will return the x-emc-unencodable-meta header, listing all the metadata tags that have non-latin characters in them (and thus cannot be sent without encoding).

Hi Chris,

I'm also adding support for Atmos filename special character in our product.Objects have unicode metadata. Hence I added the header x-emc-utf8:true. But from the time I added this header I'm getting "ATMOS_MISMATCH_SIGNATURE". Did I miss out anything? Can you please let me know what needs to be taken care in the code when this header is added?

Regards,

Priya

Priya,

If non-latin characters are in the metadata, URL-encode the metadata names and values BEFORE signing the request.  Then sign the request.  If non-latin characters are in the URL path, URL-encode those AFTER signing the request (make sure they are lower-cased when signing).

I highly recommend using one of our SDKs, which take care of signatures for you.  Signatures are also covered in the REST developer's guide on Powerlink (see page 183).

Thanks Chris. I was able to proceed…

Hi Chris,

This question is again related to moving file name with special character.

Atmos 2.1 Programmers guide clearly mentions that file name with @ is not supported.

“Atmos allows any character in the printable ASCII character set in a filename except for

? and @.”

But when we created a file name with @ it moved to Atmos. Can we move a filename with @ to Atmos? If we can move why Atmos 2.1 programmer guide does not support the same? Will it cause any other issues? Can you please let us know your opinion?"

Regards,

Priya

You can use any unicode characters in your paths, provided you URL-encode them appropriately.  The ?rename call uses the x-emc-path header to specify the new name of the object.  In this case, you will need to add x-emc-utf8=true and URL-encode the x-emc-path header.  If the existing path for the object includes unicode characters, you will have to URL-encode the path appropriately as I discussed above.

Renaming to a unicode path is covered on page 125 of the programmer's guide.  General unicode support is covered on page 20.

Remember that when a path (URI) contains unicode characters, you must sign the request before URL-encoding them.

Thanks Chris. I have implemented the logic for URL-encoding. From the mail I understand that we can also move filenames with? and @ if they are properly URL encoded.

Regards,

Priya

Thanks a lot Chris..

Yes, that's correct.  Sorry I didn't clarify.

Hi Chris,

Thanks for your earlier responses which helped me to resolve the issue which we were facing with Unicode characters. I have a similar problem now. When I did the URL encoding (Year back) we tested with earlier version of Atmos (may be 2.0). We were able to move all the characters including #. Now we are observing different behaviour with Atmos 2.1.4 and 2.1.5.

File name starting with # does not move to backend. It is URL encoded.

eg: #1.txt does not move

File name with # inbetween is moved to Atmos taking the characters upto #

eg: test#23.txt . File moves as test.txt

This looks strange. Can you please let us know why this is seen in latest version of Atmos? I did not find any information in programmers guide. Does Atmos support # in filename? Please let us know your inputs.

Regards,

Priya

Hi Priya,

This issue is fixed in the next service pack, 2.1.6.0.