- Dillo-dev - lists.mailman3.com

patch: [Dillo-dev] a couple of patches: referer and image_off

by place＠gobigwest.com

linebreaks... diff -pur dillo2/src/IO/http.c dillo2-cur/src/IO/http.c --- dillo2/src/IO/http.c 2008-01-31 23:55:04.000000000 +0000 +++ dillo2-cur/src/IO/http.c 2008-02-01 01:40:08.000000000 +0000 @@ -158,11 +158,11 @@ static char *Http_get_referer(const Dill if (!strcmp(prefs.http_referer, "host")) { referer = dStrconcat("Referer: ", URL_SCHEME(url), "://", - URL_AUTHORITY(url), "/", NULL); + URL_AUTHORITY(url), "/\r\n", NULL); } else if (!strcmp(prefs.http_referer, "path")) { referer = dStrconcat("Referer: ", URL_SCHEME(url), "://", URL_AUTHORITY(url), - URL_PATH_(url) ? URL_PATH(url) : "/", NULL); + URL_PATH_(url) ? URL_PATH(url) : "/", "\r\n", NULL); } if (!referer) referer = strdup("");

Feb. 1, 2008

a couple of patches: referer and image_off

by place＠gobigwest.com

Jorge wrote: > >From the updated dillorc2: > > # Set the HTTP Referer information (WARNING: affects privacy) > * # We use the same URI, not the refering page (to avoid cross-site tracking). > # none : No referer at all (full privacy). > # host : Default value. Send same URI's hostname (no sensible info is sent). > # path : same URI is sent (NO PRIVACY). > http_referer=host What do you mean by "NO PRIVACY"?

Feb. 1, 2008

Various minor patches

by jcid＠dillo.org

On Thu, Jan 31, 2008 at 03:35:56PM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080131 13:25]: > > > > Before this patch, we had no test for iconv. Did it work for you then? > > > In a way yes. because my solution was to add -liconv to my LDFLAGS. > > > > Did the new test in configure.in work? > Nope it did not. > > > You wrote: > > > In a way yes. because my solution was to add -liconv to my LDFLAGS. > > and > > > This breaks configure for me (OpenBSD/386 -stable). seems the > > > test does not use the LDFLAGS=-L/usr/local/lib... My knowledge > > > (and motivation) to fiddle with this autoconf hell is limited, > > > so I'd kindly hand the ball over to someone else. > > > > I assume you set LDFLAGS=-L/usr/local/lib... > > > > but this is expected to be done by the test at configure.in:96. > > The test can fail though! Would you mind posting the output of: > > > > cpp -v > > > > in your system. > > $ cpp -v > Reading specs from /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/specs > Configured with: > Thread model: single > gcc version 3.3.5 (propolice) > /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/cc1 -E -traditional-cpp -quiet -nostdinc -v -I/usr/include -iprefix /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/ -D__GNUC__ - > #include "..." search starts here: > #include <...> search starts here: > /usr/include > End of search list. > > Hope this helps, OK, then configure.in:96 should be adding /usr/local/lib to LDFLAGS. If I understood correctly, the missing part is "-liconv" in LIBS. The CVS has new code for this. Please test, tweak and report back. Making a blind patch with auto*tools is not easy. -- Cheers Jorge.-

Jan. 31, 2008

a couple of patches: referer and image_off

by jcid＠dillo.org

Hi there, - Added a text placeholder: "[IMG]" for img_off mode. - Added a http_referer preference. See details in dillorc2. This couple plays well together. When in img_off mode, non loaded images will show "[IMG]" (or original alt text), and the partial referer helps with getting images from sites that don't allow external sources. >From the updated dillorc2: # Set the HTTP Referer information (WARNING: affects privacy) * # We use the same URI, not the refering page (to avoid cross-site tracking). # none : No referer at all (full privacy). # host : Default value. Send same URI's hostname (no sensible info is sent). # path : same URI is sent (NO PRIVACY). http_referer=host Note: please read the "*"-marked line twice. ;) -- Cheers Jorge.-

Jan. 31, 2008

[PATCH]: improved ROWSPAN handling

by onepoint＠starurchin.org

> Here's a page demonstrating some problems Dillo has when all the cells > in a table have ROWSPAN > 1 . > > http://starurchin.org/dillo/bugs/table_rowspan.html Actually, on second thoughts I'm not so happy with this patch. It resolves all the slack in the row boundaries by pushing them up as far as possible. Let me see if I can get it to spread things out better. Jeremy Henty

Jan. 31, 2008

