Issue Details (XML | Word | Printable)

Key: GLASSFISH-18412
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Amy Roh
Reporter: tmpsa
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

Wrong content type on custom error page through mod_jk

Created: 27/Feb/12 09:18 AM   Updated: 02/Oct/12 01:12 PM   Resolved: 27/Feb/12 06:09 PM
Component/s: None
Affects Version/s: 3.1.1
Fix Version/s: 4.0_b25

Time Tracking:
Not Specified

File Attachments: 1. Text File GLASSFISH-18412.patch (2 kB) 10/Jul/12 02:09 PM - ancoron
2. Java Archive File web-core.jar (1.09 MB) 28/Sep/12 10:10 PM - Amy Roh
3. Java Archive File web-core.jar (1.09 MB) 01/Aug/12 07:32 PM - Amy Roh
4. Java Archive File web-core.jar (1.09 MB) 10/Jul/12 02:15 PM - ancoron

Environment:

Linux

Issue Links:
Duplicate
 

Tags: mod_jk 3_1_2-next
Participants: Amy Roh, ancoron and tmpsa


 Description  « Hide

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



Amy Roh added a comment - 27/Feb/12 06:09 PM

Fixed in the trunk. See GLASSFISH-18396.


tmpsa added a comment - 03/Jul/12 12:12 PM

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!


ancoron added a comment - 10/Jul/12 02:09 PM

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.


ancoron added a comment - 10/Jul/12 02:15 PM

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


Amy Roh added a comment - 10/Jul/12 04:24 PM

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


tmpsa added a comment - 30/Jul/12 12:20 PM

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?


Amy Roh added a comment - 01/Aug/12 07:32 PM

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


Amy Roh added a comment - 01/Aug/12 09:07 PM

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


tmpsa added a comment - 27/Sep/12 10:10 AM

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.


Amy Roh added a comment - 28/Sep/12 10:10 PM

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.


tmpsa added a comment - 02/Oct/12 12:19 PM

The patch works. Thanks!


tmpsa added a comment - 02/Oct/12 01:11 PM - 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?