Obiee Errors

§  304 errors in the HTTP cycle

Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle when it communicates with the Web server:

  • Obtain an IP address from the IP name of the site (the site URL without the leading ‘http://’). This lookup (conversion of IP name to IP address) is provided by domain name servers (DNSs).
  • Open an IP socket connection to that IP address.
  • Write an HTTP data stream through that socket.
  • Receive an HTTP data stream back from the Web server in response. This data stream contains status codes whose values are determined by the HTTP protocol. Parse this data stream for status codes and other useful information.

This error occurs in the final step above when the client receives an HTTP status code that it recognises as ‘304’.

§  Fixing HTTP 304 errors – General

You should never see this error in your Web browser. It should simply present the Web page from its cache – because it believes the page has not changed since it was last cached. If your client is not a Web browser, then it should equally be able to present the page from a cache. If unable to do so, it is not using the If_Modified_Since or related headers correctly.

§  Fixing HTTP 304 errors

You should never see this error at all for the CheckUpDown service. It indicates defective programming by us or the developers of the Web server software. Either we or they are not respecting HTTP protocols completely.

The 304 status code should only be returned if we allow it in the HTTP data stream we send to the Web server. Because we keep no records of the actual content of your URL Web page, we specifically disallow the 304 response in the HTTP data stream we send.

So if the Web server implements the HTTP protocol properly, it should never send an 304 status code back to us. This response is not what we expect, so we actively report it as an error even though it does not necessarily mean that the Web site is down.

Please contact us directly (email preferred) whenever you encounter 304 errors. Only we can resolve them for you. Unfortunately this may take some time, because we have to analyse the underlying HTTP data streams and may have to liaise with your ISP and the vendor of the Web server software to agree the exact source of the error.

++++++++++++++++

So enough fade up with HTTP 304… lets see how Oracle proposed to resolve the problem using “HTTP compression and caching” technique.

Why use Web Server Compression / Caching for OBIEE?

o       Bandwidth Savings: Enabling HTTP compression can have a dramatic improvement on the latency of responses. By compressing static files and dynamic application responses, it will significantly reduce the remote (high latency) user response time.

o       Improves request/response latency: Caching makes it possible to suppress the payload of the HTTP reply using the 304 status code.  Minimizing round trips over the Web to re-validate cached items can make a huge difference in browser page load times.

This screen shot depicts the flow and where the compression and decompression occurs.

The Solution:

1.      To implement HTTP compression / caching, install and configure Oracle HTTP Server (OHS) 11.1.1.x for the bi_serverN Managed Servers (refer to “OBIEE Enterprise Deployment Guide for Oracle Business Intelligence” document for details).

2.      On the OHS machine, open the file HTTP Server configuration file (httpd.conf) for editing.

This file is located in the OHS installation directory.
For example: ORACLE_HOME/Oracle_WT1/instances/instance1/config/OHS/ohs1

3.      In httpd.conf file, verify that the following directives are included and not commented out:

LoadModule expires_module “${ORACLE_HOME}/ohs/modules/mod_expires.so

LoadModule deflate_module “${ORACLE_HOME}/ohs/modules/mod_deflate.so

4.      Add the following lines in httpd.conf file below the directive LoadModule section and restart the OHS:

Note: For the Windows platform, you will need to enclose any paths in double quotes (“)

For example:

Alias /analytics “/ORACLE_HOME/bifoundation/web/app”

<Directory “/ORACLE_HOME/bifoundation/web/app”>

Alias /analytics ORACLE_HOME/bifoundation/web/app

#Pls replace the ORACLE_HOME with your actual BI ORACLE_HOME path
bifoundation/web/app>
#We don’t generate proper cross server ETags so disable them
FileETag none
SetOutputFilter DEFLATE
# Don’t compress images
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
<FilesMatch “\.(gif|jpeg|png|js|x-javascript|javascript|css)$”>
#Enable future expiry of static files
ExpiresActive on
ExpiresDefault “access plus 1 week”
#1 week, this will stops the HTTP304 calls i.e. generated by IE 8
Header set Cache-Control “max-age=604800”
</FilesMatch>
DirectoryIndex default.jsp
</Directory>

#Restrict access to WEB-INF
<Location /analytics/WEB-INF>
Order Allow,Deny
Deny from all
</Location>

Leave a comment