Various minor patches

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080131 13:25]: > > > Before this patch, we had no test for iconv. Did it work for you then? > > In a way yes. because my solution was to add -liconv to my LDFLAGS. > > Did the new test in configure.in work? Nope it did not. > You wrote: > > In a way yes. because my solution was to add -liconv to my LDFLAGS. > and > > This breaks configure for me (OpenBSD/386 -stable). seems the > > test does not use the LDFLAGS=-L/usr/local/lib... My knowledge > > (and motivation) to fiddle with this autoconf hell is limited, > > so I'd kindly hand the ball over to someone else. > > I assume you set LDFLAGS=-L/usr/local/lib... > > but this is expected to be done by the test at configure.in:96. > The test can fail though! Would you mind posting the output of: > > cpp -v > > in your system. $ cpp -v Reading specs from /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/specs Configured with: Thread model: single gcc version 3.3.5 (propolice) /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/cc1 -E -traditional-cpp -quiet -nostdinc -v -I/usr/include -iprefix /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/ -D__GNUC__ - #include "..." search starts here: #include <...> search starts here: /usr/include End of search list. Hope this helps, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Jan. 31, 2008

[PATCH]: escape illegal characters instead of stripping them

by onepoint＠starurchin.org

On Thu, Jan 31, 2008 at 10:30:37AM -0300, Jorge Arellano Cid wrote: > On Sun, Jan 27, 2008 at 07:15:28PM +0000, Jeremy Henty wrote: > > > > This patch makes Dillo escape all illegal URL characters instead > > of stripping them. > > Committed an improved version. Yes, that *is* neater. I'll remember that! Jeremy Henty

Jan. 31, 2008

Re: patch: image input as submit input

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 07:43:26PM +0000, place wrote: > In which I display my oh-so-impressive ability to, uhhh, uncomment code... :-) > It mostly just allows one to discover that there are lots > of paypal buttons out there. Half-committed. i.e. I left the outer spam_safe if, as an incentive to implement the real image input widget! ;-) -- Cheers Jorge.-

Jan. 31, 2008

[PATCH]: escape illegal characters instead of stripping them

by jcid＠dillo.org

On Sun, Jan 27, 2008 at 07:15:28PM +0000, Jeremy Henty wrote: > > HREF attributes often contain unescaped spaces, even though this is > illegal. This is unfortunate because Dillo deletes illegal URL > characters, which breaks the link. See, eg. > > http://www.labreporter.com/Films.html > > This patch makes Dillo escape all illegal URL characters instead of > stripping them. Committed an improved version. -- Cheers Jorge.-

Jan. 31, 2008

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 03:40:52PM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:36]: > > On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote: > > > * Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]: > > > > On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > > > > > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > > > > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > > > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > > > > > 1) detect_libiconv.diff > > > > > > > > > > > > > > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > > > > > > > > > > is not in the default linker path, making the build abort. Add > > > > > > > > > > a simple test to configure.in to check for libiconv's presence > > > > > > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am. > > > > > > > > > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > > > > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > > > > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > > > > > but it turned out that the problem was caused by a libiconv > > > > > > > package that was no longer needed. The iconv stuff is now handled > > > > > > > in libc on DragonFly... > > > > > > > > > > > > I have attached the log. Seems like the function signature differs > > > > > > on OpenBSD a bit. The testcase modified as such that it includes > > > > > > <iconv.h> and calling iconv_open("",""); works for me when doint > > > > > > it manually. > > > > > > > > > > > > I don't know what happens here... > > > > > > > > > > > > Kind regards, > > > > > > > > > > Does it fail with current CVS? > > > > > > > > Sorry, from the log it's clear it doesn't. > > > > > > > > This page seems to have good info: > > > > > > > > http://synflood.at/blog/index.php?/plugin/tag/bsd > > > > > > > > (my understanding of German is barely for survival. ;). > > > > > > > > > > Yes it does describe my problem, but how do we fix this in a portable way? > > > > > > Before this patch, we had no test for iconv. Did it work for you then? > > > In a way yes. because my solution was to add -liconv to my LDFLAGS. Did the new test in configure.in work? I assume not because of the silence. You wrote: > In a way yes. because my solution was to add -liconv to my LDFLAGS. and > This breaks configure for me (OpenBSD/386 -stable). seems the > test does not use the LDFLAGS=-L/usr/local/lib... My knowledge > (and motivation) to fiddle with this autoconf hell is limited, > so I'd kindly hand the ball over to someone else. I assume you set LDFLAGS=-L/usr/local/lib... but this is expected to be done by the test at configure.in:96. The test can fail though! Would you mind posting the output of: cpp -v in your system. -- Cheers Jorge.-

Jan. 31, 2008