December 2008 - Dillo-dev - lists.mailman3.com

HTTP/1.1 side effect
by jcid＠dillo.org 21 Dec '08

21 Dec '08

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.-

2 1

[patch]: Basic Authentication
by onepoint＠starurchin.org 21 Dec '08

21 Dec '08

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. 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. 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(). 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? 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? 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. Regards, Jeremy Henty

4 8

[patch]: Basic Authentication
by onepoint＠starurchin.org 21 Dec '08

21 Dec '08

Next iteration: one bugfix. * In Auth_parse_auth_basic(), fix the test for the "realm" token. Jeremy Henty

3 3

patch: error pages from file dpi
by corvid＠lavabit.com 21 Dec '08

21 Dec '08

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.

3 2

Mercurial repository
by jcid＠dillo.org 21 Dec '08

21 Dec '08

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.-

1 0

Re: CSS loading, part 1
by Johannes.Hofmann＠gmx.de 20 Dec '08

20 Dec '08

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

2 1

[patch]: use $(srcdir) in Make rules
by onepoint＠starurchin.org 19 Dec '08

19 Dec '08

I was revising the autoconf docs and noticed that make rules should prefix all sources with $(srcdir) to support separate builds[1]. We don't do this, so here's a patch. (Patch generated with Mercurial Queues, BTW.) Jeremy Henty [1]: (autoconf.info)Installation Directory Variables

3 6

revision control and other project infrastructure
by dillo-dev＠toykeeper.net 18 Dec '08

18 Dec '08

Hello. I noticed some recent messages about revision control and possibly switching to a DVCS. This makes me happy. :) So, I was wondering about general project infrastructure... things like bug trackers, todo lists, mailing lists, help forums, release management, news, patch queues and code review, code repositories, etc. What I've found so far is the following: dillo.org: - general project info - release tarballs - bug list - FAQ auriga.wearlab.de: - mailing lists - cvs freshmeat.net: release announcements freenode: IRC (inactive?) http://misc.andi.de1.cc/dillo/ : Packaging for Debian, Ubuntu, Openmoko http://www.hyperborea.org/software/dillo/ : Packaging for Red Hat http://freehg.org/u/dillo/css-prototype : Prototype CSS branch Is that about right? Did I miss anything? -- Scott

6 9

dillo_dbg_rendering
by corvid＠lavabit.com 16 Dec '08

16 Dec '08

I'm finally bored enough to copy the cmdline code from dillo1. Does anyone care about the dillo_dbg_rendering option? It forces borders in table.cc.

2 1

shaded colors and css
by Johannes.Hofmann＠gmx.de 15 Dec '08

15 Dec '08

Hello, mapping css properties to dw::core::style::Style members went very smooth, because Style was obviously implemented with css in mind. Just for the shaded color thing I can't find a corresponding concept in css. What exactly is the definition of a shaded color? Is it just a bit darker than the normal one? Does anyone know the corresponding concept in css? Cheers, Johannes

2 4