-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2 Oct 2010, at 09:19, Christoph Haas wrote:
I'm running a 0.9.7 application (screenshots.debian.net) and this
morning received a paste error in my mail that got me thinking. The
actual exception was:
CookieError: Illegal key value: ,__utma
And the probable cause is this cookie:
HTTP_COOKIE
',__utma=183447588.206002125.1285996917.1285996917.1285996917.1;
__utmb=183447588.2.10.1285996917; __utmc=183447588;
__utmz=183447588.1285996917.1.1.utmcsr=(direct)|utmccn=(direct)|
utmcmd=(none)'
Are cookies beginning with underscores not valid? Or is this an
artificial limitation here? There is another cookie that I found
strange:
Leading underscores are legal syntax. I think it may be the leading /
comma/ in ',__utma=...' that's causing the problem.
RFC2109 states:
NAME=VALUE
Required. The name of the state information ("cookie") is NAME,
and its value is VALUE. NAMEs that begin with $ are reserved
for
other uses and must not be used by applications.
The VALUE is opaque to the user agent and may be anything the
origin server chooses to send, possibly in a server-selected
printable ASCII encoding. "Opaque" implies that the content
is of
interest and relevance only to the origin server. The content
may, in fact, be readable by anyone that examines the Set-Cookie
header.
and with respect to the token...
The two state management headers, Set-Cookie and Cookie, have common
syntactic properties involving attribute-value pairs. The
following
grammar uses the notation, and tokens DIGIT (decimal digits) and
token (informally, a sequence of non-special, non-white space
characters) from the HTTP/1.1 specification [RFC 2068] to describe
their syntax.
av-pairs = av-pair *(";" av-pair)
av-pair = attr ["=" value] ; optional value
attr = token
value = word
word = token | quoted-string
Attributes (names) (attr) are case-insensitive. White space is
permitted between tokens. Note that while the above syntax
description shows value as optional, most attrs require them.
NOTE: The syntax above allows whitespace between the attribute and
the = sign.
so RFC 2068 defines the syntax for the token:
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
Is this some kind of attacker who wants to annoy the Pylons
application
with overly long cookies to see if it fails?
That doesn't look like valid cookie syntax. But anyway....
6.3 Implementation Limits
Practical user agent implementations have limits on the number and
size of cookies that they can store. In general, user agents'
cookie
support should have no fixed limits. They should strive to store
as
many frequently-used cookies as possible. Furthermore, general-use
user agents should provide each of the following minimum
capabilities
individually, although not necessarily simultaneously:
* at least 300 cookies
* at least 4096 bytes per cookie (as measured by the size of the
characters that comprise the cookie non-terminal in the syntax
description of the Set-Cookie header)
* at least 20 cookies per unique host or domain name
User agents created for specific purposes or for limited-capacity
devices should provide at least 20 cookies of 4096 bytes, to ensure
that the user can interact with a session-based origin server.
The information in a Set-Cookie response header must be retained in
its entirety. If for some reason there is inadequate space to
store
the cookie, it must be discarded, not truncated.
Applications should use as few and as small cookies as possible,
and
they should cope gracefully with the loss of a cookie.
6.3.1 Denial of Service Attacks
User agents may choose to set an upper bound on the number of
cookies
to be stored from a given host or domain name or on the size of the
cookie information. Otherwise a malicious server could attempt to
flood a user agent with many cookies, or large cookies, on
successive
responses, which would force out cookies the user agent had
received
from other servers. However, the minima specified above should
still
be supported.
- --
Cheers,
Graham
http://www.linkedin.com/in/ghiggins
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkynTsgACgkQOsmLt1NhivxIPgCeMs1pYj3l/8COobehgwol9SPw
ovYAmgMPMOeu46yNOwUgC0roovecRAo9iQCVAgUBTKdOyFnrWVZ7aXD1AQJTJwQA
1BFfcrQmT+ad2IfJW7p+ze+6SF5eAyynp24wkAGzO7BA3fdhY2l1NRZF+CKjD7Lg
zshCfjG5sZvMLfuKPK1kFCiepTI3ch7bTfs3+xWppAu5ghzgpqRRj8d9xjq8s1bH
K7PWFxoXIVx8tmDuCzNq8rcMuBjTDnsXMFyK6P2+u9Y=
=n+N1
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
