Bug with preauth mechanism and SOAP headers?

[Coilcore]

I'm not sure if this is a bug, but it seems like unexpected behavior and I cannot figure out when or why it happens.

Most of the time when doing a preauth request via SOAP, we receive a response that contains a SOAP header with the normal refresh/update data. I have one user that in every case, we don't receive any SOAP header in the preauth request. Unfortunately our existing code is expecting a SOAP header in all cases generating some Null Pointer Excpetions (and isn't a header needed to be a proper SOAP packet, even if the header is empty?)

Its simple enough for us to avoid the Null Pointer Exception, but is this a potential problem that might have bigger ramifications if we continue to receive empty headers for this user. Has anyone else seen this? Is this expected behavior?

[KevinH]

Is this on the GetInfoResponse? Can you post the result of this? Was the user already logged in? Is it an admin user?

[schemers]

The SOAP header element is definitely optional, per spec.

Do you have more then one server? If the user's mailbox is on a different server then where you sent the request then you might endup without any header, as it won't create a session for that user.

Other then that, without seeing the actual SOAP request/response it will be hard to debug.

[Coilcore]

Indeed we do have two nodes as running Zimbra under one virtual host, after the preauth, we do a GetAccountInfoRequest and store the actual server name as a cookie. That cookie is then used by apache to detirmine which zimbra node to proxy requests to.

It certainly makes sense that in the case of doing a preauth on a different server than the mail store it would not be able to provide any information about mail counts. Most of the users are installed on the first node and the user that was failing was on the second node. It also makes sense that that first request is always to the first node, since apache will always proxy to the first node when their is no cookie, so the a user on the second node would always have this problem.

I'm no longer worried. It all makes sense. None the less we're just handling the missing header more gracefully in our SOAP processing.