Errors using HttpUseridModule

Hi guys,

I’m using the HttpUseridModule for storing session ids of our users.

We’re receiving a lot of errors lately concerning the format of the
userid cookie.

Basically there are two types of errors:

[error] 1581#0: *20523638 client sent invalid userid cookie
“sid=“Cvwk2lLYLvhh3gYtDscPAg==”; $Path=”/"" while reading response
header from upstream, client: xx.xx.xx.xx, server: , request: “GET
/xxxx/xxxx HTTP/1.1”, upstream: “http://xxxxxxxxxxxxxx”, host:
“xxxxxxxxxxxxxxxxx”

and

[error] 1582#0: *17018740 client sent too short userid cookie
“sid=Cvwkcept: /”, client: xx.xx.xx.xx, server: xxxxxxxxx, request:
“GET /xxxxxx HTTP/1.0”, host: “xxxxxxx”, referrer: “http://xxxxxxxxxxx

And I’m using this configuration for userid

userid on;
userid_name sid;
userid_expires 31d;
userid_path /;

Can you help me?

Thank you in advance,
Gabriel Arrais

On Thu, Jan 16, 2014 at 09:41:25PM +0100, Gabriel Arrais wrote:

Hi there,

We’re receiving a lot of errors lately concerning the format of the
userid cookie.

Is there any pattern to the errors that you can see?

Are they all coming from a particular browser version, for example?

[error] 1581#0: *20523638 client sent invalid userid cookie
“sid=“Cvwk2lLYLvhh3gYtDscPAg==”; $Path=”/"" while reading response

It looks to me like nginx does not expect the quotes after the =.

They are unnecessary, but I think that they are possibly allowed by
rfc 2109.

If they are allowed, then nginx should probably be changed to accept
them. If they are not, then the client should probably be changed not
to send them.

[error] 1582#0: *17018740 client sent too short userid cookie
“sid=Cvwkcept: /”, client: xx.xx.xx.xx, server: xxxxxxxxx, request:

It looks to me like something – client, server, or just the display –
has gotten confused and mixed together the Cookie: header with probably
an Accept: header. I don’t think there’s much that can be done about
this, apart from try to identify the culprit and see if it is something
repeatable and fixable.

If it is an identifiable problem in nginx, then I’m sure there’ll be
interest in fixing it.

Cheers,

f

Francis D. [email protected]

Thank you for the answer Francis!

Francis D. wrote in post #1133390:

On Thu, Jan 16, 2014 at 09:41:25PM +0100, Gabriel Arrais wrote:

Hi there,

We’re receiving a lot of errors lately concerning the format of the
userid cookie.

Is there any pattern to the errors that you can see?

Are they all coming from a particular browser version, for example?

For now, I can’t see any pattern and the error logs (how they are
formatted now) does not help me, they don’t pass the user-agent data.

[error] 1581#0: *20523638 client sent invalid userid cookie
“sid=“Cvwk2lLYLvhh3gYtDscPAg==”; $Path=”/"" while reading response

It looks to me like nginx does not expect the quotes after the =.

They are unnecessary, but I think that they are possibly allowed by
rfc 2109.

If they are allowed, then nginx should probably be changed to accept
them. If they are not, then the client should probably be changed not
to send them.

Yes, I think if that is the case, nginx could be more permissive…

[error] 1582#0: *17018740 client sent too short userid cookie
“sid=Cvwkcept: /”, client: xx.xx.xx.xx, server: xxxxxxxxx, request:

It looks to me like something – client, server, or just the display –
has gotten confused and mixed together the Cookie: header with probably
an Accept: header. I don’t think there’s much that can be done about
this, apart from try to identify the culprit and see if it is something
repeatable and fixable.

I see that in this case maybe the client corrupted the cookie data
unfortunately… Anyway I will leave here another log entry with the same
error but a different value in the cookie.

2014/01/15 23:46:50 [error] 1577#0: *18789665 client sent too short
userid cookie “sid=”, client: xx.xx.xx.xx, server: xxxxxxx, request:
“GET /xxxxx HTTP/1.1”, host: “xxxxxxx”, referrer: “http://xxxxxxxxxxxxx

If it is an identifiable problem in nginx, then I’m sure there’ll be
interest in fixing it.

Cheers,

f

Francis D. [email protected]

On Thu, Jan 16, 2014 at 11:15:55PM +0100, Gabriel Arrais wrote:

Francis D. wrote in post #1133390:

Hi there,

Are they all coming from a particular browser version, for example?

For now, I can’t see any pattern and the error logs (how they are
formatted now) does not help me, they don’t pass the user-agent data.

Error logs usually don’t include that information. Access logs
frequently
do, and it is often possible to tie log lines together based on
timestamp
and url. If you have the information, it may be a useful data point to
see whether the problems are associated with only one specific old
version
of a browser, where newer versions of the same thing browser no problem,
for example.

If they are allowed, then nginx should probably be changed to accept
them. If they are not, then the client should probably be changed not
to send them.

Yes, I think if that is the case, nginx could be more permissive…

Reading more closely, I still can’t tell whether the surrounding quotes
are actively forbidden; but they are certainly advised against unless
the cookie was flagged as new, which I think nginx default ones are not.

I would tend to invite the client to become fixed, or invite the user
to change clients. But that’s because it costs me nothing to do so.

Anyway I will leave here another log entry with the same
error but a different value in the cookie.

2014/01/15 23:46:50 [error] 1577#0: *18789665 client sent too short
userid cookie “sid=”, client: xx.xx.xx.xx, server: xxxxxxx, request:

There the cookie named “sid” has no value. I suspect more information
will be needed to know what is happening here – was it somehow set
blank by something else running through nginx? Or is it an attempt by
the client to see what happens when they manually change things?

Good luck with it,

f

Francis D. [email protected]

Francis D. wrote in post #1133402:

On Thu, Jan 16, 2014 at 11:15:55PM +0100, Gabriel Arrais wrote:

Francis D. wrote in post #1133390:

Hi there,

Are they all coming from a particular browser version, for example?

For now, I can’t see any pattern and the error logs (how they are
formatted now) does not help me, they don’t pass the user-agent data.

Error logs usually don’t include that information. Access logs
frequently
do, and it is often possible to tie log lines together based on
timestamp
and url. If you have the information, it may be a useful data point to
see whether the problems are associated with only one specific old
version
of a browser, where newer versions of the same thing browser no problem,
for example.

I will try do this.

If they are allowed, then nginx should probably be changed to accept
them. If they are not, then the client should probably be changed not
to send them.

Yes, I think if that is the case, nginx could be more permissive…

Reading more closely, I still can’t tell whether the surrounding quotes
are actively forbidden; but they are certainly advised against unless
the cookie was flagged as new, which I think nginx default ones are not.

I would tend to invite the client to become fixed, or invite the user
to change clients. But that’s because it costs me nothing to do so.

It’s very difficult to do this in our product =/

Anyway I will leave here another log entry with the same
error but a different value in the cookie.

2014/01/15 23:46:50 [error] 1577#0: *18789665 client sent too short
userid cookie “sid=”, client: xx.xx.xx.xx, server: xxxxxxx, request:

There the cookie named “sid” has no value. I suspect more information
will be needed to know what is happening here – was it somehow set
blank by something else running through nginx?

I have nothing running through nginx that could be corrupting this
cookie

Or is it an attempt by
the client to see what happens when they manually change things?

Maybe, but I don’t think that it is the case…

Good luck with it,

f

Francis D. [email protected]

Thank you again Francis!

Gabriel Arrais [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs