glassfish
  1. glassfish
  2. GLASSFISH-18412

Wrong content type on custom error page through mod_jk

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.1
    • Fix Version/s: 4.0_b25
    • Component/s: None
    • Labels:
      None
    • Environment:

      Linux

      Description

      I have a custom 404.html in ../docroot/404.html
      My Glassfish is configured behinde Apache via mod_jk.
      Browsing to a non-existing webapp shows this page nicely.
      BUT browsing to my webapp when it is not working results
      in a web page showing the SOURCE CODE of my 404.html.
      It appears that a HTTP header is wrong in ths particular case.

      See http://www.java.net/forum/topic/glassfish/glassfish/path-custom-default-error-page-resources?force=170

      1. GLASSFISH-18412.patch
        2 kB
        ancoron

        Issue Links

          Activity

          Hide
          Amy Roh added a comment -

          Fixed in the trunk. See GLASSFISH-18396.

          Show
          Amy Roh added a comment - Fixed in the trunk. See GLASSFISH-18396 .
          Hide
          tmpsa added a comment -

          This bug is still present in GF 3.1.2 .
          Will this fix also be available in the upcoming 3.x versions (and not just 4.x)?
          That would be very nice!

          Show
          tmpsa added a comment - This bug is still present in GF 3.1.2 . Will this fix also be available in the upcoming 3.x versions (and not just 4.x)? That would be very nice!
          Hide
          ancoron added a comment -

          Uploaded a different patch for this issue that applies against the 3.1.2 tag: GLASSFISH-18412.patch

          Also attached the resulting artifact: web-core.jar (goes into .../glassfish/modules/)

          Reason for the different fix:

          I have quite some applications (and/or browsers) that rely on the correct content-type being returned (e.g. "application/xhtml+xml" for ".xhtml" files or even an XUL remote rich-client server which must return "application/vnd.mozilla.xul+xml" for ".xul" files).

          The new patch tries to find the correct mime-type to be used as content-type by the error page file path extension. This makes it possible to also fix problems without changing any code in GlassFish by renaming files or editing the "default-web.xml" of the GlassFish instance.

          Show
          ancoron added a comment - Uploaded a different patch for this issue that applies against the 3.1.2 tag: GLASSFISH-18412.patch Also attached the resulting artifact: web-core.jar (goes into .../glassfish/modules/) Reason for the different fix: I have quite some applications (and/or browsers) that rely on the correct content-type being returned (e.g. "application/xhtml+xml" for ".xhtml" files or even an XUL remote rich-client server which must return "application/vnd.mozilla.xul+xml" for ".xul" files). The new patch tries to find the correct mime-type to be used as content-type by the error page file path extension. This makes it possible to also fix problems without changing any code in GlassFish by renaming files or editing the "default-web.xml" of the GlassFish instance.
          Hide
          ancoron added a comment -

          ...had to replace web-core.jar to be compliant with upstream.

          Show
          ancoron added a comment - ...had to replace web-core.jar to be compliant with upstream.
          Hide
          Amy Roh added a comment -

          We will include a fix for the next patch release of GF 3.1.2. Thanks.

          Show
          Amy Roh added a comment - We will include a fix for the next patch release of GF 3.1.2. Thanks.
          Hide
          tmpsa added a comment -

          Glassfish bug 18444 also has has a fix consisting of a patched web-core.jar.
          Does this patched web-core.jar contain a fix for bug 18444, too?

          Show
          tmpsa added a comment - Glassfish bug 18444 also has has a fix consisting of a patched web-core.jar. Does this patched web-core.jar contain a fix for bug 18444, too?
          Hide
          Amy Roh added a comment -

          This attached web-core.jar should include the patch for both 18444 and 18412. Let me know if it does not work for you.

          Show
          Amy Roh added a comment - This attached web-core.jar should include the patch for both 18444 and 18412. Let me know if it does not work for you.
          Hide
          Amy Roh added a comment -

          Opened bug 14400809 so the patch can be included in the 3.1.2.x. sustaining release.

          Show
          Amy Roh added a comment - Opened bug 14400809 so the patch can be included in the 3.1.2.x. sustaining release.
          Hide
          tmpsa added a comment -

          I can't find a Glassfish bug with number 14400809 . Is it a typo?

          Also, I just upgraded to Glassfish 3.1.2.2, and the bug is still present.

          Show
          tmpsa added a comment - I can't find a Glassfish bug with number 14400809 . Is it a typo? Also, I just upgraded to Glassfish 3.1.2.2, and the bug is still present.
          Hide
          Amy Roh added a comment -

          Bug 14400809 is our internal bug id for sustaining team so they can include it in the future patch releases. It appears this patch didn't get included in the 3.1.2.2 release. You can use the attached jar for now.

          Show
          Amy Roh added a comment - Bug 14400809 is our internal bug id for sustaining team so they can include it in the future patch releases. It appears this patch didn't get included in the 3.1.2.2 release. You can use the attached jar for now.
          Hide
          tmpsa added a comment -

          The patch works. Thanks!

          Show
          tmpsa added a comment - The patch works. Thanks!
          Hide
          tmpsa added a comment - - edited

          However... One other thing is still not working!

          Custom default pages only work fully when the webapp is accessed via example.com:8080/myapp, NOT via example.com/myapp (i. e. via mod_jk).

          The web page is shown all right, but <img> tags does NOT work. They DO work when the webapp is accessed via example.com:8080/myapp .

          I have a custom default page for 404 and 503. It is defined in the admin console under
          Configurations > server-config > Virtual servers > server > Additional Properties
          as

          Name Value
          -----------------------------------------------------------
          send-error_1 code=404 path=../docroot/fl-unavailable.html
          send-error_2 code=503 path=../docroot/fl-unavailable.html

          fl-unavailable.html and fl-service.jpg are placed in domain1/docroot .

          fl-unavailable.html contains
          <img src="../fl-service.jpg" alt="Service">

          This image is ONLY shown by the browser when the explicit port number is used in the URL.
          It is not a browser issue; I have tried all of them.

          Am I doing it wrong?

          Is this problem related with this bug, or should we open a new bug for it?

          Show
          tmpsa added a comment - - edited However... One other thing is still not working! Custom default pages only work fully when the webapp is accessed via example.com:8080/myapp, NOT via example.com/myapp (i. e. via mod_jk). The web page is shown all right, but <img> tags does NOT work. They DO work when the webapp is accessed via example.com:8080/myapp . I have a custom default page for 404 and 503. It is defined in the admin console under Configurations > server-config > Virtual servers > server > Additional Properties as Name Value ----------------------------------------------------------- send-error_1 code=404 path=../docroot/fl-unavailable.html send-error_2 code=503 path=../docroot/fl-unavailable.html fl-unavailable.html and fl-service.jpg are placed in domain1/docroot . fl-unavailable.html contains <img src="../fl-service.jpg" alt="Service"> This image is ONLY shown by the browser when the explicit port number is used in the URL. It is not a browser issue; I have tried all of them. Am I doing it wrong? Is this problem related with this bug, or should we open a new bug for it?

            People

            • Assignee:
              Amy Roh
              Reporter:
              tmpsa
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: