FileRemoteServiceServlet returns wrong data url

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Put some sample *.png image in the folder given as path parameter to the 
servlet.
2. Get the file reference on the client and then use 
FileReader#readAsDataUrl(String) to get it's data url.
3.Create img tag on the webpage and set it's src attribute to data url from 
point 2.

What is the expected output? What do you see instead?
Expected output is image from point 1. Instead there is a "broken image" icon 
which informs that the file is not valid image.

What version of the product are you using? On what operating system?
I'm using 1.2.0.0 from maven central on Ubuntu 10.04 LTS.

Please provide any additional information below.
I looked into the problem and it seems that reason for wrong data url is that 
servlet's readAsDataUrl(String) uses readAsText(String) to get String 
representation of the file. Below rewritten method which returns correct 
results (the image shows up in the browser):

@Override
public String readAsDataUrl(String relativePath) throws FileErrorException {
    File basePath = new File(path);
    File file = new File(basePath, relativePath);
    ensureLocalRoot(basePath, file);

    try {
        byte[] binaryData = FileUtils.readFileToByteArray(file);
        byte[] base64 = Base64.encodeBase64(binaryData);
        String base64String = new String(base64, "UTF-8");
        String mimeType = guessMimeType(file);
        String dataUrl = "data:" + mimeType + ";base64," + base64String;
        //logger.finest("dataUrl: " + dataUrl);
        return dataUrl;
    } catch (IOException e) {
        logger.log(Level.WARNING, "error while reading file", e);
        throw new FileErrorException(FileError.NOT_READABLE_ERR);
    }
}

Original issue reported on code.google.com by grz3gorz...@gmail.com on 13 Jan 2012 at 8:23

[GoogleCodeExporter]

This issue was closed by revision ab2e5f9e4cb3.

Original comment by kurka.da...@gmail.com on 13 Jan 2012 at 8:42

• Changed state: Fixed

[GoogleCodeExporter]

The order of converting to string and base64 encoding seems to be important

Fix is in trunk and will be part of 1.3.0.0

Original comment by kurka.da...@gmail.com on 13 Jan 2012 at 8:42