Cookies not sent to other web apps on same server

aakoshh

Dear Support,

I am evaluating Lightstreamer using a setup where the LS server is on the same box as the webserver listening on a different port. The server hosts another web application, which sets its session cookie in the browser. After I open up a browser tab to the page with the lightstreamer demo, the first application receives no cookies any more, which breaks authentication and everything. Has anyone ever experienced anything like this? I tried with both NEW_SESSION and SHARE_SESSION. Is this because it uses the same domain? After I close the tab with the ligstreamer demo, the other works like it did before, receiving cookies and all.

I would appreciate any kind of advice.
Thank you,
Aa`Koshh

Mone

Hi,

We've never seen anything like that.
Does this happen with any browser?
Did you try to monitor the cookies on firefox with firebug to see if they are sent to the server?
If not, try to monitor them with firecookie or with a custom javascript and check if and when them disappear.

aakoshh

Hi Mone,

thanks for the reply, I managed to solve it. I don't know why simply checking in Firebug did not occur to me earlier. The cookies were clearly sent, but they were not handled properly on the server. Lightstreamer uses a cookie with a name containing the url address of the streaming server, and so contains illegal characters (":" and "/"), according to the RFC2068 definition. The Django web framework, which I want to use, relies on the Python built-in Cookie module to parse the cookie string, which raises an exception when it finds illegal keys. The exception was, however, silently swallowed by Django and it used an empty cookie dictionary from then on, that's why I did not see anything in my debug views.

Thanks again,
Aa`Koshh

Mone

Hi,

sorry but I can't find where it is stated, in the RFC2068 specs, that : and / are not admitted, can you point me to the correct section?

aakoshh

Hello,

well I am by no means an expert on this, just read it in Python comments.
So, it is RFC 2109 section 4.1 that describes the syntax of cookies (token=word;...) and refers to RFC 2068 to see what the definition of token is (sequence of non-whitespace, non-special characters). Sorry that I didn't mention the 2109 part.
And in 2068, 2.2 Basic Rules, they list what special characters are:

Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted
string to be used within a parameter value.

token = 1*<any CHAR except CTLs or tspecials>

tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT

Best regards,
Aa`Koshh

Mone

Thank you very much for pointing the issue out, you're right, those special characters should not be used unless quoted as cookie values and can't be used at all as cookie names.
We'll correct this issue with our next release, in the meanwhile send me a PM if you need the updated library sooner.

PS: note that RFC 2109 was substituted by RFC 2965 and that 2068 was substituted by 2616, btw the quoted parts were not changed.

aakoshh

Glad I could be of help. For now I'm fine with modifying the web servers cookie parsing routine, so that it does not choke on unexpected inputs, but thanks for the support!
Bests,
Aa`Koshh