DotNetNuke 7.1 HTML Module converting data:image into URI?

Question

I am unable to use the drag-and-drop functionality within DotNetNuke version 7.1.

The drag-and-drop functionality of the Telerik RadEditor takes the browser's Base64 input and encases it in an img tag where the source is the data. E.g., src="data:image/jpeg;base64,[base64data]".

When using drag/drop to a RadEditor within the HTML Module and then saving the HTML content, that src definition is changed to a URI request by prepending the relative path for the DNN portal. E.g., src="/mysite/portals/0/data:image/jpeg;base64,[base64data]".

This converts what started out as a perfectly valid embedded image tag into a request and thereby causes the browser to request this "image" from the server. The server then returns a 414 error (URI too long).

Example without prepended relative path: http://jsfiddle.net/GGGH/27Tbb/2/

<img src="data:image/jpeg;base64,[stuff]>

Example with prepended relative path (won't display): http://jsfiddle.net/GGGH/NL85G/2/

<img src="mysite/portals/0/data:image/jpeg;base64,[stuff]>

Is there some configuration that I've missed? Prepending relative paths is OK for src="/somephysicalpath" but not for src="data:image...".

Answer 1

I ended up solving the problem prior to posting the question but wanted to add this knowledge to SO in case someone else encountered the same problem (has no one noticed this yet?). Also, perhaps, DNN or the community can improve upon my solution and that fix can make it into a new DNN build.

I've looked at the source code for RadEditor, RadEditorProvider and then finally the Html module itself. It seems the problem is in the EditHtml.ascx.cs, FormatContent() method which calls the HtmlTextController's ManageRelativePaths() method. It's that method that runs for all "src" tags (and "background") in the Html content string. It post-processes the Html string that comes out of the RadEditor to add in that relative path. This is not appropriate when editing an embedded Base64 image that was dragged to the editor.

In order to fix this, and still allow for the standard functionality originally intended by the manufacturer, the DotNetNuke.Modules.Html.EditHtm.ascx.cs, ManageRelativePaths needs to be modified to allow for an exception if the URI includes a "data:image" string at its beginning. Line 488 (as of version 7.1.0) is potentially appropriate. I added the following code (incrementing P as appropriate and positioned after the URI length was determined -- I'm sure there's a better way but this works fine):

// line 483, HtmlTextController.cs, DNN code included for positioning
while (P != -1)
    {
        sbBuff.Append(strHTML.Substring(S, P - S + tLen));


        // added code
        bool skipThisToken = false;
        if (strHTML.Substring(P + tLen, 10) == "data:image")  // check for base64 image
            skipThisToken = true;
        // end added code - back to standard DNN

        //keep characters left of URL
        S = P + tLen;
        //save startpos of URL
        R = strHTML.IndexOf("\"", S);
        //end of URL
        if (R >= 0)
        {
            strURL = strHTML.Substring(S, R - S).ToLower();
        }
        else
        {
            strURL = strHTML.Substring(S).ToLower();
        }

        // added code to continue while loop after the integers were updated
        if (skipThisToken)
        {
             P = strHTML.IndexOf(strToken + "=\"", S + strURL.Length + 2, StringComparison.InvariantCultureIgnoreCase);
             continue;
        }
        // end added code -- the method continues from here (not reproduced)

This is probably not the best solution as its searching for a hard coded value. Better would be functionality that allows the developers to add tags later. (But, then again, EditHtml.ascx.cs and HtmlTextController both hard code the two tags that they intend to post-process.)

So, after making this small change, recompiling the DotNetNuke.Modules.Html.dll and deploying, drag-and-drop should be functional. Obviously this increases the complexity of an upgrade -- it would be better if this were fixed by DNN themselves. I verified that as of v7.2.2 this issue still exists.

UPDATE: Fixed in DNN Community Version 7.4.0