- Dillo-dev - lists.mailman3.com

[patch]: refactor Auth_parse_auth_basic()

by jcid＠dillo.org

On Mon, Dec 29, 2008 at 01:37:05PM +0000, Jeremy Henty wrote: > > This patch implements a previous suggestion to break up > Auth_parse_auth_basic() into smaller functions and eliminate gotos. > Please comment. Committed. It's much easier to understand/maintain with short functions. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 2, 2009

Best wishes for 2009!

by jcid＠dillo.org

Hi there, Please receive my best wishes for this new year 2009! We've come a long way since dillo restarted, and progress in several fronts has improved the browser a lot. Thanks to you all for the good work!!! > Amyway, it looks like 2009 will be an exciting year for Dillo. In the hope of it coming true, I just sent Johannes an image handling patch series for CSS to work properly with stylesheet loading. Just wait for his signal after he commits to download and enjoy the new code. Note: I'm still working on it, but it's quite usable "as is". -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 2, 2009

We have competition!

by Beartooth＠swva.net

On Thu, 1 Jan 2009, Jeremy Henty wrote: > > Linux Weekly News covers Hv3, a Tcl-based lightweight browser. > > http://lwn.net/Articles/311823/ > > They refer to Dillo as "perhaps the best known minimalist browser"! > It's worth reading the comments to see what people want to see in a > lightweight browser and what they don't miss if it's not there. They > certainly appreciate the speed. That sounds like my cue. In case anyone is interested, Dillo has been my default browser for about four or five years -- and almost nothing in this thread nor on the sites mentioned means a thing to me; most of it I never heard of till now. Noticeably often Dillo can't or won't display what I click on -- somewhere between 1 time in 10 and 1 in 100 -- closer to the less frequent end. So be it; that fact alone, or it plus some message the site gives me (e.g., "You need mxzstplk; download it here.") may tell me whether to skip it. If not, I have four or so bigger slower browsers open all the time on other work-spaces, anyway. (Opera, Firefox, Galeon, and usually Epiphany; sometimes Konqueror; occasionally Kazehakase, Midori, or Seamonkey. I use Firefox for NoScript; Opera for redirects (which I dis-automate); and so on.) Having those already launched makes it fast to switch work-spaces, add or overwrite a tab, and try the reject there. (I can usually guess from Dillo and the URL itself which to pick, nearly always on the first try.) The really big things, to at least this one not quite clueless user (who wouldn't know a line of code if it bit me), are what they've always been, and I hope will remain : safety and speed. In particular, I run a couple of small private lists, most of whose subscribers use one form or another of Windows; I don't allow attachments of any sort; and I urge people to send links instead. So I have lots of sites to vet. (Until recently, I ran lists only manually.) For that, Dillo is invaluable. If Dillo displays a site, it's likely to be safe -- and I can guess whether my subscribers will be interested. If not, that one next look will likely tell me what I need to know. In any case, better by far that I, with Dillo, linux (Fedora 10), hard & soft firewalls, etc., should look -- rather than some poor soul with negligible defenses. I hope this helps. -- Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User I have precious (very precious!) little idea where up is. I try to be paranoid, but I just can't keep up.

Jan. 2, 2009

We have competition!

by onepoint＠starurchin.org

