MantaClient.ILLEGAL_METADATA_HEADERS not exhaustive and only checked from putMetadata

[tjcelaya]

It is possible for users to set encryption-related metadata. In some cases this metadata will simply be overridden (i.e. when passed alongside a regular PUT) but in other cases it will effectively make the object inaccessible. The following code snippet will make it impossible to read a file encrypted with CSE using AES/CTR/NoPadding by squashing it's plaintext length:

client.put(file, localBytes);

MantaMetadata metadata = new MantaMetadata();
metadata.put(MantaHttpHeaders.ENCRYPTION_PLAINTEXT_CONTENT_LENGTH, "illegal");
client.putMetadata(file, metadata);

leading to the following exception when attempting to fetch the object:

Exception in thread "main" java.lang.NumberFormatException: For input string: "illegal"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Long.parseLong(Long.java:589)
	at java.lang.Long.parseLong(Long.java:631)
	at com.joyent.manta.http.EncryptionHttpHelper.httpRequestAsInputStream(EncryptionHttpHelper.java:321)
	at com.joyent.manta.client.MantaClient.getAsInputStream(MantaClient.java:408)
	at com.joyent.manta.client.MantaClient.getAsInputStream(MantaClient.java:434)
	at co.tjcelaya.sandbox.App.main(App.java:110)

[uxcn]

I can think of a few possible solutions...

• add the client encryption metadata to ILLEGAL_METADATA_HEADERS, or similar, in the client interface
• add a token type to provide a type safe authorization mechanism to modify headers that have side effects (work around for jdk less than nine)
• silently (maybe log warnings) drop attempts to modify headers that have side effects

The last is probably the least friction, but could also potentially add extra burden debugging genuine errors.