Jump to content
  • Retrieving image fails when url results in 404 not found

    Assigned User lucianc
    CategoryBug report

    The problem occurs when retrieving images using the Image component with an url to an image that results in 404 not found. The report library disregards the status code and reads the content anyway. That content is often a html page explaining that the image is no longer available. It feeds the html and tries so interpret it as a image. As a result, the batik library is loaded and is asked to determine if the image is an svg image.


    We do not ship the batik library along with the report library. As a result a NoClassDefFoundError occurs (see stack trace below).


    We expect that the library checks the status code and simply returns an error in case of a 404. This error can then be captured using the 'on error type' property of the image component.


    To illustrate the problem we added an example report called imageurlpointstohtmlpage.jrxml .


    Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/batik/bridge/UserAgent

    at net.sf.jasperreports.renderers.util.RendererUtil.getSvgDataSniffer(RendererUtil.java:148)

    at net.sf.jasperreports.renderers.util.RendererUtil.isSvgData(RendererUtil.java:107)

    at net.sf.jasperreports.renderers.util.RendererUtil.isSvgData(RendererUtil.java:137)

    at net.sf.jasperreports.engine.export.JRPdfExporter$InternalImageProcessor.process(JRPdfExporter.java:1575)

    at net.sf.jasperreports.engine.export.JRPdfExporter$InternalImageProcessor.access$300(JRPdfExporter.java:1532)

    at net.sf.jasperreports.engine.export.JRPdfExporter.exportImage(JRPdfExporter.java:1472)

    at net.sf.jasperreports.engine.export.JRPdfExporter.exportElements(JRPdfExporter.java:1090)

    at net.sf.jasperreports.engine.export.JRPdfExporter.exportPage(JRPdfExporter.java:1053)

    at net.sf.jasperreports.engine.export.JRPdfExporter.exportReportToStream(JRPdfExporter.java:917)

    at net.sf.jasperreports.engine.export.JRPdfExporter.exportReport(JRPdfExporter.java:537)


    Caused by: java.lang.ClassNotFoundException: org.apache.batik.bridge.UserAgent

    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)

    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)

    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

    ... 16 more

    User Feedback

    Recommended Comments

    Changed Status from New to Feedback Requested

    Changed Assigned User from - to @teodord

    Hi, ThomasWe'll try fix this by using an SVG pre-detector which would not require Batik.This means the image element would fail with some other error, probably telling you that the file was not a valid image file.I'm not sure I understand what you mean by potential security risk. Does this mean we should simply remove the possibility of people loading SVGs for images?Thanks,Teodor
    Link to comment
    Share on other sites

    Hello Teodor


    Thank you for your reply.


    Foremost I think you should check the html status code. If the http request does not yield a valid response (200 status code, i suppose) the library should not try to load image using the contents. The security risk is that a hacker might exploit the fact that the results of other invalid html status code are processed as an image.


    Secondly I think it is very good to give a warning message (some output on the console) that batik is not available and the image could not be loaded. However if we would like to support svg images in the future then by including batik in the distribution should us enable loading svg images.




    Link to comment
    Share on other sites

    Hi, Thomas


    Still trying to figure out the security risk you mentioned.

    Basically, when a certain URL is used in an image element, we expect to receive an image, even if in the form of an SVG.

    Now, are you saying that someone might return as an error, but in the message of the error they would put a malicious SVG?

    Why would they complicate it with an error since they can send the malicious SVG as valid image in the first place?


    In recent distros we no longer ship any JAR. All dependencies are downloaded automatically when you build the library from source or when you run the samples.

    We do not provide a list of required dependencies as the majority of them are optional, depending on what feature of the library you use.

    So if you decide to support SVG, as JR already does, you should look into the pom.xml or in the ivy.xml files to see what Batik dependencies you need and make them part of your own application build.


    I hope this helps.



    Link to comment
    Share on other sites

    Changed Resolution from Open to Fixed

    Changed Status from Feedback Requested to Resolved

    Changed Assigned User from @teodord to @lucianc

    Hi, ThomasWe have improved our image checking code so that when a valid XML comes as image content from the remote URL, we first check if it contains a root node before attempting to use Batik to load the SVG.This way you should get a proper image load failure exception when the 404 response comes back, instead of the NoClassDefFoundError one you got so far.This was committed on Git master branch and will be part of the next release.Thanks,Teodor
    Link to comment
    Share on other sites

  • Create New...