Can't Set ContentType on a String

Dec 13, 2007 at 11:29 PM
Why is Affirma.ThreeSharp.Model.Request.ContentType read-only? This is preventing me from generating an HTML document in memory and making it available on S3 as a publicly-readable document because ThreeSharp isn't letting me assign the content type of an uploaded string programmatically. (Unless there's another way to do this that I'm not seeing.)
Dec 13, 2007 at 11:44 PM
There's another thing that's thwarting me here -- Request.LoadStreamWithBytes has hard-coded the ContentType to "text/plain" which seems wrong. This means that if I force ContentType to be writable it won't matter because trying to use an in-memory string to create a publicly-readable HTML document on S3 won't work -- I can set the ContentType to "text/html" but LoadStreamWithBytes sets it back to "text/plain".
Dec 14, 2007 at 12:30 AM
One more problem with what I'm doing: Request.LoadStreamWithString encodes the string as ASCII, which is almost certainly an error. (If you look at the C# example that Amazon provides, they do it correctly -- since .NET strings are UTF-8 then it should be encoded and stored as UTF-8 as well.)
Dec 14, 2007 at 5:59 AM
Actually, strike that -- the C# S3 sample that Amazon provides hard-codes ASCII encoding as well, which is a bit distressing since it means that there is no .NET library that doesn't have the potential to lose data (through the under-the-covers conversion from native Unicode to ASCII) when saving strings to S3.

Storing files works fine, but storing strings in anything other than a western character set is not going to work as long as this problem exists.
Coordinator
Aug 11, 2008 at 7:54 PM

Hi Jeffrey,

  For Release 1.4, I've switched to UTF8 encoding, which should solve everyone's difficulties with the encoding.  Also, I've added overloads to Request.LoadStreamWithString and Request.LoadStreamWithBytes to allow a developer to set content type manually.

Thanks,
Joel Wetzel
Affirma Consulting