subject:"\[issue2193\] Cookie Colon Name Bug"

Luke Plant  added the comment:

@ David Murray:

Thanks for taking the time to look at this - can I trouble you to keep going 
and read my response?

Thanks. 

You wrote:

> IMO the thing that needs to be fixed here is that receiving an invalid cookie 
> makes it difficult to receive the valid cookies.

I agree absolutely, and my patch implements exactly that aim. So I don't 
understand why the rest of your reply goes on to assume a very different goal - 
handling RFC-invalid cookies such that we can read their values. 

> I'd love to accept your patch, but "silently ignore" sounds like a bad 
> idea and is something we try to avoid in Python where practical.

"silently ignore" is what the current BaseCookie implementation does for 
**every other** type of invalid input, with the only exception (I can find) 
being the case where everything is correct apart from the name:

>>> from Cookie import SimpleCookie
>>> c = SimpleCookie()
>>> c.load('rubbish')
>>> c

>>> c.output()
''
>>> c.load('more:rubbish')
>>> c

>>> c.load('name=value')
>>> c

>>> c.load('name=value; invalidattribute;')
>>> c.output()
'Set-Cookie: name=value'
>>> c.load('xyz123"sfs;;=-abc')
>>> c

>>> c.load('namewith:colon=value')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/Cookie.py", line 632, in load
self.__ParseString(rawdata)
  File "/usr/lib/python2.7/Cookie.py", line 665, in __ParseString
self.__set(K, rval, cval)
  File "/usr/lib/python2.7/Cookie.py", line 585, in __set
M.set(key, real_value, coded_value)
  File "/usr/lib/python2.7/Cookie.py", line 460, in set
raise CookieError("Illegal key value: %s" % key)
Cookie.CookieError: Illegal key value: namewith:colon

As you said, I think this ticket is about fixing that last one, which is the 
gross exception to the rule, and the only thing that is causing major problems 
for people.

I agree that handling cookies with invalid names so that we can read them would 
be nice, but I think it is **very** difficult to find a rationale for saying 
that this bug fix should have to wait for that change.

In addition, I do not think there is any sensible way to implement that 
suggestion given the API of BaseCookie at the moment - it's not just the 
implementation I baulked at, it is the API of BaseCookie that works against you 
every step of the way.

The API of BaseCookie works like this in the typical case:

Consuming:

input -> load()-> store in BaseCookie -> __getitem__()

Generating:

input -> __setitem__() -> store in BaseCookie -> output()

(Of course you don't have to do it that way, but looking at the docs and 
examples, http://docs.python.org/library/cookie.html, it's very clear that it's 
meant to be used that way).

The fact that both modes involves storing in BaseCookie really messes up any 
attempt to make these two work differently, and means you would have a really 
surprising and strange API whichever way you do it.

So, option (1): you could allow BaseCookie to store invalid cookie names if 
they come via load, but not via __setitem__(). This means that you've got an 
easy work-around for BaseCookie refusing to store your value - just use 
'load()' instead. It also means that simple code like this fails:

>>> c['name:val'] = c['name:val']

which can be a problem if you are trying to do some generalised processing of 
the contents of a BaseCookie.

This leads us to option (2): allow RFC-invalid cookies to be stored, but then 
quietly sanitise (i.e. discard) in output().

But this becomes a much worse example of "silently ignoring" - the former is 
tolerant handling of data that is outside the programmers control - Postel's 
law. But this would be accepting incorrect data from a programmer, and then 
silently discarding it, is what we should do our utmost to avoid.

Neither of these options is any good, and it is because the API of BaseCookie 
was just not designed for it. The only sensible things to do, given our API, is 
sanitise on input. We could have an 'RFC-invalid' mode, but it would have to be 
turned on for the whole Cookie instance, and it would be a feature addition. An 
alternative implementation would be a 'badmorsels' attribute which preserves 
the rubbish where possible, in case you want it - but again, it's a feature 
addition.

Finally, I think the behaviour you are aiming at is unreasonable to ask for, 
especially in this ticket. You are essentially asking for a tolerant kind of 
cookie parsing which does its best to do 'do-what-I-mean'. But:

