Re: patch: cookies string leak
On Fri, Feb 01, 2008 at 06:26:56PM +0000, place wrote:
Also, what would you think of me either
- stuffing the "Cookie2: $Version=\"1\"\r\n" header into a_Cookies_get(url)
OK. Basically the same way referer is handled.
or - adding a function to http.c to accomplish the same thing? ...with a_Cookies_get() changed to show a distinction between don't-want-cookies and don't-have-cookies.
I almost never have any cookies enabled, so I'd prefer not to send the Cookie2 header all of the time when I don't want their cookies.
No problem. Leak patch committed. -- Cheers Jorge.-
Jorge wrote:
On Fri, Feb 01, 2008 at 06:26:56PM +0000, place wrote:
Also, what would you think of me either
- stuffing the "Cookie2: $Version=\"1\"\r\n" header into a_Cookies_get(url)
OK.
attached. I renamed it a_Cookies_get_query() in an effort to suggest that it now returned more than just the cookies. Everything looks fine when I watch the headers, but I don't use dillo for anything that _relies_ on cookies working properly. So...anyone who habitually uses cookies might want to give this a bit of a test.
On Mon, Feb 04, 2008 at 08:10:25PM +0000, place wrote:
Jorge wrote:
On Fri, Feb 01, 2008 at 06:26:56PM +0000, place wrote:
Also, what would you think of me either
- stuffing the "Cookie2: $Version=\"1\"\r\n" header into a_Cookies_get(url)
OK.
attached.
I renamed it a_Cookies_get_query() in an effort to suggest that it now returned more than just the cookies.
Everything looks fine when I watch the headers, but I don't use dillo for anything that _relies_ on cookies working properly.
Committed.
So...anyone who habitually uses cookies might want to give this a bit of a test.
Now that's on CVS it should get a share of testing... -- Cheers Jorge.- PS: sorry for the long wait.
On Mon, Feb 04, 2008 at 08:10:25PM +0000, place wrote:
Jorge wrote:
On Fri, Feb 01, 2008 at 06:26:56PM +0000, place wrote:
Also, what would you think of me either
- stuffing the "Cookie2: $Version=\"1\"\r\n" header into a_Cookies_get(url)
OK.
attached.
I renamed it a_Cookies_get_query() in an effort to suggest that it now returned more than just the cookies.
Everything looks fine when I watch the headers, but I don't use dillo for anything that _relies_ on cookies working properly.
So...anyone who habitually uses cookies might want to give this a bit of a test.
I just noticed that calling current CVS with: http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 completely blocks the browser. It doesn't happen with older dillo2 versions. Please give it a look. -- Cheers Jorge.-
Jorge wrote:
I just noticed that calling current CVS with:
http://www.fltk.org/newsgroups.php?gfltk.general+v:24912
completely blocks the browser.
It doesn't happen with older dillo2 versions.
Please give it a look.
No problems for me, either with or without cookies.
On Wed, Mar 19, 2008 at 07:55:35PM +0000, place wrote:
Jorge wrote:
I just noticed that calling current CVS with:
http://www.fltk.org/newsgroups.php?gfltk.general+v:24912
completely blocks the browser.
It doesn't happen with older dillo2 versions.
Please give it a look.
No problems for me, either with or without cookies.
It consistently hangs the latest CVS for me. I have attached the gdb backtrace. For a while not so long ago one of my ISP's pages also hung Dillo in a_Dpi_send_blocking_cmd() . The problem went away before I got round to investigating it properly. I don't know if it fixed itself due to a change in the page, a change in Dillo or some other factor. I mention it now to point out that this problem *may* have been around for a little while in some form or other (though I can't be certain). Regards, Jeremy Henty
I do not have problem with that page, but ... I have suffer the same problem(i think) in dillo-gtk few times, but can not reproduce it. I am interested in resolve this bug, but do not have time. Now that the problem happen always maybe we can catch the bug. Try to gdb the dpid or cookies.dpi I think the problem is about the cookies.dpi: cookies.dpi can not start, it die before send an answer to dillo and the dpid restart it one and other time with same result. Dillo wait blocked forever the answer(because a_Dpi_send_blocking_cmd()). To recover the blocked dillo you can stop dpid and at the same time kill the various cookies.dpi running. Te reason to have or not to have this problem, can be to have enabled cookies for that site Diego. 2008/3/20, Jeremy Henty <onepoint@starurchin.org>:
On Wed, Mar 19, 2008 at 07:55:35PM +0000, place wrote:
Jorge wrote:
I just noticed that calling current CVS with:
http://www.fltk.org/newsgroups.php?gfltk.general+v:24912
completely blocks the browser.
It doesn't happen with older dillo2 versions.
Please give it a look.
No problems for me, either with or without cookies.
It consistently hangs the latest CVS for me. I have attached the gdb backtrace.
For a while not so long ago one of my ISP's pages also hung Dillo in a_Dpi_send_blocking_cmd() . The problem went away before I got round to investigating it properly. I don't know if it fixed itself due to a change in the page, a change in Dillo or some other factor. I mention it now to point out that this problem *may* have been around for a little while in some form or other (though I can't be certain).
Regards,
Jeremy Henty
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Wed, Mar 19, 2008 at 07:55:35PM +0000, place wrote:
Jorge wrote:
I just noticed that calling current CVS with:
http://www.fltk.org/newsgroups.php?gfltk.general+v:24912
completely blocks the browser.
It doesn't happen with older dillo2 versions.
Please give it a look.
No problems for me, either with or without cookies.
Oh! I'm on dialup now and have: www.fltk.org ACCEPT_SESSION in cookiesrc. It blocks for me on every try... -- Cheers Jorge.-
participants (4)
-
darkspirit5000＠gmail.com -
jcid＠dillo.org -
onepoint＠starurchin.org -
place＠gobigwest.com