Bug 794454 (JBEPP-1494)

Release Notes Docs Status: Added: Not Yet Documented

Release Notes Text: Added: PROBLEM: For simulation the problem, it's sufficient to point browser to http://localhost:8080/portal/classic and log all HTTP requests sent by browser. It can be seen that HTTP requests for obtain images (*.jpg, *.gif, favicon.ico, ...) are repeated during each HTTP request to portal page and HTTP response contains header "Cache-control: no-cache" for all images.

CAUSED BY: Problem is caused by incorrect mapping of staticResource handler in controller.xml . StaticResource handler is mapped after PortalRequestHandler, which means that all images are firstly processed by PortalRequestHandler. This is non-sense and it results that incorrect HTTP header "Cache-control: no-cache" is used for images and some non-sense operations are called (like calling DataStorage.getPortalConfig with argument "favicon.ico" ).

SOLUTION: Thing is that images should be processed only by StaticResourceHandler and not by PortalRequestHandler at all. So I changed the order in controller.xml configuration, and I've added StaticResourceHandler before PortalRequestHandler (it was opposite before).

Link: Added: This issue is related to GTNPORTAL-2338

Release Notes Text: Removed: PROBLEM: For simulation the problem, it's sufficient to point browser to http://localhost:8080/portal/classic and log all HTTP requests sent by browser. It can be seen that HTTP requests for obtain images (*.jpg, *.gif, favicon.ico, ...) are repeated during each HTTP request to portal page and HTTP response contains header "Cache-control: no-cache" for all images.

CAUSED BY: Problem is caused by incorrect mapping of staticResource handler in controller.xml . StaticResource handler is mapped after PortalRequestHandler, which means that all images are firstly processed by PortalRequestHandler. This is non-sense and it results that incorrect HTTP header "Cache-control: no-cache" is used for images and some non-sense operations are called (like calling DataStorage.getPortalConfig with argument "favicon.ico" ).

SOLUTION: Thing is that images should be processed only by StaticResourceHandler and not by PortalRequestHandler at all. So I changed the order in controller.xml configuration, and I've added StaticResourceHandler before PortalRequestHandler (it was opposite before).
 Added: PROBLEM: For simulation the problem, it's sufficient to point browser to http://localhost:8080/portal/classic and log all HTTP requests sent by browser. It can be seen that HTTP requests for obtain images (*.jpg, *.gif, favicon.ico, ...) are repeated during each HTTP request to portal page and HTTP response contains header "Cache-control: no-cache" for all images. This is bad from performance perspective on server side (more request for images needs to be processed by server) but also from client side (Images needs to be received from server to client after each HTTP request to portal page, which is bad for bandwidth as network is more burdened because of this).

CAUSED BY: Problem is caused by incorrect mapping of staticResource handler in controller.xml . StaticResource handler is mapped after PortalRequestHandler, which means that all images are firstly processed by PortalRequestHandler. This is non-sense and it results that incorrect HTTP header "Cache-control: no-cache" is used for images and some non-sense operations are called (like calling DataStorage.getPortalConfig with argument "favicon.ico" ).

SOLUTION: Thing is that images should be processed only by StaticResourceHandler and not by PortalRequestHandler at all. So I changed the order in controller.xml configuration, and I've added StaticResourceHandler before PortalRequestHandler (it was opposite before).

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
CAUSE: Problem is caused by incorrect mapping of staticResource handler in
controller.xml . StaticResource handler is mapped after PortalRequestHandler,
which means that all images are firstly processed by PortalRequestHandler. This
is non-sense and it results that incorrect HTTP header "Cache-control:
no-cache" is used for images and some non-sense operations are called (like
calling DataStorage.getPortalConfig with argument "favicon.ico" ).

FIX: Thing is that images should be processed only by
StaticResourceHandler and not by PortalRequestHandler at all. So I changed the
order in controller.xml configuration, and I've added StaticResourceHandler
before PortalRequestHandler (it was opposite before).

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,11 +1 @@
-CAUSE: Problem is caused by incorrect mapping of staticResource handler in
+It was discovered that an incorrect mapping order in controller.xml caused PortalRequestHandler to process images. Because PortalRequestHandler was not designed to process images, incorrect HTTP header information was used for images. The fix corrects the mapping order in controller.xml so StaticResourceHandler is declared before PortalRequestHandler. This ensures the appropriate handler is called to manage images.-controller.xml . StaticResource handler is mapped after PortalRequestHandler,
-which means that all images are firstly processed by PortalRequestHandler. This
-is non-sense and it results that incorrect HTTP header "Cache-control:
-no-cache" is used for images and some non-sense operations are called (like
-calling DataStorage.getPortalConfig with argument "favicon.ico" ).
-
-FIX: Thing is that images should be processed only by
-StaticResourceHandler and not by PortalRequestHandler at all. So I changed the
-order in controller.xml configuration, and I've added StaticResourceHandler
-before PortalRequestHandler (it was opposite before).