1) You haven't specified further than that (and there are no RFCs of use)
2) in general that kind of thing is notoriously hard to get right
3) the job is never finished - there are always more cases of invalid cookies 
that you *could* handle
4) and in fact it is impossible to provide an implementation that pleases 
everyone - there will always be invalid cookies that were 'meant' to be one 
thing, but the implementation interprets in a different way.

Do we r

[issue2193] Cookie Colon Name Bug


Luke Plant  added the comment:

I had a quick look, and there are these relevant bits:

<< There are two audiences for this specification: developers of 
cookie-generating servers and developers of cookie-consuming user agents. >>

And:

<< To maximize interoperability with user agents, servers should limit 
themselves to the well-behaved profile defined in Section 4 when generating 
cookies. >>

So, the document doesn't tell servers how to parse cookies, only how to 
generate them.

With regards to generation, there is basically no change - we still disallow 
programmers to set cookie names that are not a 'token', as defined by section 4 
of that document, which is the same as RFC 2109 in terms of valid cookie names 
if you look at it. It is not obvious to me that Python's BaseCookie 
implementation obeys RFC 2109 (due to the way character lists are defined in 
the opposite way), but if you believe the comments in the module then it does.

I haven't read the rest of RFC 6265 and checked BaseCookie against it - that 
would be a much bigger job. But with respect to the change in my patch, it 
looks like we are all OK.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-06-29 Thread R. David Murray


R. David Murray  added the comment:

Thanks for taking a crack at this.  IMO the thing that needs to be fixed here 
is that receiving an invalid cookie makes it difficult to receive the valid 
cookies.  I'd love to accept your patch, but "silently ignore" sounds like a 
bad idea and is something we try to avoid in Python where practical.  In the 
email package we have a mechanism for reporting RFC violations (the defects 
attribute).  And we make as much sense of the input as we can, even if it is 
invalid, and preserve it.  We even allow generation of some RFC-invalid stuff, 
though we have plans to make applications work harder to do that in the future.

So I think your harder fix (accept the RFC-invalid cookies as long as there is 
some sensible way to parse them, but reject creating them) is the right 
approach.  I could also see the possibility of accepting a feature request for 
adding the ability to explicitly create RFC-invalid cookies, if someone can 
demonstrate a use case for doing so.  Other possible follow-on feature requests 
would be a 'defects' facility and/or a way to explicitly request that 
non-compliant cookies be ignored.

