Bad request: LS_Session parameter missing

[lstest]

Hi,

we seem to have a problem with the network connections of one of our clients. We noticed that this client did not receive all of the Lightstreamer message and had a look at the log where we found these errors (this is the first time we have seen this):

24-Feb-10 09:16:22,413 |INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 5 |Serving request: /<OUR PATH>/ control.html? from 206.73.234.4:58899
24-Feb-10 09:16:22,413 |ERROR|LightstreamerLogger.requests |SERVER POOLED THREAD 5 |Bad request: LS_session parameter missing
24-Feb-10 09:16:22,413 |ERROR|LightstreamerLogger.connections |SERVER POOLED THREAD 5 |Failure in request processing: Bad request: com.lightstreamer.b.c: LS_session parameter missing

Do you have any idea what is happening here? What would we or our client need to do to fix this problem?

Regards and many thanks in advance,
Oliver

[Mone]

Hi,

I would like to see the headers of the problematic request.

You can either use a tool like wireshark to snoop such headers or you can set the level of the LightstreamerLogger.connections.http category inside LS_HOME/conf/Lightstreamer_log_conf.xml to INFO (only headers of failed requests are logged).
Note that I'm not sure that this category works this way with a server <3.6 so, if you're using an older version you should make a check by opening in a browser http://path.of.your.server/lightstreamer/control.html (with no params): If in the server log you can see the headers of your request that means that it also works that way with the version you are using.

[lstest]

Hi,

it took some time as we had to switch to 3.6, but now I have some examples of these requests:

25-Feb-10 15:23:37,162 |ERROR|LightstreamerLogger.requests |SERVER POOLED THREAD 29 |Bad request: LS_session parameter missing
25-Feb-10 15:23:37,163 |INFO |htstreamerLogger.connections.http|SERVER POOLED THREAD 29 |Refused failed request:
POST /<OUR PATH>/send_message.js HTTP/1.1
Accept: */*
Referer: http://<OUR HOST>/<OUR PATH>/ajax_frame.html?phase=710&domain=<OUR DOMAIN>&
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Content-Length: 0
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: <OUR HOST>
Cookie: __utma=131542546.2084345808.1266238254.1266474703.1267106628.14; __utmb=131542546.28.10.1267106628; __utmz=131542546.1266238254.1.1.utmcsr=(direct)|utmcmd=(none); __utmc=131542
546; LS4_CE=|198|; LS4_198_CE=1267107938515|N|<OUR DOMAIN>_198_CE; LS4_http://<OUR HOST>=|198_CE|
Pragma: no-cache
Accept-Language: de-ch
Connection: Keep-Alive
X-BlueCoat-Via: 8F4E285D7928C226

from <CUSTOMER's IP>:49537

----------------------------------------

25-Feb-10 16:03:41,098 |ERROR|LightstreamerLogger.requests |SERVER POOLED THREAD 20 |Bad request: LS_session parameter missing
25-Feb-10 16:03:41,098 |INFO |htstreamerLogger.connections.http|SERVER POOLED THREAD 20 |Refused failed request:
POST /<OUR PATH>/send_message.js HTTP/1.1
Accept: */*
Referer: http://<OUR HOST>/<OUR PATH>/ajax_frame.html?phase=888&domain=<OUR DOMAIN>&
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Content-Length: 0
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: <OUR HOST>
Cookie: __utma=131542546.1657268587.1267110103.1267110103.1267110103.1; __utmb=131542546.3.10.1267110103; __utmz=131542546.1267110103.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
__utmc=131542546; LS4_CE=|474|; LS4_474_CE=1267110295468|N|<OUR DOMAIN>_474_CE; LS4_http://<OUR HOST>=|474_CE|
Pragma: no-cache
Accept-Language: de-ch
Connection: Keep-Alive
X-BlueCoat-Via: 8F4E285D7928C226

from <CUSTOMER's IP>:51483

Regards,
Oliver

[Mone]

Hi,

it's clear that the request reaches the server without its parameters; You can see that those requests have content-length 0. This is indeed not correct.

I see that there is a X-BlueCoat-Via header in the request, that suggests that the user is behind a Blue Coat ProxySG (http://www.bluecoat.com/products/sg), btw I can't assume that the problem lies there.

I put here some questions/ideas that could help nail the issue.

Is the problem appearing regularly?

Which kind of problem is experiencing the client? A colleague of mine suggests that those empty requests could be just "echo" requests and that actual requests could have reach the server before.
Setting LightstreamerLogger.connections.http to DEBUG will make the server log headers of every requests; that way could be possible to check if the refused requests are duplicated requests or not by checking the timestamp in the cookies.

Is it possible that the sysadmins of the network of your client are blocking such requests on purpose?

Is it possible to compare the problematic requests as they exit your client's pc (before the proxy handles the request) with the requests received on the server? This would help understand if it's really the proxy that strips the parameters.

[lstest]

Hi,

I have set the logging level to DEBUG instead of INFO when I switch to 3.6. Hence, I can tell you that indeed I can see a correct messages with utma, utmb, utmz and utmc being exactly the same as the ones in the bad request.

These correct requests seem to be sent just before the incorrect request are sent (no requests between these two).

Could this explain that our client does not always receive message or send message correctly to Lightstreamer? Is this a severe issue?

It is probably not possible to check the messages on our clients pc's...

Regards,
Oliver

[Mone]

with utma, utmb, utmz and utmc being exactly the same as the ones in the bad request sorry but I'm not sure that the google analytics cookies are enough to identify a request.
If not (or if you're not sure) try to identify requests through the LS4_XXX_CE cookie, (where XXX is a random number): such cookie contains a timestamp that should be enough to identify a request:

LS4_198_CE=1267107938515|N|<OUR DOMAIN>_198_CE

Obviously if those requests are just duplicates of actual requests minus the parameters, them should not harm the client, but if your client has issues, than or such issues lies elsewhere or those are not duplicated requests.

I don't know anything about their network infrastructure, but obviously if something in the middle removes parameters from http requests we can't do anything about that.