problems with module Cookie

[Manlio Perillo]

Hi.
I'm using the Cookie module (on the client side).
I have found a problem trying to parse the cookie:

"Set-Cookie: value=thevalue; path=/;
expires=Fri, 21-May-2004 10:40:51 GMT"

The date is not parsed correctly, only "Fri," is matched.
Thanks and regards Manlio Perillo

[John J. Lee]

Manlio Perillo <NO************ ******@libero.i t> writes:
[...]

Standard Cookie module (with my corrections) plus httplib module is
really all I need.
Cool.

Yes, there exists programs that are simple (as there exist programming
languages that are simple)!

Actually what I do is to download several files from a server.
Some files/pages are generated by a script (so I have to post an
x-www-form-urlencoded string).

I don't want to use urllib2 because it (as I think) for every request
connects to the server, do the request and disconnect.

Yes, that's true. I should fix it...

I need cookies because the server (as many other) authenticate user
with cookies.
So the simple algorithm is:

-connect to the server
-read a cookie from a file
-send the cookie to the server
-if the server send a cookie, the old one must be updated: with
standard Cookie this is simple: cookie.update(n ewcookie)
- ...
- save the cookie to a file
This is very simple to do with httplib and Cookie modules, so why to
use more involved modules?

No reason at all if you're happy with it, of course. That was what my
"Cool" was meant to communicate.

*Using* urllib2 is less involved even than your little algorithm
above, of course (neglecting bugs, of course, including the persistent
connection bug, which -- though it could certainly be a problem -- I
confess has never actually troubled me, despite having used it to
repeatedly fetch tens of millions of records in the past).

Why use modules whose *implementation * is more involved? Because
they're even easier to use, and because, even for simple scripts like
your's, not every case is as simple as the one you happen to have met.
I know from experience that it can quickly get *very* tiresome to do
some of this stuff by hand (even if only a few things like
redirections and cookies are involved). And personally, I don't even
like to *think* about it, or to have to maintain it in future if I can
avoid it, regardless of how simple (ignoring for the moment that I
have to maintain the library itself ;-).

As for why the complications.. . well, if you want to know, read the
code (no, don't :-).
John

[Manlio Perillo]

On 31 May 2004 01:56:10 +0100, jj*@pobox.com (John J. Lee) wrote:

I need cookies because the server (as many other) authenticate user
with cookies.
So the simple algorithm is:

-connect to the server
-read a cookie from a file
-send the cookie to the server
-if the server send a cookie, the old one must be updated: with
standard Cookie this is simple: cookie.update(n ewcookie)
- ...
- save the cookie to a file
This is very simple to do with httplib and Cookie modules, so why to
use more involved modules?
No reason at all if you're happy with it, of course. That was what my
"Cool" was meant to communicate.

*Using* urllib2 is less involved even than your little algorithm
above, of course (neglecting bugs, of course, including the persistent
connection bug, which -- though it could certainly be a problem -- I
confess has never actually troubled me, despite having used it to
repeatedly fetch tens of millions of records in the past).

Why use modules whose *implementation * is more involved? Because
they're even easier to use, and because, even for simple scripts like
your's, not every case is as simple as the one you happen to have met.

You are right, but: what means 'easier to use'?
There is less code to write?
There is less theory to learn?

For my script using urllib2 does not make the program easier.
I know from experience that it can quickly get *very* tiresome to do
some of this stuff by hand (even if only a few things like
redirections and cookies are involved).

In my case cookie are very easy to use and I simply ignore
redirection...

Of course I agree with you for all other cases, but there exist
programs that really needs only low level library.

Actually, ad example, standard Cookie module is low level.
It only parses key=value pairs, and, more important, it is 'other
library' neutral.
That is, BaseCookie class has a parse method for parsing a string
(as SetCookie: key=value; ....), and an OutputString (added by me)
that returns the cookie data.

Thanks and regards Manlio Perillo

[John J. Lee]

Manlio Perillo <NO************ ******@libero.i t> writes:

On 31 May 2004 01:56:10 +0100, jj*@pobox.com (John J. Lee) wrote: [...]

This is very simple to do with httplib and Cookie modules, so why to
use more involved modules?

No reason at all if you're happy with it, of course. That was what my
"Cool" was meant to communicate.

[...] Of course I agree with you for all other cases, but there exist
programs that really needs only low level library.
Was that not what I said? Sorry if I'm not making myself clear!
(What follows is unrelated to your (quite unnecesary!) extended
defence of your use of Cookie in your script, but just by the way of
commentary on the points you make)
Actually, ad example, standard Cookie module is low level.
Yes. The low-level stuff it does is not not always the right thing
for client-side code, though.

It only parses key=value pairs, and, more important, it is 'other
library' neutral.

[...]

Same goes for ClientCookie. The interface required of request and
response objects is defined in the docs. For doing what ClientCookie
does (automatic cookie handling), I don't think it can get much
simpler.
John

[Manlio Perillo]

On 01 Jun 2004 20:28:03 +0100, jj*@pobox.com (John J. Lee) wrote:

Manlio Perillo <NO************ ******@libero.i t> writes:

On 31 May 2004 01:56:10 +0100, jj*@pobox.com (John J. Lee) wrote:[...]

>> This is very simple to do with httplib and Cookie modules, so why to
>> use more involved modules?
>
>No reason at all if you're happy with it, of course. That was what my
>"Cool" was meant to communicate.

[...]

Of course I agree with you for all other cases, but there exist
programs that really needs only low level library.

Was that not what I said? Sorry if I'm not making myself clear!

I'm sorry but I not a very expert in english language...

(What follows is unrelated to your (quite unnecesary!) extended
defence of your use of Cookie in your script, but just by the way of
commentary on the points you make)

Actually, ad example, standard Cookie module is low level.
Yes. The low-level stuff it does is not not always the right thing
for client-side code, though.

Why?

It only parses key=value pairs, and, more important, it is 'other
library' neutral.[...]

Same goes for ClientCookie. The interface required of request and
response objects is defined in the docs.

Ok, but I don't want to write additional code for implementing request
and response interface...
For doing what ClientCookie
does (automatic cookie handling), I don't think it can get much
simpler.

Ok. But my program is already very simple using Cookie.

Thanks and regards Manlio Perillo