Note that in suggesting we reject creating RFC-invalid cookies by default I am 
not expressing an opinion on the relevance of the RFCs to cookie processing "in 
the wild".  Given that there is a standard and we are talking about what to do 
on generation, the obvious answer (by Postel's law) is that we ought to 
generate standards-compliant cookies.

Also note that I have not looked at the referenced rfc (here is what I believe 
is the official link: http://tools.ietf.org/html/rfc6265).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-06-29 Thread karl


karl  added the comment:

@Luke

did you have the opportunity to look at 
http://greenbytes.de/tech/webdav/rfc6265.html 

If there is something which doesn't match reality in that document that would 
be cool to have feedback about it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


Changes by Luke Plant :


Removed file: http://bugs.python.org/file22514/issue2193_patch_python27.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


Changes by Luke Plant :


Removed file: http://bugs.python.org/file22513/issue2193_patch_trunk.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


Luke Plant  added the comment:

Same against Python 2.7

--
Added file: http://bugs.python.org/file22516/issue2193_patch_2_python27.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


Luke Plant  added the comment:

Found a bug with patch - this supersedes old one.

--
Added file: http://bugs.python.org/file22515/issue2193_patch_2_trunk.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


Luke Plant  added the comment:

Same patch backported to python 2.7 branch

--
Added file: http://bugs.python.org/file22514/issue2193_patch_python27.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


Luke Plant  added the comment:

First, I agree with others who say that RFCs are basically irrelevant for 
cookies. For Django we've discovered this in various ways e.g. issue 9824 - 
http://bugs.python.org/issue9824 - which has now been applied. We have also had 
to work around the stdlib behaviour here.

Second, I have implemented a patch for this, with tests, against trunk - please 
review.

After looking at the implementation, this seems like the best way to make 
Python conservative in what is produces and liberal in what it accepts, which 
seems to be what the thread converged on. BaseCookie will now silently discard 
cookie 'morsels' with a colon in their name (and all other irregularities) when 
loading from a string, rather than raise an exception.

This allows cookie parsing to continue, so that other cookies in the HTTP 
header will be found.

However, if in Python code you attempt to directly set a morsel with an illegal 
name, you will still get the error.

There is a more lax strategy: Simply add ':' to the _LegalChars variable.

This would allow morsels to be *read* that have a colon in their name. However, 
from the current implementation, it would be very hard to add that ability 
without also allowing the BaseCookie class to produce such cookies. This would 
also raise other issues about at what point an error should be raised for 
setting invalid cookies etc.

Also, allowing these illegal cookies to be read is a corner case that is much 
less important - it isn't needed either for Trac or for our needs in Django.

For these reasons, I decided against the more lax strategy.

--
keywords: +patch
nosy: +spookylukey
Added file: http://bugs.python.org/file22513/issue2193_patch_trunk.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-06-12 Thread Terry J. Reedy


Changes by Terry J. Reedy :


--
versions: +Python 3.3 -Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


Changes by Carsten Klein :


--
nosy: +carsten.klein -carsten.kl...@axn-software.de

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-04-05 Thread Ezio Melotti


Changes by Ezio Melotti :


--
nosy:  -carsten.klein

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


Carsten Klein  added the comment:

Perhaps the best solution would be for the Python cookie module to
gracefully adapt to servers not quoting cookie values as is required
by the RFCs and make these quoted-strings instead?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


Carsten Klein  added the comment:

Ups forgot to also mention the production rule for token, which is defined in 
the HTTP RFC RFC2616:

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

and here it clearly states that a value that is not a quoted string
must not contain colons, and other characters as is specified by separators.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


Carsten Klein  added the comment:

Guess you are right...

I did overlook the quoted-string reference in the RFC:

   av-pair =   attr ["=" value]; optional value
   attr=   token
   value   =   word
   word=   token | quoted-string

The actual production rules for quoted-string are not specified, so I guess 
that anything resembling unicode data would be allowed in that string provided 
that:

[...] from RFC 2109
10.1.3  Punctuation

   In Netscape's original proposal, the values in attribute-value pairs
   did not accept "-quoted strings.  Origin servers should be cautious
   about sending values that require quotes unless they know the
   receiving user agent understands them (i.e., "new" cookies).  A
   ("new") user agent should only use quotes around values in Cookie
   headers when the cookie's version(s) is (are) all compliant with this
   specification or later.

in RFC 2965 there is no such notice...

However, and this is important, the cookie values not matching token must be 
quoted by the origin server upon setting and the client must return these as 
quoted strings as well.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-04-04 Thread BM


BM  added the comment:

To Carsten Klein:
It would be great if you turn your eyes on and try to read more carefully 
before posting something here.


NAME=VALUE 
NAME is the cookie’s name, and VALUE is its value. Thus the header Set-Cookie: 
id=waldo sets a cookie with name id and value waldo. Both the cookie NAME  and 
its VALUE may be any sequence of characters except semi-colon, comma, or 
whitespace. 


In the above it says "any sequence of characters" EXCEPT a three characters: 
1. semi-colon
2. comma
3. whitespace

In English this means that "any sequence of characters" INCLUDES a colon and 
thus colon IS a valid character. BTW, this stupid bug is three years old, while 
the rest of the world implemented it right (Java, Ruby etc).

Also Python implementation of this part is at least... strange (being polite 
here). Because instead of excluding illegal chars, they actually going opposite 
by including the entire world and then going mad in the whole code inside... :-(

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-02-03 Thread Carsten Klein


Carsten Klein  added the comment:

Besides that, BM is wrong in the assumption that *who ever he is* Davi M. 
Kristol states that the colon is a valid character.
There is no such notion in the article. In fact, DMK repeats the definition 
found in the original RFC on cookies, which also was referred to in the follow 
up RFC and then again referred to in the current RFC which seeks to get rid of 
the set-cookie2 directive, combining the two RFCs into a single RFC/pseudo 
standard.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-02-03 Thread Carsten Klein


Carsten Klein  added the comment:

if you'd take a close look at the following lines accepted as part of the patch 
for stripping out unwanted/non standard cookies over trac:

+try:
+old_set(key, real_value, coded_value)
+except CookieError:
+bad_cookies.append(key)

then you will find that trac actually behaves just like what is requested in 
the "original" RFC, namely that the colon is part of the reserved or special 
characters not meant for inclusion with the cookie name or, as it was stated in 
the referred rfc, the token.

Please do not fix.

--
nosy: +carsten.kl...@axn-software.de

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-01-30 Thread John J Lee


John J Lee  added the comment:

I agree with And Clover that Carsten Klein's comments in #msg127366 are not 
correct, for the reason that And stated.

Also, Carsten repeats again the idea that the trac issue is about the trac 
server failing to generate appropriate cookies -- but that issue was in fact 
about trac's processing of cookies generated by servers other than trac.  In 
that particular case, the other server was probably under the control of the 
same group of people, but that isn't true in general.  Please read all the 
comments before adding more comments.

Re #msg127368: I don't think the patch applied to trac is relevant here.  
"Somebody" should write a patch for module Cookie, and then it can be reviewed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-01-29 Thread karl


karl  added the comment:

@aclover
see my comment http://bugs.python.org/issue2193#msg125423
Adam Barth is working for Google on Chrome. 
The RFC being written is made in cooperation with other browser developers.

If you have comments about this RFC you are welcome to add comment on freenode 
at #whatwg.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-01-29 Thread And Clover


And Clover  added the comment:

@carsten.klein: there is no such thing as an “original RFC”. The RFCs that have 
been produced on the subject of cookies, 2109 and 2965, were drawn up long 
after user-agents implemented cookies. Their attempts to clean up the warts of 
cookies and implement new features have completely failed. Their strictures are 
not obeyed by user agents; they are irrelevant and should not be used as the 
basis for any server-side cookie implementation.

The nearest to an original standard for cookies is the Netscape cookie-spec 
(see eg http://curl.haxx.se/rfc/cookie_spec.html), which is far too woolly to 
really count as a real specification, but which allows all but `;`, `,` and 
space, and in practice browsers do typically allow all characters that do not 
already serve as delimiters. Python should be liberal in what it accepts.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-01-28 Thread Carsten Klein


Carsten Klein  added the comment:

One more: if you look closer at the accepted patch by CMLENZ over @ t.e.o., you 
will find:


 if self.req.headers_in.has_key('Cookie'):
-self.incookie.load(self.req.headers_in['Cookie'])
+#self.incookie.load(self.req.headers_in['Cookie'])
+cookie = self.req.headers_in['Cookie']
+old_set = self.incookie._BaseCookie__set
+bad_cookies = []
+def safe_set(key, real_value, coded_value):
+try:
+old_set(key, real_value, coded_value)
+except CookieError:
+bad_cookies.append(key)
+dict.__setitem__(self.incookie, key, None)
+# override Cookie.set to ignore cookies with parse errors
+self.incookie._BaseCookie__set = safe_set
+   # load the cookie values
+self.incookie.load(cookie)
+# clean up the Cookie.set overriding
+self.incookie._BaseCookie__set = old_set
+for key in bad_cookies:
+del self.incookie[key]
+


which will eventually delete all cookies that do not match the original 
production rule.

Besides that, the original poster of the issue forgot to properly limit the 
cookies set by the other site to just a single host path, so these invalid 
cookies got routed to the trac instance running on some different host.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-01-28 Thread Carsten Klein


Carsten Klein  added the comment:

Personally I believe that this is WONTFIX.

Why?

Because, the original RFC states that the colon is part of the unwanted 
characters, regardless of whether Perl or other similar implementations ignore 
the standard.

Besides that, and most important: The cookies are always set by the server or 
application thereof. Therefore, the server must behave just like what is stated 
in the original RFC. And it must also expect existing browsers to behave just 
like what is requested in the RFC.

IMO, the original requester and supporters, both here and over on the trac 
issue tracker are simply not able to figure out a proper cookie tracking 
mechanism for marketing or whatever purposes. Or, perhaps, they want to exploit 
some unwanted behaviour in existing user agents, who knows.

Besides that, if the original poster and follow up requesters supporting the 
issue persist on using a non standard implementation of the cookie library, 
hey, who cares. Let them figure out how to patch or rewrite the existing 
library, and how to include it with their favourite server/user agent 
exploiting implementation.

And the same is true for the request on the trac issue tracker. Since the 
cookies are set by the server, there is no need to actually weaken the existing 
pseudo standard by incorporating ways to hierarchically define a cookie name 
other than what is already present in the scheme or could be accomplished using 
different characters other than those blacklisted.

--
nosy: +carsten.klein

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


John J Lee  added the comment:

Yes, interoperability is good.  Do you have a specific concern about the change 
that I proposed?

If not, and you're instead just trying to ensure conformance, by all means read 
the draft specification that you pointed out and look for reasons why my 
suggested change would be the wrong thing to do -- that would certainly be 
useful.  Otherwise, it's hard to respond to non-specific "are you doing the 
right thing" questions with anything other than "yes" ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


John J Lee  added the comment:

Yes, interoperability is good.  Do you have a specific concern about the change 
that I proposed?

If not, and you're instead just trying to ensure conformance, by all means read 
the draft specification that you pointed out and look for reasons why my 
suggested change would be the wrong thing to do -- that would certainly be 
useful.  Otherwise, it's hard to respond to non-specific "are you doing the 
right thing" questions with anything other than "yes" ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-01-05 Thread karl


karl  added the comment:

agreed. :)

Then my question about parsing rules for libraries. Is interoperability a plus 
here.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug


John J Lee  added the comment:

Again, I don't think this is relevant, because the bug is about servers parsing 
Cookie: headers.  Note that that string (the value of the Cookie: header) may 
be generated by a different server than the server that parses it (see the trac 
example mentioned in the bug comments).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

2011-01-05 Thread karl

karl added the comment:

John: Ah sorry, if I misunderstood. The bug seems to say that it is about the
Cookie Name and legal chars for this cookie name. What I was trying to say is
that the processing of the Cookie Name is different depending if you are a
client or a server *and* that there is a specification being developed by Adam
Barth (part of browser vendors) to obsolete RFC 2109.

In the case of Server sending to the Client
Set-Cookie: Name=Value

The rules for production of the cookies must be strict. Always. aka the module
is used for creating a cookie and indeed the "colon" character is forbidden.
The "token" syntax for valid chars and invalid chars are defined now in
RFC2696. It means that any US-ASCII characters EXCEPT those are authorized:

control characters (octets 0-31) and DEL (octet 127) and, the following
characters “(“, “)”, “<”, “>”, �...@”, “,”, “;”, “:”, “", “/”, “[“, “]”, “?”,
“=”, “{“, “}”, the double quote character itself, US-ASCII SP (octet 32) or the
tabulation (octet 9)

Then if you use the Cookie Module for a client it is not anymore the same story.

In the case of Client storing the value of the cookie sent by a server.
See the section "5.2. The Set-Cookie Header",
http://tools.ietf.org/html/draft-ietf-httpstate-cookie-20#section-5.2

quote:

If the user agent does not ignore the Set-Cookie header
field in its entirety, the user agent MUST parse the
field-value of the Set-Cookie header field as a
set-cookie-string (defined below).

NOTE: The algorithm below is more permissive than the
grammar in Section 4.1. For example, the algorithm strips
leading and trailing whitespace from the cookie name and
value (but maintains internal whitespace), whereas the
grammar in Section 4.1 forbids whitespace in these
positions. User agents use this algorithm so as to
interoperate with servers that do not follow the
recommendations in Section 4."

/quote

then the algorithm is described. Which means that what the server will parse
will not be necessary what the server have generated.

Section 5.4 says how the Cookie Header should be sent to the server with an
algorithm for what will receive the server.

John, do you think there is a missing algorithm for parsing the value of cookie
header when sent by the client?

___
Python tracker

___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug