Monday Feb 15, 2010

Web Server 7.0 appears to be consuming more CPU than Web Server 6.1

The increase in memory usage could be due to the 'auto-tuning' 
    functionality that was introduced in Web Server 7.0U2. (But not yet documented)
    This feature will set some of the servers parameters based on number of CPU's, 
    file descriptors, etc of the actual machines.
    It is possible to see what these are being auto-tuned to by setting the 
    log level to finest, and restarting each server.

    They should see differences between the two boxes.

    The one best thing that can be done is run perfdump to see how much of 
    the set resources are actually being used.  Once you have those figures, you
    can then manually set these values in the server.xml file, which will 
    override any auto-tuning values.

    Web Server 7.0 will definitely require more memory than 6.0, 
    basically because it's architecture is very different.

    So in recap you would want to start by setting the log level to finest 
    on both servers, enabling perfump and restarting them. Then gathering 
    some perfdump data as the memory usage reaches its high levels.  This should 
    allow some thoughts for settingl initial values you might want to set 
    these parameters to.

Wednesday Jan 28, 2009

How to truncate the request URL written to the Web Server 6.1 access log.

Q:  How can I trim the request line written to the access logs so that the whole
    URL is not written but only a piece?

    This can be an important consideration where there is the possibilit that
    sensitive data such as a password may be written to the log files in
    clear text.

example line written to access log: - - [26/Jan/2009:20:53:04 -0500] "GET

and here is what we would like to see:


A:  To accomplish this for a single particular URL as is listed the following
    can be performed:

<Object ppath="\*(\*/ABC/sign/\*)">
AuthTrans fn="set-variable" set-reqpb="clf-request=/ABC/sign/"

The above has the effect of rewriting the clf-request in the access logs
to change it to just /JSO/sign/

This solution will work for one particular URL but to do this for all URL's
it would require the creation of an NSAPI filter.

Tuesday Dec 30, 2008

Is there a way to dynamically set the "Expires" header using WebServer 6.1?

Q: Is there a way to dynamically set the "Expires" header using WebServer 6.1?

A; The answer is "yes" and "no".  Out of the box, this functionality
   is not available for Web Server Version 6.1 (or earlier releases
   for that matter).  A blog site at SUN however does reference some
   other sites that outline how to do this via a customized approach.
   Please see:

   <a href=""> </a>

   ...and note that any undertaking based upon these notes is entirely
   at the risk of the person doing so.  SUN does not support this officially.

   It is possible to also set the expiry header to a static date under
   Web Server 6.1 by doint the following in obj.conf file under default object:

   Output type="image/\*" fn="set-variable" set-srvhdrs="Expires: Mon, 29 Dec 2008 0:00:00 GMT"

   Important Note:

   At Web Server release 7.x this functionality is built in to the webserver!

   For reference, please see the following link:

   <a href=""> </a>

Wednesday Nov 19, 2008

WebServer can log the end client browser's ssl capabilities in the log file

This is pretty nifty....

Apparently, the Sun WebServer can log what the end client browser's encryption capabilities.  The information is picked up during the SSL Handshake.

The %Ses->client.secret-keysize% logs the browsers encryption capablity in the access log.  This would be added to the format line of the access log (its the top line).

Friday Nov 14, 2008

How to extract and log client IP addresses to SUN WebServer when requests forward through a proxy server.

A question arose with a client site in which they wanted to know how
they could extract and log the client ip when the request forwards 
through a reverse proxy.

The situation looked liked this:

Client ------------> Reverse Proxy ------------> Web Server
Client <------------ Reverse Proxy <----------- Web Server

In order to find the IP address of the original client, they wanted to capture the
"X-Forwarded-For" header in web server access log and error log.

The way to do this is by using the custom log format available on the Sun WebServer.

If the reverse proxy is adding:

X-Forwarded-For: header to the request, the Web Server can be configured
to log that header field by adding %Req->headers.x-forwarded-for% to the access log format. 
(Note that the Web Server doesn't add an X-Forwarded-For: header when it reverse proxies requests. 
It does, however, add a Proxy-ip: header).


Gregory Bedigian


« September 2016