One of my Lotus Connections guru friends in the Netherlands had asked me about the headers that are sent from the webserver, Microsoft Internet Information Server in his case, to the WebSphere Plugin.
These are revealed when one enables tracing by setting LogLevel=“Trace” in the Plugin configuration file - plugin-cfg.xml.
He referred me to this forum post: -
IIS websphere plugin headers - Websphere
as he was specifically interested in one heading - $WSAT.
Having checked this most useful reference - Demystifying the IBM Web Server Plug-in - written by Naveen Shetty and Steve Reid from the IBM HTTP Server / WAS Plugin Support Team, I wasn't able to find that specific header, so I had to look further afield.
Thanks to some timely assistance from another IBM colleague, here are the headers explained: -
$WSAT -- The Auth Type that is being used to make this request.
$WSCC -- The Client Certificate used for this request. If value is not base64 encoded for us by the webserver then the plugin will base64 encode it before sending it across to the Application Server.
$WSCS -- The Cipher Suite that the webserver negotiated with the client. This is not necessarily the cipher suite that the plugin will use to send the request across to the Application Server.
$WSIS -- This header will be set to either 'true' or 'false' depending on whether or not the request is secure or not(came in over SSL/TLS).
$WSSC -- The scheme being used for the request. This header will normally be set to either 'http' or 'https'.
$WSPR -- The HTTP protocol level being used for this request. The plugin currently has support for up to HTTP/1.1 requests.
$WSRA -- The remote IP address of the machine the client is running on.
$WSRH -- The remote hostname of the machine the client is running on. If the hostname can't be resolved then this header should be set to the IP address.
$WSRU -- The remote user specified for the given request.
$WSSN -- The server name used for this request. This should be the value that was specified in the HOST header of the incoming request.
$WSSP -- The server port that the request was received on. This will be the port value that is used in route determination.
$WSSI -- The SSL Session ID being used for this request. If the value is not base64 encoded for us by the webserver then the plugin will base64 encode it before sending it across to the Application Server.
So here's hoping that this is of use to my Dutch pal, as well as to other out there ....
2 comments:
This is great! Thanks! But I have encoutered a problem. In my case, the web server is IHS 6.1, and the plug-in is also 6.1. It's very strange that if I doesn't block the request header $WSSP, i.e. the port, requests routed to the cluster will be responsed as 404 File Not Found. If I block this header, the requested page will return back successfully. Do you have any idea how could this happen?
@Shunjing Jin - thanks for your comment. Can you provide some more detail e.g. how are you blocking the $WSSP header ? What exception do you get in the access log and the plugin log when you don't block that header e.g. when you get the 404 ?
Post a Comment