Thread: Inconsistency in headers

I have a really weird issue which I cannot begin to figure out.

So we have two systems, the client and the webserver. The client sends messages to the webserver, and the webserver responses with messages of its own. To send and receive the messages, we are using the WebServiceMessageCallback class.

The client has a session id. We have a boolean configuration which, when set to true, attaches the session id as a header to the message sent to the webserver. It attaches the session id with the key: "SessionKey". When that boolean is false, the session key should not be attached to the header.

We have a log message on the client side indicating when a header is added to the message. We also have a log on the webserver providing a list of the message headers. We are also watching the message headers with browser dev tools. I just use the ones provided by Chrome, but all of the different tools are showing the same results.

Here is where it gets interesting:
When the boolean value is set to true:
The client logs that a header has been added, the dev tools show the session key in the message header (named "sessionKey" instead of "SessionKey". Not sure if that is important), and the webserver confirms the session key is there. Everything works as expected and there are no problems here.
HOWEVER, when the boolean value is set to false:
The client does not log that a header has been added (this is good), the web server does not find the session key in the header (this is also good), but the dev tools show the session key in the message header (also named "sessionKey")... That right there is the problem.

So I'm at a loss here. I could understand if the dev tools AND the webserver were finding the session key. That would probably indicate that it is being added somewhere other than where we have the log message in the client. But how can the dev tools indicate the session key is in the headers, but the webserver disagrees? And, why has the first "s" in the header key changed to lowercase?

Is it possible the dev tools is loading a cached version of the result? This can be an issue with web browsers at least, in that they can cache page information and when requested to load the data again it loads from a cache rather than refreshing the data from the source.

Actually, I found out what was happening. Apparently we were adding a "sessionKey" variable to messages in some javascript pages when we did some sort of ajax call. I'm not even sure when that was occurring. As it turns out, the header information the web browser tools display doesn't even include any header data that we added to the web service messaging objects in java, but rather only the header information added via the javascript code. So we could add all the header data we wanted in java and none of it would be displayed by the web browser's tools (although it was passed correctly to and from the web server).