Re: Cookie support

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

hi Mike,

> It appears cookie support is not consistent and leads to some
> inconsistent behavior in the programs.

You've discovered a good site to test things with. They are doing some 
unusual (in my experience) things with cookies, and that'll be good for 
stress testing my code.

> I created a small test program to go to www.yahoo.com and see what I
> get.  Some of the cookies on the site are embedded in javascript and
> so I don't think those are relevant as LIBHTTP does not use a
> javascript engine

I didn't follow that... how can a cookie be embedded in JavaScript!?  If 
the browser has loaded a cookie, JavaScript can read it...  but the 
browser does have to load it first!  So _all_ cookies have to be handled 
in the HTTP layer, they can't exist purely in JavaScript.

> call mv001
> Application error.  MCH3601 unmonitored by HTTPAPIR4 at statement
>    0000005129, instruction X'0000'.
> call mv001
> Application error.  MCH3601 unmonitored by HTTPAPIR4 at statement
>    0000005129, instruction X'0000'.

This seems to be a bug in cookie_read().  It didn't do that when I wrote 
the cookie support (several years ago) so it must be some sort of 
regression.  I'll fix it.

> We end up with only two entries for CH instead of the 9 distinct ones
> that firefox found. We reject or don't write all other cookies for
> some reason.

Several of the cookies are expired, and therefore won't appear.  This is 
a common "trick" -- if you have a cookie you want to delete from a 
browser's cookie file, you send the same cookie name, but use an expired 
date.  This forces the browser to change the cookie's date to the 
expired one -- and therefore, it won't be sent again later.

These cookies are also being set to the string "deleted" (which isn't a 
keyword -- it's the actual value stored inside the cookie) -- presumably 
this is done to wipe out any data that was stored there.

HTTPAPI removes deleted records from the cookie file immediately, so 
these shouldn't show up.  We should have 5 cookies in the file.

> Many are rejected for bad domain, others I assume are not written
> because they are either expired or "deleted" (is that a special
> value?)

The bad domain thing seems to be a bug...  I don't understand why I have 
this code in HTTPAPI...   it says that any domain that doesn't start 
with a '.' is invalid -- and that's not true.  I'm thinking I used an 
"OR" where I meant to code an "AND" -- but I don't remember the purpose 
of that code, anymore.

> I can match up the CH in the debug file to the first CH in the file
> above...not sure where the second one is coming from.

The server is first deleting the CH cookie, then it's sending a new one. 
  It should only result in a single record in the cookie file.

> This must be some technical thing as I saw on the CH that the
> domain parses as .yahoo.com while the others parsed as www.yahoo.com.

When the server sends .yahoo.com, it should be sent back to any host 
that ends in .yahoo.com.  This includes www.yahoo.com, but also includes 
groups.yahoo.com, mta6.am0.yahoo.com, and even yahoo.com

whereas when the domain is set to www.yahoo.com (with no leading dot) 
then it only matches www.yahoo.com. It should not match yahoo.com, 
groups.yahoo.com -- it also should not match test.www.yahoo.com, (even 
though that ends with 'www.yahoo.com') because it's missing the leading 
dot.  However, HTTPAPI has code to reject anything without a leading dot 
-- so that's a bug.

> In firefox, I think they are shown with leading "." on both the
> yahoo.com and www.yahoo.com entries. Does this mean we need to add a
> "." when parsing?

They shouldn't be...   That may be a bug in Firefox?  But I'm not going 
to worry about it.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------