Add option to WAResponse>>#document: to send documents without (re)encoding them about seaside HOT 4 OPEN

I am not a Seaside specialist, let alone on any port, but I don't think it is Seaside's job to fix encoding issues or other trouble.

If you have a String that is actually UTF-8 encoded bytes, then the problem is how you got there, it should be fixed there and then.

Obviously Seaside is capable of serving any binary file correctly (as it does in its file libraries in lots of variations), so technically anything should be possible.

from seaside.

I am not a Seaside specialist, let alone on any port, but I don't think it is Seaside's job to fix encoding issues or other trouble.

This is exactly the rationale behind the issue, you should be able to send a WADocument with whatever content and encoding you want and Seaside should not alter it. By default it encodes it, but if you want to send it as is you should have an option.

If you have a String that is actually UTF-8 encoded bytes, then the problem is how you got there, it should be fixed there and then.

I agree with this as well... but if WAFileLibrary compiles as a return String the extensions for which it interprets as non-binary MIME types, then you're on Seaside's hands. Compiling everything read from disk as ByteArray should have been the initial choice, but here we are...

from seaside.

This is exactly the rationale behind the issue, you should be able to send a WADocument with whatever content and encoding you want and Seaside should not alter it. By default it encodes it, but if you want to send it as is you should have an option.

I am pretty sure that already works, after all that is what the file library and handler already do (i.e. taking bytes, as for an image and serving them unaltered with any mime type). At least as far as I can see in Pharo / Seaside 3.

Are you sure this is not related the VAST Seaside port/implementation ? Did you try anywhere else ?

from seaside.

I did not try, but now I did and I noticed GRPharoPlatform>>readFileStreamOn:do:binary: forces the input stream to be valid UTF-8, so anything other than valid UTF-8 cannot be read.
So If I want to read an ISO-8859-1 or Windows 949 (Korean) encoded file in Pharo, it doesn't work (I tried).

I guess it is because it forces a "MIME type" to be compiled as a String (or WideString), instead of being a ByteArray. So in Pharo, for UTF-8 encoded files, each character in the literal compiled string will be a Character with a valid Unicode codepoint (without any clustering), which when reencoded in the output will produce the same UTF-8 bytes.

I'll think in how to work around this, maybe the changes must be applied ONLY in the VAST adaptor layer, as I don't foresee anything changing GRPharoPlatform>>readFileStreamOn:do:binary: to read non UTF-8 encoded files.

Thanks for the input.

from seaside.