[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev tvgen cookie problem (patch)
From: |
brian j. pardy |
Subject: |
Re: lynx-dev tvgen cookie problem (patch) |
Date: |
Sun, 11 Oct 1998 17:38:37 -0700 |
Ismael Cordeiro wrote:
> On Sun, 11 Oct 1998, brian j. pardy wrote:
>
> > The latest patch I made to cookie handling makes sure that Lynx stores
> > cookies internally in the same order that it reads them from the
> > COOKIE_FILE. I don't think this would be leading Lynx towards broken
> > behavior, and if it helps Lynx be compatible with broken sites (while
> > still following spec) I don't think it's a problem.
>
> I did some comparative tests with pre.9, without and with your patch, using
> the steps proposed by Laura. Here are the steps, numbered for easier
> reference:
>
> (1) First, delete (or move) your cookie file.
> [I emptied .lynx_cookies instead - IC]
> (2) Go to http://www.tvgen.com/tv/listings/
> (3) Cursor down to link 2 ("Enter") and hit return.
> (4) Log on as ricklew with password 3234606
> (5) Cursor down to link 5 ("Search"). Hit return.
>
> (6) Exit lynx. Start up again at http://www.tvgen.com/tv/listings/
> (7) Cursor down to link 2 ("Enter"). Hit return.
Okay, I've got another patch for this. Here are the results of me
following each step with this patch:
pre.9 with my previous patch and new patch (at bottom)
------------------------------------------------------
(2) Got the first page
(3) Got the login page
(4) Got redirected around to the grids page
(which I assume is the proper page -- Netscape brings it up)
(5) Got the search page
(6) Got the first page
(7) Got the grids page
Looks okay to me.
Here's a patch against clean pre.9 -- it contains both my previous patch
and the new one.
The new patch comments out FM's code to fold cookie headers. I did not
want to comment this out, but after looking at the HTTP/1.0 spec, it
appears to be breaking spec by doing that. Please read my comments for my
justification.
diff -cr 2.8.1pre.9/src/LYCookie.c 2.8.1pre.9.bri/src/LYCookie.c
*** 2.8.1pre.9/src/LYCookie.c Mon Sep 28 02:15:11 1998
--- 2.8.1pre.9.bri/src/LYCookie.c Sun Oct 11 17:28:52 1998
***************
*** 501,507 ****
--- 501,522 ----
* if confirmed or 'allow' is set to always. - FM
*/
} else if (HTConfirmCookie(de, hostname, co->name, co->value)) {
+
+ #ifdef EXP_PERSISTENT_COOKIES
+ /*
+ * If the cookie domain came from persistent cookie file,
+ * we want to add new cookies to the end of the cookie list
+ * to maintain their order for servers that need cookies in
+ * a particular order. This is a hack.
+ */
+ if(de->bv = FROM_FILE) {
+ HTList_appendObject(cookie_list, co);
+ } else {
+ HTList_insertObjectAt(cookie_list, co, pos);
+ }
+ #else
HTList_insertObjectAt(cookie_list, co, pos);
+ #endif /* EXP_PERSISTENT_COOKIES */
total_cookies++;
} else {
freeCookie(co);
***************
*** 607,616 ****
/*
* Check if we should fold the header. - FM
*/
! if (len > 800) {
! StrAllocCat(header, crlftab);
! len = 0;
! }
}
/*
* Include the cookie name=value pair.
--- 622,648 ----
/*
* Check if we should fold the header. - FM
*/
!
! /*
! * Section 2.2 of RFC1945 says:
! *
! * HTTP/1.0 headers may be folded onto multiple lines
! * if each continuation line begins with a space or
! * horizontal tab. All linear whitespace, including
! * folding, has the same semantics as SP.
! * [...]
! * However, folding of header lines is not expected by
! * some applications, and should not be generated by
! * HTTP/1.0 applications.
! *
! * This code was causing problems. Let's not use it. -BJP
! */
!
! /* if (len > 800) { */
! /* StrAllocCat(header, crlftab); */
! /* len = 0; */
! /* } */
!
}
/*
* Include the cookie name=value pair.
--
I'm successful because I'm lucky.
The harder I work, the luckier I get.