[GLASSFISH-18412] Wrong content type on custom error page through mod_jk Created: 27/Feb/12  Updated: 02/Oct/12  Resolved: 27/Feb/12

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: 3.1.1
Fix Version/s: 4.0_b25

Type: Bug Priority: Major
Reporter: tmpsa Assignee: Amy Roh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Attachments: Text File GLASSFISH-18412.patch     Java Archive File web-core.jar     Java Archive File web-core.jar     Java Archive File web-core.jar    
Issue Links:
duplicates GLASSFISH-18396 send-error html source displayed if J... Resolved
Tags: 3_1_2-next, mod_jk


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

Comment by Amy Roh [ 27/Feb/12 ]

Fixed in the trunk. See GLASSFISH-18396.

Comment by tmpsa [ 03/Jul/12 ]

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!

Comment by ancoron [ 10/Jul/12 ]

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.

Comment by ancoron [ 10/Jul/12 ]

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

Comment by Amy Roh [ 10/Jul/12 ]

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

Comment by tmpsa [ 30/Jul/12 ]

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?

Comment by Amy Roh [ 01/Aug/12 ]

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

Comment by Amy Roh [ 01/Aug/12 ]

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

Comment by tmpsa [ 27/Sep/12 ]

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

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

Comment by Amy Roh [ 28/Sep/12 ]

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 release. You can use the attached jar for now.

Comment by tmpsa [ 02/Oct/12 ]

The patch works. Thanks!

Comment by tmpsa [ 02/Oct/12 ]

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

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?

Generated at Wed Aug 31 17:07:04 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.