On Thu, Jan 01, 2009 at 11:44:14PM +0000, corvid wrote: > Jeremy wrote: > > Maybe SEE would be a way to support JavaScript in Dillo? > > Justus wrote a bit about SEE and others: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005065.html Oh yes, I remembered this but forgot that it discussed SEE. (New Year's resolution: stop trusting my memory!) That's a pretty impressive performance gap! I guess that's the price you pay for being simple. I'll still have a look at SEE once their website is back. Regards, Jeremy Henty

Jan. 2, 2009

We have competition!

by sas＠321.hu

Hv3 is slow, Dillo rokz, btw, what about i18n? On Thu, Jan 1, 2009 at 11:38 PM, Jeremy Henty <onepoint(a)starurchin.org>wrote: > > Linux Weekly News covers Hv3, a Tcl-based lightweight browser. > > http://lwn.net/Articles/311823/ > > They refer to Dillo as "perhaps the best known minimalist browser"! > It's worth reading the comments to see what people want to see in a > lightweight browser and what they don't miss if it's not there. They > certainly appreciate the speed. > > Hv3 claims to support CSS, but I'm not seeing it: Slashdot and the BBC -- SZERV?C Attila - zeneszerz? http://google.com/search?q=szerv?c <http://google.com/search?q=szerv%C3%A1c>

Jan. 2, 2009

We have competition!

by corvid＠lavabit.com

Jeremy wrote: > Hv3 is also supposed to support Javascript through SEE, but the SEE > site is not responding right now so I can't try it out (and comments > suggest that getting it into a source build is broken). Maybe SEE > would be a way to support JavaScript in Dillo? Justus wrote a bit about SEE and others: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005065.html

Jan. 2, 2009

We have competition!

by onepoint＠starurchin.org

Linux Weekly News covers Hv3, a Tcl-based lightweight browser. http://lwn.net/Articles/311823/ They refer to Dillo as "perhaps the best known minimalist browser"! It's worth reading the comments to see what people want to see in a lightweight browser and what they don't miss if it's not there. They certainly appreciate the speed. Hv3 claims to support CSS, but I'm not seeing it: Slashdot and the BBC look almost exactly the same as they do in Dillo. Mind you, I'm running it from the latest CVS and getting plagued with Tcl errors too, so maybe it's just temporarily broken. Hv3 is also supposed to support Javascript through SEE, but the SEE site is not responding right now so I can't try it out (and comments suggest that getting it into a source build is broken). Maybe SEE would be a way to support JavaScript in Dillo? Amyway, it looks like 2009 will be an exciting year for Dillo. Jeremy

Jan. 1, 2009

[patch]: refactor Auth_parse_auth_basic()

by onepoint＠starurchin.org

This patch implements a previous suggestion to break up Auth_parse_auth_basic() into smaller functions and eliminate gotos. Please comment. Jeremy Henty

Dec. 29, 2008

patch: Accept-Language header

by furaisanjin＠gmail.com

Hi, I like this patch because google works better for none English with accept language header. Regards, furaisanjin

Dec. 29, 2008

patch: Accept-Language header

by corvid＠lavabit.com

For people who don't want to always get language-of-place-where-I'm-physically-located.

Dec. 29, 2008

Re: CSS loading part#2

by jcid＠dillo.org

On Sun, Dec 28, 2008 at 05:30:07PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Dec 25, 2008 at 10:43:06AM -0300, Jorge Arellano Cid wrote: > > > Hi, > > > > > > On Sun, Dec 21, 2008 at 04:48:42PM -0300, Jorge Arellano Cid wrote: > > > > Hi Johannes, > > > > > > > > Here I'm attaching the second part of the CSS loading patch. > > > > This one is coherent and works better :-). Please commit after > > > > some testing. > > > > > > > > Note: images are still truncated sometimes, but AFAIS this is a > > > > problem in the dicache, not in CSS loading. I hope to fix this > > > > soon. > > > > > > Well, in fact, images were always truncated when the repush > > > caught them still rendering. > > > > > > I've been working on this for days and yes, it's a problem in > > > the dicache. Unfortunately the cache/dicache/image-decode/image > > > code is so entangled that it needs a rewrite. Quite surprising it > > > works stable "as is". > > > > BTW, what about removing the dicache altogether? Or is anyone using > > use_dicache=YES ? > > fltk-era dillo always behaved like use_dicache=NO, and I took out the > pref some months ago. I wanted to rip out the dicache at one point, > but ran into the entanglement mentioned above. A simple ripping-out > didn't look like it was going to work because something needed to > associate URLs with imgbufs and so on... Exactly. The dicache serves as a link between the image decoder and the image widget. It also provides versioned images. I have progressed a lot and the new code works quite well in my tree. After some assorted testing, there's still a segfault that I want to chase before showing the code. The rest of it works OK. (i.e. CSS with no half images). -- Cheers Jorge.-

Dec. 29, 2008

remove generate_submit pref?

by jcid＠dillo.org

On Fri, Dec 26, 2008 at 05:05:30AM +0000, Jeremy Henty wrote: > On Fri, Dec 26, 2008 at 02:44:52AM +0000, corvid wrote: > > Any objections to getting rid of it? > > No. IIRC that was a code path that got in the way of refactoring > form.cc when I last looked at it, so I wouldn't be surprised if the > code was improved by losing it. A long time ago it served as a workaround for simple javascript-dependent submit buttons. It seems like it's of not much use anymore. AFAIS, we can get rid of it. -- Cheers Jorge.-

Dec. 29, 2008

[patch]: fix dialog callback

by onepoint＠starurchin.org

Dialog_user_password_cb() should not use VOIDP2INT, because the (void *) argument was originally an (int *), not an int or long. This bug makes the dialog always call its callback even when the user presses the Cancel button. As a result it is futile to cancel the Basic Authentication dialog: the page reloads and the dialog pops up again. Patch attached. Jeremy Henty

Dec. 28, 2008

Re: CSS loading part#2

by corvid＠lavabit.com

Johannes wrote: > On Thu, Dec 25, 2008 at 10:43:06AM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > On Sun, Dec 21, 2008 at 04:48:42PM -0300, Jorge Arellano Cid wrote: > > > Hi Johannes, > > > > > > Here I'm attaching the second part of the CSS loading patch. > > > This one is coherent and works better :-). Please commit after > > > some testing. > > > > > > Note: images are still truncated sometimes, but AFAIS this is a > > > problem in the dicache, not in CSS loading. I hope to fix this > > > soon. > > > > Well, in fact, images were always truncated when the repush > > caught them still rendering. > > > > I've been working on this for days and yes, it's a problem in > > the dicache. Unfortunately the cache/dicache/image-decode/image > > code is so entangled that it needs a rewrite. Quite surprising it > > works stable "as is". > > BTW, what about removing the dicache altogether? Or is anyone using > use_dicache=YES ? fltk-era dillo always behaved like use_dicache=NO, and I took out the pref some months ago. I wanted to rip out the dicache at one point, but ran into the entanglement mentioned above. A simple ripping-out didn't look like it was going to work because something needed to associate URLs with imgbufs and so on...

Dec. 28, 2008

experimental patch: image error status as alt text

by corvid＠lavabit.com

Johannes wrote: > That reminds me of a related issue. Display of alt text works fine > if width or height of an image is unspecified, but looks weird e.g. > with images that have width=1. > Any idea how to handle that? Should we ignore width/height in case > we are showing the alt text? Perhaps. I'm wondering whether it might distort pages too much, though. And related to _that_, we have the matter of dillo not preserving aspect for images with one dimension specified.

Dec. 28, 2008

Re: CSS loading part#2

by Johannes.Hofmann＠gmx.de

On Thu, Dec 25, 2008 at 10:43:06AM -0300, Jorge Arellano Cid wrote: > Hi, > > On Sun, Dec 21, 2008 at 04:48:42PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > Here I'm attaching the second part of the CSS loading patch. > > This one is coherent and works better :-). Please commit after > > some testing. > > > > Note: images are still truncated sometimes, but AFAIS this is a > > problem in the dicache, not in CSS loading. I hope to fix this > > soon. > > Well, in fact, images were always truncated when the repush > caught them still rendering. > > I've been working on this for days and yes, it's a problem in > the dicache. Unfortunately the cache/dicache/image-decode/image > code is so entangled that it needs a rewrite. Quite surprising it > works stable "as is". BTW, what about removing the dicache altogether? Or is anyone using use_dicache=YES ? > > The idea is to try to devise a single path of execution that > allows handling each image request (repeated or not) as a simple > cache client. It's more complex than it sounds! > > The good news is that after you merge the latest cleanups in > dillo main, the attached patch will more or less make it work as > desired. There'll be some added unstability, and the underlying > mess ;), but it should be a good basis to keep improving CSS > while I work in the image process stream. With the patch below I get frequent crashes like that: Program received signal SIGSEGV, Segmentation fault. a_Image_imgbuf_unref (v_imgbuf=0x0) at image.cc:214 214 ((Imgbuf*)v_imgbuf)->unref(); (gdb) bt #0 a_Image_imgbuf_unref (v_imgbuf=0x0) at image.cc:214 #1 0x0805c63e in Dicache_remove (Url=<value optimized out>, version=<value optimized out>) at dicache.c:190 #2 0x0805a486 in a_Cache_stop_client (Key=63) at cache.c:1268 #3 0x080542fb in a_Bw_stop_clients (bw=0x2860f2c0, flags=3) at bw.c:188 #4 0x08059b4b in Nav_open_url (bw=0x2860f2c0, url=0x2866b1c0, offset=0) at nav.c:231 #5 0x08059e23 in Nav_repush (bw=0x2860f2c0) at nav.c:366 #6 0x08059e46 in Nav_repush_callback (data=0x2860f2c0) at nav.c:373 #7 0x080c3c1d in fltk::wait () #8 0x080c3cad in fltk::run () #9 0x0804f1a0 in main (argc=1, argv=0x4) at dillo.cc:334 (gdb) Cheers, Johannes

Dec. 28, 2008

experimental patch: image error status as alt text

by Johannes.Hofmann＠gmx.de

On Mon, Dec 22, 2008 at 01:19:07AM +0000, corvid wrote: > You know how for image redirections and 404s, nothing at all happens? > User's mind: "I didn't get the image. Dillo must be broken." > > (or the address can't resolve, or content-type doesn't match...) > > So I tried making something recently that shows, > e.g., [404] as the alt text. In this form it's > probably wrong in a design sense because cache > probably isn't allowed to call image, but maybe > it'll prompt some discussion... That reminds me of a related issue. Display of alt text works fine if width or height of an image is unspecified, but looks weird e.g. with images that have width=1. Any idea how to handle that? Should we ignore width/height in case we are showing the alt text? Cheers, Johannes

Dec. 28, 2008

remove generate_submit pref?

by onepoint＠starurchin.org

On Fri, Dec 26, 2008 at 02:44:52AM +0000, corvid wrote: > Any objections to getting rid of it? No. IIRC that was a code path that got in the way of refactoring form.cc when I last looked at it, so I wouldn't be surprised if the code was improved by losing it. Regards, Jeremy Henty

Dec. 26, 2008

remove generate_submit pref?

by corvid＠lavabit.com

Any objections to getting rid of it? dillorc: # Some forms lack a submit button, and dillo can generate a custom one # internally. Unfortunately there's no guarantee for it to work. :( # (my experience is that forms that lack a submit rely on Javascript) #generate_submit=NO

Dec. 26, 2008

Re: CSS loading part#2

by jcid＠dillo.org

Hi, On Sun, Dec 21, 2008 at 04:48:42PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > Here I'm attaching the second part of the CSS loading patch. > This one is coherent and works better :-). Please commit after > some testing. > > Note: images are still truncated sometimes, but AFAIS this is a > problem in the dicache, not in CSS loading. I hope to fix this > soon. Well, in fact, images were always truncated when the repush caught them still rendering. I've been working on this for days and yes, it's a problem in the dicache. Unfortunately the cache/dicache/image-decode/image code is so entangled that it needs a rewrite. Quite surprising it works stable "as is". The idea is to try to devise a single path of execution that allows handling each image request (repeated or not) as a simple cache client. It's more complex than it sounds! The good news is that after you merge the latest cleanups in dillo main, the attached patch will more or less make it work as desired. There'll be some added unstability, and the underlying mess ;), but it should be a good basis to keep improving CSS while I work in the image process stream. -- Cheers Jorge.- _... o_.-"` `\ .--. _ `'-._.-'""-; _ .' \`_\_ {_.-a"a-} _ / \ _/ .-' '. {c-._o_.){\|` | (@`-._ / \{ ^ } \\ _/ `~\ '-._ /'. } \} .-. |>:< '-.__/ '._,} \_/ / ()) | >:< `'---. ____'-.|(`"` \ >:< \\_\\_\ | ; \ \\-{}-\/ \ \ '._\\' /) '. /( `-._ _____ _ _____ __.'\ \ / \ / \ / \ \ \ jgs _.'/^\'._.'/^\'._.'/^\'.__) \ ,==' `---` '---' '---' ) `"""""""""""""""""""""""""""""""`

Dec. 25, 2008

Re: gmail access

by furaisanjin＠gmail.com

The patch is attached in this e-mail. Regards, furaisanjin

Dec. 23, 2008

Re: Dillo-dev Digest, Vol 40, Issue 22

by daniel.victoria＠gmail.com

Regarding Gmail access... I'm certanly interested in a patch Thanks Daniel On Tue, Dec 23, 2008 at 9:00 AM, <dillo-dev-request(a)dillo.org> wrote: > Send Dillo-dev mailing list submissions to > dillo-dev(a)dillo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > or, via email, send a message with subject or body 'help' to > dillo-dev-request(a)dillo.org > > You can reach the person managing the list at > dillo-dev-owner(a)dillo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Dillo-dev digest..." > > > Today's Topics: > > 1. gmail access (furaisanjin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 23 Dec 2008 09:28:14 +0900 > From: furaisanjin <furaisanjin(a)gmail.com> > Subject: [Dillo-dev] gmail access > To: Dillo-dev(a)dillo.org > Message-ID: > <144aa14b0812221628v71c176b2vf504b5bfe663e5b9(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi all. > > Now I figure out the way to access gmail but I realize that isn't sophisticated. > > Anyway what I have modified dillo after all is add "force reload link" feature. > > This is the step to access gmail > 1. Goto gmail.com and login in. > 2. You will see meta redirect page so just force reload the link on > meta redirect link. However you won't go anywhere yet. > 3. Goto mail.google.com/mail, then you find link to simple HTML page. > > If some of you are interested the patch, I will post. > > Regards, > furaisanjin > > > > ------------------------------ > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > End of Dillo-dev Digest, Vol 40, Issue 22 > ***************************************** >

Dec. 23, 2008

gmail access

by furaisanjin＠gmail.com

Hi all. Now I figure out the way to access gmail but I realize that isn't sophisticated. Anyway what I have modified dillo after all is add "force reload link" feature. This is the step to access gmail 1. Goto gmail.com and login in. 2. You will see meta redirect page so just force reload the link on meta redirect link. However you won't go anywhere yet. 3. Goto mail.google.com/mail, then you find link to simple HTML page. If some of you are interested the patch, I will post. Regards, furaisanjin

Dec. 23, 2008

experimental patch: image error status as alt text

by corvid＠lavabit.com

You know how for image redirections and 404s, nothing at all happens? User's mind: "I didn't get the image. Dillo must be broken." (or the address can't resolve, or content-type doesn't match...) So I tried making something recently that shows, e.g., [404] as the alt text. In this form it's probably wrong in a design sense because cache probably isn't allowed to call image, but maybe it'll prompt some discussion... (and maybe it'd be better to pull the status out of the header whenever needed rather than adding more junk to the cache entry.)

Dec. 22, 2008

a little ad blocker

by corvid＠lavabit.com

If you would like one just to play with, well then: http://www.dillo.org/test/adblocker.patch (Blocking * pretty much suffices for me, so I might as well put it there as-is before I become dangerously bored with it.)

Dec. 22, 2008

HTTP/1.1 side effect

by corvid＠lavabit.com

Jorge wrote: > @corvid: while debugging the CSS loading patch, I noticed that > sometimes dillo doesn't get the close after transfer event. This > is needed to trigger the CSS parser with a full sheet. > > For instance, go to http://localhost:631/ (CUPS interface), and > the progress bar will not get inactive after the page is got. > Now, if you switch http.c to HTTP/1.0 queries, it will work as > expected. > > Is there something missing, or a way to hook this? Searching for "cups" and "Connection: close", I found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504727 which says: | The client uses HTTP 1.1 and includes the |"Connection: close" header meaning that he wants that request to |be the last one. cups replies with a "Connection: keep-alive" |header and doesn't close its end of the connection, which is in |violation of the HTTP 1.1 RFC.

Dec. 21, 2008

HTTP/1.1 side effect

by jcid＠dillo.org

Hi, @corvid: while debugging the CSS loading patch, I noticed that sometimes dillo doesn't get the close after transfer event. This is needed to trigger the CSS parser with a full sheet. For instance, go to http://localhost:631/ (CUPS interface), and the progress bar will not get inactive after the page is got. Now, if you switch http.c to HTTP/1.0 queries, it will work as expected. Is there something missing, or a way to hook this? -- Cheers Jorge.-

Dec. 21, 2008

[patch]: Basic Authentication

by onepoint＠starurchin.org

I reviewed the final auth patch. No changes to suggest, just a few comments. > > The authentication dialog does not know which browser window > > opened the URL so it can't call a_Nav_reload(). Instead I > > implemented a_Nav_reload_url(). > > Removed a_Nav_reload_url() and set bw as a parameter. <facepalm/> Why didn't I think of that? :-) > > There's an interesting case when the server demands authentication > > for a realm that we have already authenticated ourselves to. It > > could be that we didn't send authentication because we didn't know > > the path was in the realm, or it could be that the authentication > > we sent was wrong. This requires the code to deduce what it did > > last time it saw this URL and rely on what it will do the next > > time. It works, but it feels fragile to me. I would prefer the > > URL to explicitly record authentication attempts so that the code > > doesn't have to second-guess itself. Thoughts? > > This will need debugging. Doesn't seem critical though. I've been testing it locally and it seems to work as expected. > > I implemented a full token-value list parser as per the RFC. > > I'd appreciate it in smaller functions and without gotos. OK, I'll investigate breaking it down. > > If the user opens several pages in a realm in a very short time > > then it is conceivable that multiple authentication dialogs for > > the same realm could pop up > > Just added a check. It doesn't solve the problem, but avoids the > storm and sends a warning to stdout. What happens if the user opens pages for different realms at almost the same time. Will the first authentication dialog suppress the other? If so then the user will have to reload the second page before they can log in. > * Does Auth_path_is_inside() need to be case sensitive? I think so. From RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1: 3.2.3 URI Comparison When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: None of the exceptions apply to the path component (except for the condition that "" and "/" are the same path). Since "/foo" and "/FOO" are different paths I deduce that "/foo/bar" is not inside "/FOO". Regards, Jeremy Henty

Dec. 21, 2008

[patch]: Basic Authentication

by onepoint＠starurchin.org

On Sat, Dec 20, 2008 at 09:34:45AM -0300, Jorge Arellano Cid wrote: > ... I don't know of a single site with basic auth to test! :-) I set up a quick test: http://starurchin.org:8080/basic_auth user: dillo password: dillo You can also try my Linux From Scratch Trac account: http://wiki.linuxfromscratch.org/blfs/login user: jeremy_henty password: VglP96IxQ (I'll change the password once you have tested it.) Regards, Jeremy Henty

Dec. 21, 2008

patch: error pages from file dpi

by jcid＠dillo.org

On Fri, Dec 19, 2008 at 10:46:03PM +0000, corvid wrote: > What do you think of sending little HTTP error pages for > file not found and so on? > > I always find it a little jarring when nothing happens and > I have to look down at the status bar for the error. > Committed. -- Cheers Jorge.-

Dec. 21, 2008

Mercurial repository

by jcid＠dillo.org

Hi, The source code repository page was updated to Mercurial. Please send me the patches as advised there, and please add a one-liner entry in the ChangeLog file. That way it'kll be easier for me and proper credits will appear in both. -- Cheers Jorge.-

Dec. 21, 2008

[patch]: Basic Authentication

by corvid＠lavabit.com

auth.c:296: warning: 'match_length' may be used uninitialized in this function

Dec. 20, 2008

[patch]: Basic Authentication

by jcid＠dillo.org

Hi Jeremy, Committed a modified version of the last patch. Here I'm adding some comments. On Thu, Dec 04, 2008 at 11:11:03AM +0000, Jeremy Henty wrote: > > OK, here it is. Please comment. Some observations: > > When the cache parses the HTTP header we just attach any > authentication headers to the cache entry. Nothing else happens until > we process the clients. Just before iterating over the clients we > check if all the data is in. If it is then we do any necessary > authentication. Just moved the test after the for loop. > Opening the authentication dialog runs the FLTK event loop, which > means that incoming data can call the cache again, triggering CCC > warnings. We work around it by deferring the dialog to a timeout so > that the cache finishes iterating over the clients before the dialog > appears. This is annoying but I don't see a better way at the moment. That's the way to do it. > The authentication dialog does not know which browser window opened > the URL so it can't call a_Nav_reload(). Instead I implemented > a_Nav_reload_url(). Removed a_Nav_reload_url() and set bw as a parameter. > There's an interesting case when the server demands authentication for > a realm that we have already authenticated ourselves to. It could be > that we didn't send authentication because we didn't know the path was > in the realm, or it could be that the authentication we sent was > wrong. This requires the code to deduce what it did last time it saw > this URL and rely on what it will do the next time. It works, but it > feels fragile to me. I would prefer the URL to explicitly record > authentication attempts so that the code doesn't have to second-guess > itself. Thoughts? This will need debugging. Doesn't seem critical though. > I implemented a full token-value list parser as per the RFC. Maybe > this is overkill for Basic authentication, but it will be necessary > for Digest authentication. Yes, it has gotos; I began by setting > flags but decided that gotos were actually cleaner. Maybe it should > be rewritten in state-machine style? I'd appreciate it in smaller functions and without gotos. > If the user opens several pages in a realm in a very short time then > it is conceivable that multiple authentication dialogs for the same > realm could pop up (just like the https DPI sometimes does with > certificate dialogs). I don't address this at the moment because I > think it won't be a problem in practice. If it needs fixing then we > will have to monitor the list of currently open dialogs to avoid > duplicates. Just added a check. It doesn't solve the problem, but avoids the storm and sends a warning to stdout. Please review the changes. It almost has no testing. Some changes I remember: - Modified a bit the code ignoring the last '/' of a path. - Reordered function so no massive forward declarations are necessary. - Used VOID2INT macro. - Added some comments (there're still plenty of uncommented functions) - Prefixed all functions in auth.c with "Auth" - Suffixed "_t" the typedefed data structures. - Removed a_Bw_each() - Removed compiler warnings. - some others... * Does Auth_path_is_inside() need to be case sensitive? Well, now it seems is time to fix the missing points and to real-world test it! -- Cheers Jorge.-

Dec. 20, 2008

[patch]: Basic Authentication

by newman.x＠gmail.com

On Sat, Dec 20, 2008 at 09:34:45AM -0300, Jorge Arellano Cid wrote: > There're several minor things I'd like to arrange, but > believe it or not, I don't know of a single site with basic auth > to test! :-) > > Would you mind sending me an example? Yeah, not much of them :). www.csfd.cz user: dillo pass: dillo Look for the link "Prihlasit" ["log-in"] (points to http://www.csfd.cz/login.php) The log-in seems to work, I can see there "Bu? zdr?v! :-)", which means "Howdy :)". But in Firefox there's also some redirection, perhaps via javascript and some cookie mangling, becausu if I go to www.csfd.cz, after log-in, again, it does not look like I am in (still the "Prihlasit" text there). Michal

Dec. 20, 2008

[patch]: Basic Authentication

by jcid＠dillo.org

Hi Jeremy, On Sat, Dec 06, 2008 at 02:25:57PM +0000, Jeremy Henty wrote: > > Next iteration: one bugfix. > > * In Auth_parse_auth_basic(), fix the test for the "realm" token. Today I gave a detailed review to the patch. There're several minor things I'd like to arrange, but believe it or not, I don't know of a single site with basic auth to test! :-) Would you mind sending me an example? TIA. -- Cheers Jorge.-

Dec. 20, 2008

patch: error pages from file dpi

by onepoint＠starurchin.org

On Fri, Dec 19, 2008 at 10:46:03PM +0000, corvid wrote: > What do you think of sending little HTTP error pages for file not > found and so on? I like it. It annoys me when Dillo displays blank pages in these situations and this is definitely better. Jeremy Henty

Dec. 20, 2008

patch: error pages from file dpi

by corvid＠lavabit.com

What do you think of sending little HTTP error pages for file not found and so on? I always find it a little jarring when nothing happens and I have to look down at the status bar for the error.

Dec. 19, 2008

Re: CSS loading, part 1

by jcid＠dillo.org

On Fri, Dec 19, 2008 at 09:57:44PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Fri, Dec 19, 2008 at 03:37:28PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > The attached patch does better than the current way, it has > > more consistency betweeen what's shown the first time and after > > back and forward (at least with my test set). > > > > Please test it and apply to the css-proto tree. > > Thanks! Pushed to css-prototpe. Good! > > I don't know what's to be done when multiple stylesheets are > > specified, like in this site: http://www.lacuarta.cl. Are they > > all supposed to be loaded? If that's the case, I'd like to load > > them all and after that, make a single repush instead of one per > > arrival. > > Yes, all stylesheets with a matching media type have to be loaded. > I noticed a regression on http://src.opensolaris.org/source/ > Maybe it's because now only one stylesheet is loaded? > > I agree that having just a single repush is probabely better. OK. I'll work on it. > I don't yet fully understand the new logic and the difference to > corvid's approach. It's quite messy by now, don't try to find coherence in it! I just tried to push it quick because it may help debug CSS. > Are the style changes in css.cc and css.hh intentional? Yes. > Generally it would be good to keep whitespace only changes in > separate commits. That simplifies reviewing and the search for > faulty changesets. > BTW. "hg bisect" is a fanatastic tool for that! (similar stuff > exists for git too of course). Sorry, I'm still a newbie with Hg. Yesterday I tried to make that and ended with several heads, and had to resort to plain patches, and erasing the local repo. -- Cheers Jorge.-

Dec. 19, 2008

Re: CSS loading, part 1

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Fri, Dec 19, 2008 at 03:37:28PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > The attached patch does better than the current way, it has > more consistency betweeen what's shown the first time and after > back and forward (at least with my test set). > > Please test it and apply to the css-proto tree. Thanks! Pushed to css-prototpe. > > I don't know what's to be done when multiple stylesheets are > specified, like in this site: http://www.lacuarta.cl. Are they > all supposed to be loaded? If that's the case, I'd like to load > them all and after that, make a single repush instead of one per > arrival. Yes, all stylesheets with a matching media type have to be loaded. I noticed a regression on http://src.opensolaris.org/source/ Maybe it's because now only one stylesheet is loaded? I agree that having just a single repush is probabely better. I don't yet fully understand the new logic and the difference to corvid's approach. Are the style changes in css.cc and css.hh intentional? Generally it would be good to keep whitespace only changes in separate commits. That simplifies reviewing and the search for faulty changesets. BTW. "hg bisect" is a fanatastic tool for that! (similar stuff exists for git too of course). > > If that scheme is implemented, then it'd be simple to extend > the code to parse this case: > > <style type="text/css" media="all"> > @import url('/style.css'); > </style> > > > BTW, it's a very nice feeling to see CSS working. Yes it's fun! Cheers, Johannes

Dec. 19, 2008