Question

I’m using the PrimeFaces FileUpload component for transferring the .properties files into the server. However, extension is not everything, so I wanted to test the behaviour when something else is posted. I’ve uploaded sample jar file (apache commons codec to be specific), but instead of possible exception in stack trace I’ve came across the strange behaviour of the browser: the dialog content collapsed completly and was not available (IE).

I’ve opened JavaScript console and I’ve found out the more fundamental errors.

On FireFox, there’s the jQuery error, but the dialog does not collapse:

NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIDOMLSProgressEvent.input]

On IE 9, however, there’s an error from rendering engine:

XML5617: Ungültiges XML-Zeichen. 
form.xhtml, Zeile 3 Zeichen 3926

The XML answer contains binary content, such as the content of the uploaded file would be attached into it. Searching for possible PrimeFaces bugs I’ve found the following: primefaces fileupload filter with utf8 characters filter but I don’t know how could it apply to my case, since I’m not storing the content into String, I’m operating directly on UploadedFile object:

public void onPropertyFileUpload(FileUploadEvent event) {
    log.info("onPropertyFileUpload");
    if (event.getFile() == null) {
        log.warn("Empty file!!!");
        return;
    }
    Properties props = new Properties();
    try {
        props.load(event.getFile().getInputstream());
    } catch (IOException e) {
        log.error(e.getMessage(), e);
        return;
    }

So, is the bug in MultipartRequest found by BalusC the cause of this problem in my case, or this is something else? And, the most important, what can I do to avoid this bug?

Answer 1

At first I’ve looked at primefaces fileupload filter with utf8 characters filter and I thought this may be the case, but after the analyse of the PrimeFaces code I’ve found out that this is something complete else.

The bug is in fact in PrimeFaces, but deeply hidden. The bug is that they make no correct escaping of the texts they embed in XML response. My code was converting the file into String, which was available for editing and therefore sended to the user. Because uploaded file was binary, and PrimeFaces makes no correct escaping, the XML was broken.

Because there’s actually not way to say in Java that the String is correct (no decoding error!), I’d have to use the code which I’ve seen a few times in other projects (shouldn’t it at least be put into Apache commons-lang?)

/**
     * This method ensures that the output String has only
     * valid XML unicode characters as specified by the
     * XML 1.0 standard. For reference, please see
     * <a href="http://www.w3.org/TR/2000/REC-xml-20001006#NT-Char">the
     * standard</a>. This method will return an empty
     * String if the input is null or empty.
     *
     * @param in The String whose non-valid characters we want to remove.
     * @return The in String, stripped of non-valid characters.
     */
    public String stripNonValidXMLCharacters(String in) {
        StringBuffer out = new StringBuffer(); // Used to hold the output.
        char current; // Used to reference the current character.

        if (in == null || ("".equals(in))) return ""; // vacancy test.
        for (int i = 0; i < in.length(); i++) {
            current = in.charAt(i); // NOTE: No IndexOutOfBoundsException caught here; it should not happen.
            if ((current == 0x9) ||
                (current == 0xA) ||
                (current == 0xD) ||
                ((current >= 0x20) && (current <= 0xD7FF)) ||
                ((current >= 0xE000) && (current <= 0xFFFD)) ||
                ((current >= 0x10000) && (current <= 0x10FFFF)))
                out.append(current);
        }
        return out.toString();
    }

The source of the solution: https://kr.forums.oracle.com/forums/thread.jspa?threadID=1625928