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

feature freeze

by corvid＠lavabit.com

Jorge wrote: > More or less we entered "feature freeze" mode implicitly. > > What is left pending? > > I remember: > > - the mini_bug.xpm FLTK2 fix. > - the focused textarea callback issue. My alt-X crash in the menu. I guess I'll look into giving it a timeout. I think the 128 tabs and some other hardcoded 128 in there that Johannes found are still there. My leaving-the-window nav_expecting problem would be nice if possible.

Oct. 2, 2008

Javascript engine

by jcid＠dillo.org

Hi, Does anybody know about a lightweight javascript engine we can use with dillo? From what I've seen, SEE (Simple ECMAScript Engine), looks like a good candidate. Disclaimer: I'm a newbie on JavaScript. -- Cheers Jorge.-

Oct. 2, 2008

crash with reload and textarea

by jcid＠dillo.org

On Thu, Oct 02, 2008 at 05:38:18PM +0200, Johannes Hofmann wrote: > Hi, > > when using MALLOC_OPTIONS=GJPRZ on DragonFly which enables malloc > debugging I get a crash when hitting Ctrl+r to reload a page with > entered text in a textarea if the focus is still in the > textarea. > It seems that the Ctrl+r causes a callback on the already deleted > fltk Input widget: There seems to be a bug in FLTK2's Input::replace(), called by Input::insert(). The attached workaround solves it for me. Please check. -- Cheers Jorge.-

Oct. 2, 2008

feature freeze

by jcid＠dillo.org

Hi, More or less we entered "feature freeze" mode implicitly. What is left pending? I remember: - the mini_bug.xpm FLTK2 fix. - the focused textarea callback issue. -- Cheers Jorge.-

Oct. 2, 2008

crash with reload and textarea

by Johannes.Hofmann＠gmx.de

Hi, when using MALLOC_OPTIONS=GJPRZ on DragonFly which enables malloc debugging I get a crash when hitting Ctrl+r to reload a page with entered text in a textarea if the focus is still in the textarea. It seems that the Ctrl+r causes a callback on the already deleted fltk Input widget: Program received signal SIGBUS, Bus error. 0x0805310d in fltk::Widget::do_callback (this=0x284f5600) at /home/hofmann/soft//include/fltk/Widget.h:127 127 voiddo_callback()when{ callback_(this,user_data_); } (gdb) bt #0 0x0805310d in fltk::Widget::do_callback (this=0x284f5600) at /home/hofmann/soft//include/fltk/Widget.h:127 #1 0x080b75e3 in changed_stuff (i=0x28471480) at Input.cxx:49 #2 0x080b85dc in fltk::Input::replace (this=0x28471480, b=0, e=0, text=0x2856d280 "http://www.shiningsilence.com/dbsdlog/2008/10/01/3185.html#respond", ilen=66) at Input.cxx:826 #3 0x080bc4d8 in fltk::Input::insert (this=0x28471480, t=0x2856d280 "http://www.shiningsilence.com/dbsdlog/2008/10/01/3185.html#respond", l=66) at ../fltk/Input.h:86 #4 0x080b78f1 in fltk::Input::insert (this=0x28471480, text=0x2856d280 "http://www.shiningsilence.com/dbsdlog/2008/10/01/3185.html#respond") at Input.cxx:852 #5 0x08057aee in a_Web_dispatch_by_type (Type=0x2856f260 "text/html; charset=UTF-8", Web=0x2855a980, Call=0x2855a9d0, Data=0x2855a9d4) at web.cc:95 #6 0x08059b25 in Cache_process_queue (entry=0x285010c0) at cache.c:1050 On Linux export MALLOC_CHECK_=2 or valgrind should show similar results. Cheers, Johannes

Oct. 2, 2008

what crashes remain?

by jcid＠dillo.org

On Thu, Oct 02, 2008 at 04:50:55PM +0200, Johannes Hofmann wrote: > On Wed, Oct 01, 2008 at 07:21:35PM -0400, Jorge Arellano Cid wrote: > > On Wed, Oct 01, 2008 at 11:11:23PM +0200, Johannes Hofmann wrote: > > > On Wed, Oct 01, 2008 at 03:01:19PM -0400, Jorge Arellano Cid wrote: > > > > On Wed, Oct 01, 2008 at 06:14:47PM +0200, Johannes Hofmann wrote: > > > > > On Wed, Oct 01, 2008 at 11:45:53AM -0400, Jorge Arellano Cid wrote: > > > > > > On Wed, Oct 01, 2008 at 04:47:05PM +0200, Johannes Hofmann wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Wed, Oct 01, 2008 at 10:33:20AM -0400, Jorge Arellano Cid wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Sat, Sep 27, 2008 at 05:38:03PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > > > > > > > > It's still possible to crash dillo if you click on a remote link and > > > > > > > > > > quickly click on some images to load them. Doesn't crash every time, > > > > > > > > > > but typically within four tries or so. I had assumed it was the same > > > > > > > > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > > > > > > > > > > > > > > > If I stick > > > > > > > > > > a_Bw_stop_clients(bw, BW_Img); > > > > > > > > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > > > > > > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > > > > > > > > earlier today, so there's something wrong with just doing that. > > > > > > > > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > > > > > > > > > > > > > > > That message means big trouble: the event loop stepped over itself... > > > > > > > > > > > > > > > > > > I've tried several different ways but can't get to crash it. > > > > > > > > > > > > > > > > > > Does the attached patch help? > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Cheers > > > > > > > > > Jorge.- > > > > > > > > > > > > > > > > > diff -pru dillo2/src/html.cc dillo2-cur/src/html.cc > > > > > > > > > --- dillo2/src/html.cc 2008-09-27 15:11:08.000000000 -0400 > > > > > > > > > +++ dillo2-cur/src/html.cc 2008-09-27 17:34:21.000000000 -0400 > > > > > > > > > @@ -711,6 +711,8 @@ bool_t DilloHtml::unloadedImages() > > > > > > > > > */ > > > > > > > > > void DilloHtml::loadImages (const DilloUrl *pattern) > > > > > > > > > { > > > > > > > > > + dReturn_if_fail (bw->nav_expecting == FALSE); > > > > > > > > > + > > > > > > > > > for (int i = 0; i < images->size(); i++) { > > > > > > > > > if (images->get(i)->image) { > > > > > > > > > if ((!pattern) || (!a_Url_cmp(images->get(i)->url, pattern))) { > > > > > > > > > > > > > > > > Can you still crash dillo this way, with the latest CVS? > > > > > > > > (i.e. without the above patch). > > > > > > > > > > > > > > I'm currently seeing all sorts of crashes and I suspect that they > > > > > > > are related to xpmImage from fltk. > > > > > > > Could someone with a linux machine please check current dillo with > > > > > > > valgrind especially when the new mini_bug_xpm is shown? > > > > > > > > > > > > > > Also changing mini_bug_xpm to 15x15 seems to fix things for me. > > > > > > > I don't understand all that completely, but other crashes might be > > > > > > > related to this. > > > > > > > > > > > > OK, I'll check with valgrind... > > > > > > Does changing mini_ok_xpm to 16x16 fix it too? > > > > > > > > > > No it doesn't, that's what I thought first too :-) > > > > > > > > > > But it really only happens when fltk was compiled with > > > > > --disable-xft > > > > > > > > I did that and FLTK's tests don't use xft, but my > > > > dillo-fltk still uses them! > > > > > > > > > > Did you call ./configure for dillo again? > > > > Yes. I forgot to make install FLTK, now it works. :) > > > > > > > > > > > > > > > > > BTW, does a: > > > > > > > > - new_w = strlen(str)*8 + 20; > > > > + new_w = strlen(str)*8 + 40; > > > > > > > > in ui.cc solve the problem for you? > > > > > > No, it doesn't. I think it's a fltk problem. > > > > Yes, valgrind reports an invalid write of size 1. > > See the attached file. > > > > It looks like unless FLTK2 is patched, we'll have a w=15 minibug > > as workaround. > > > > -- > > Cheers > > Jorge.- > > > ==17533== Invalid write of size 1 > > ==17533== at 0x4893E4: argb32_converter(unsigned char const*, unsigned char*, int) (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x4BA415: fltk::xpmImage::fetch(fltk::Image&, char const* const*) (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x4BA45C: fltk::xpmImage::fetch() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x488AFB: fltk::Image::fetch_if_needed() const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x488B76: fltk::Image::_measure(int&, int&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x4B85D9: fltk::Widget::draw_label(fltk::Rectangle const&, int) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x47AA90: fltk::Button::draw(int) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x48645A: fltk::Group::draw() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x48645A: fltk::Group::draw() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > > > Thanks. I think I've found the problem. It's now in the fltk > bugtracker: http://fltk.org/str.php?L2054 > Let's hope the fix get's commited soon. Excellent! Maybe you can write a note to fltk-dev so Bill S. notices quickly. -- Cheers Jorge.-

Oct. 2, 2008

Shift + {Left, Right}

by jcid＠dillo.org

Hi there, Just committed a patch for making: SHIFT + {Left, Right} work even with the findbar focused. It took a long time to get it to work, but it improves Tab navigation a lot! Note: in uicmd.cc, + focus(child(i)); selected_child(child(i)); makes SHIFT+Right keep focus. SHIFT+Left doesn't work. I don't know why... -- Cheers Jorge.-

Oct. 2, 2008

what crashes remain?

by Johannes.Hofmann＠gmx.de

On Wed, Oct 01, 2008 at 07:21:35PM -0400, Jorge Arellano Cid wrote: > On Wed, Oct 01, 2008 at 11:11:23PM +0200, Johannes Hofmann wrote: > > On Wed, Oct 01, 2008 at 03:01:19PM -0400, Jorge Arellano Cid wrote: > > > On Wed, Oct 01, 2008 at 06:14:47PM +0200, Johannes Hofmann wrote: > > > > On Wed, Oct 01, 2008 at 11:45:53AM -0400, Jorge Arellano Cid wrote: > > > > > On Wed, Oct 01, 2008 at 04:47:05PM +0200, Johannes Hofmann wrote: > > > > > > Hi, > > > > > > > > > > > > On Wed, Oct 01, 2008 at 10:33:20AM -0400, Jorge Arellano Cid wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Sat, Sep 27, 2008 at 05:38:03PM -0400, Jorge Arellano Cid wrote: > > > > > > > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > > > > > > > It's still possible to crash dillo if you click on a remote link and > > > > > > > > > quickly click on some images to load them. Doesn't crash every time, > > > > > > > > > but typically within four tries or so. I had assumed it was the same > > > > > > > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > > > > > > > > > > > > > If I stick > > > > > > > > > a_Bw_stop_clients(bw, BW_Img); > > > > > > > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > > > > > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > > > > > > > earlier today, so there's something wrong with just doing that. > > > > > > > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > > > > > > > > > > > > > That message means big trouble: the event loop stepped over itself... > > > > > > > > > > > > > > > > I've tried several different ways but can't get to crash it. > > > > > > > > > > > > > > > > Does the attached patch help? > > > > > > > > > > > > > > > > -- > > > > > > > > Cheers > > > > > > > > Jorge.- > > > > > > > > > > > > > > > diff -pru dillo2/src/html.cc dillo2-cur/src/html.cc > > > > > > > > --- dillo2/src/html.cc 2008-09-27 15:11:08.000000000 -0400 > > > > > > > > +++ dillo2-cur/src/html.cc 2008-09-27 17:34:21.000000000 -0400 > > > > > > > > @@ -711,6 +711,8 @@ bool_t DilloHtml::unloadedImages() > > > > > > > > */ > > > > > > > > void DilloHtml::loadImages (const DilloUrl *pattern) > > > > > > > > { > > > > > > > > + dReturn_if_fail (bw->nav_expecting == FALSE); > > > > > > > > + > > > > > > > > for (int i = 0; i < images->size(); i++) { > > > > > > > > if (images->get(i)->image) { > > > > > > > > if ((!pattern) || (!a_Url_cmp(images->get(i)->url, pattern))) { > > > > > > > > > > > > > > Can you still crash dillo this way, with the latest CVS? > > > > > > > (i.e. without the above patch). > > > > > > > > > > > > I'm currently seeing all sorts of crashes and I suspect that they > > > > > > are related to xpmImage from fltk. > > > > > > Could someone with a linux machine please check current dillo with > > > > > > valgrind especially when the new mini_bug_xpm is shown? > > > > > > > > > > > > Also changing mini_bug_xpm to 15x15 seems to fix things for me. > > > > > > I don't understand all that completely, but other crashes might be > > > > > > related to this. > > > > > > > > > > OK, I'll check with valgrind... > > > > > Does changing mini_ok_xpm to 16x16 fix it too? > > > > > > > > No it doesn't, that's what I thought first too :-) > > > > > > > > But it really only happens when fltk was compiled with > > > > --disable-xft > > > > > > I did that and FLTK's tests don't use xft, but my > > > dillo-fltk still uses them! > > > > > > > Did you call ./configure for dillo again? > > Yes. I forgot to make install FLTK, now it works. :) > > > > > > > > > > > > BTW, does a: > > > > > > - new_w = strlen(str)*8 + 20; > > > + new_w = strlen(str)*8 + 40; > > > > > > in ui.cc solve the problem for you? > > > > No, it doesn't. I think it's a fltk problem. > > Yes, valgrind reports an invalid write of size 1. > See the attached file. > > It looks like unless FLTK2 is patched, we'll have a w=15 minibug > as workaround. > > -- > Cheers > Jorge.- > ==17533== Invalid write of size 1 > ==17533== at 0x4893E4: argb32_converter(unsigned char const*, unsigned char*, int) (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x4BA415: fltk::xpmImage::fetch(fltk::Image&, char const* const*) (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x4BA45C: fltk::xpmImage::fetch() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x488AFB: fltk::Image::fetch_if_needed() const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x488B76: fltk::Image::_measure(int&, int&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x4B85D9: fltk::Widget::draw_label(fltk::Rectangle const&, int) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x47AA90: fltk::Button::draw(int) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x48645A: fltk::Group::draw() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x48645A: fltk::Group::draw() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > Thanks. I think I've found the problem. It's now in the fltk bugtracker: http://fltk.org/str.php?L2054 Let's hope the fix get's commited soon. Cheers, Johannes

Oct. 2, 2008

Basic authentication

by jcid＠dillo.org

Hi Christian, On Thu, Oct 02, 2008 at 09:15:58AM +0200, Christian Kellermann wrote: > * corvid <corvid(a)lavabit.com> [081002 06:41]: > > Christian wrote: > > > Dear List, > > > > > > since I have not found any traces of discussion on this list about > > > this topic I dare to ask where to place code handling basic > > > authentication in dillo's source? As I see it the cache module is > > > responsible for handling server responses. So I would at a first > > > try add the code there. How can I connect to a UI dialog from here > > > to get the necessary credentials? Maybe a possible solution looks > > > like this: > > > > > > - react to 403 header and look for Authorization request > > > - if there is one ask the user for username/pass > > > + resend the request with the Authorisation header added > > > + or display the 403 if the user aborts > > > > > > > > > What do you think? I will come up with some example code to illustrate > > > the idea in case this is not very clear. > > > > (We'll see what Jorge has to say, but...) > > cache.c seems like the right place to me, with a dialog called by way of > > uicmd.cc. The auth data would be stored away somewhere (a new file?), > > which a_Http_make_query_str() could call like it calls a_Cookies_get_query(). > > > > This sounds good. Yes, following the cookies model, without the dpi part, is a good idea. > What I am thinking about at the moment is how to > keep the user/password combination attached to a certain URL for > future reference? As I see it the connection structure gets dropped > as soon as the transfer of one entity is finished... A new file (auth.c or basic_auth.c) looks like a good place for the auth-specific functions and data. i.e. you can store a URL to user/password/whatever table there, and query it when the AUTH flag is set. > To be more > specific I have been trying something like this: > > > Index: src/cache.c > =================================================================== > RCS file: /sfhome/cvs/dillo/dillo2/src/cache.c,v > retrieving revision 1.33 > diff -b -u -p -r1.33 cache.c > --- src/cache.c 14 Sep 2008 20:26:08 -0000 1.33 > +++ src/cache.c 2 Oct 2008 07:13:11 -0000 > @@ -617,7 +617,7 @@ static Dlist *Cache_parse_multiple_field > static void Cache_parse_header(CacheEntry_t *entry) > { > char *header = entry->Header->str; > - char *Length, *Type, *location_str, *encoding, *charset; > + char *Length, *Type, *location_str, *encoding, *charset, *auth; > #ifndef DISABLE_COOKIES > Dlist *Cookies; > #endif > @@ -657,6 +657,23 @@ static void Cache_parse_header(CacheEntr > } > dFree(location_str); > > + } else if (strncmp(header + 9, "401", 3) == 0) { > + auth = Cache_parse_field(header, "WWW-Authenticate"); > + if ( auth ) { > + if (strncmp(auth, "Basic", 5) == 0) { > + entry->Flags |= CA_AuthNeeded; > + entry->Flags |= CA_AuthBasic; > + MSG_HTTP("Basic Authentication request\n"); > + } else if (strncmp(auth, "Digest", 6) == 0) { > + entry->Flags |= CA_AuthNeeded; > + entry->Flags |= CA_AuthDigest; > + MSG_HTTP("Digest Authentication request\n"); > + } else { > + MSG_ERR("Unknown authentication method in request " > + "'%s'.\n", auth); > + } > + MSG_HTTP(" for %s!\n", URL_STR(entry->Url)); > + } > } else if (strncmp(header + 9, "404", 3) == 0) { > entry->Flags |= CA_NotFound; > } > @@ -1037,6 +1054,11 @@ static void Cache_process_queue(CacheEnt > entry->ExpectedSize / (1024*1024)); > AbortEntry = OfferDownload = TRUE; > } > + if (entry->Flags & CA_AuthNeeded) { > + if (!Client->Callback) { > + Client->Callback = Cache_null_client; > + } > + } > } else { > /* For non root URLs, ignore redirections and 404 answers */ > if (entry->Flags & CA_Redirect || entry->Flags & CA_NotFound) > Index: src/cache.h > =================================================================== > RCS file: /sfhome/cvs/dillo/dillo2/src/cache.h,v > retrieving revision 1.5 > diff -b -u -p -r1.5 cache.h > --- src/cache.h 2 Jun 2008 02:27:43 -0000 1.5 > +++ src/cache.h 2 Oct 2008 07:13:11 -0000 > @@ -33,6 +33,9 @@ extern "C" { > #define CA_InternalUrl 0x800 /* URL content is generated by dillo */ > #define CA_HugeFile 0x1000 /* URL content is too big */ > #define CA_IsEmpty 0x2000 /* True until a byte of content arrives */ > +#define CA_AuthNeeded 0x4000 /* Set if server requests authentication */ > +#define CA_AuthBasic 0x8000 /* Set if server requests basic authentication */ > +#define CA_AuthDigest 0x10000 /* Set if server requests digest authentication */ > > /* > * Callback type for cache clients > > > The bit in Cache_process_queue should be the place where the handling > is done, at least so I thought. Maybe that is not a good idea... > Also I am a but uneasy with introducing new flags but it somehow > fits the overall scheme. Maybe it's possible to make it with just one flag: CA_AuthNeeded. Storing the details in the auth table. > Any suggestions? Yes, go ahead with the prototype implementation, and if you need more advice, just ask. Currently we're quite busy with the release schedule (a few days to go), so please be patient... -- Cheers Jorge.-

Oct. 2, 2008

Basic authentication

by Christian.Kellermann＠nefkom.net

* corvid <corvid(a)lavabit.com> [081002 06:41]: > Christian wrote: > > Dear List, > > > > since I have not found any traces of discussion on this list about > > this topic I dare to ask where to place code handling basic > > authentication in dillo's source? As I see it the cache module is > > responsible for handling server responses. So I would at a first > > try add the code there. How can I connect to a UI dialog from here > > to get the necessary credentials? Maybe a possible solution looks > > like this: > > > > - react to 403 header and look for Authorization request > > - if there is one ask the user for username/pass > > + resend the request with the Authorisation header added > > + or display the 403 if the user aborts > > > > > > What do you think? I will come up with some example code to illustrate > > the idea in case this is not very clear. > > (We'll see what Jorge has to say, but...) > cache.c seems like the right place to me, with a dialog called by way of > uicmd.cc. The auth data would be stored away somewhere (a new file?), > which a_Http_make_query_str() could call like it calls a_Cookies_get_query(). > This sounds good. What I am thinking about at the moment is how to keep the user/password combination attached to a certain URL for future reference? As I see it the connection structure gets dropped as soon as the transfer of one entity is finished... To be more specific I have been trying something like this: Index: src/cache.c =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/cache.c,v retrieving revision 1.33 diff -b -u -p -r1.33 cache.c --- src/cache.c 14 Sep 2008 20:26:08 -0000 1.33 +++ src/cache.c 2 Oct 2008 07:13:11 -0000 @@ -617,7 +617,7 @@ static Dlist *Cache_parse_multiple_field static void Cache_parse_header(CacheEntry_t *entry) { char *header = entry->Header->str; - char *Length, *Type, *location_str, *encoding, *charset; + char *Length, *Type, *location_str, *encoding, *charset, *auth; #ifndef DISABLE_COOKIES Dlist *Cookies; #endif @@ -657,6 +657,23 @@ static void Cache_parse_header(CacheEntr } dFree(location_str); + } else if (strncmp(header + 9, "401", 3) == 0) { + auth = Cache_parse_field(header, "WWW-Authenticate"); + if ( auth ) { + if (strncmp(auth, "Basic", 5) == 0) { + entry->Flags |= CA_AuthNeeded; + entry->Flags |= CA_AuthBasic; + MSG_HTTP("Basic Authentication request\n"); + } else if (strncmp(auth, "Digest", 6) == 0) { + entry->Flags |= CA_AuthNeeded; + entry->Flags |= CA_AuthDigest; + MSG_HTTP("Digest Authentication request\n"); + } else { + MSG_ERR("Unknown authentication method in request " + "'%s'.\n", auth); + } + MSG_HTTP(" for %s!\n", URL_STR(entry->Url)); + } } else if (strncmp(header + 9, "404", 3) == 0) { entry->Flags |= CA_NotFound; } @@ -1037,6 +1054,11 @@ static void Cache_process_queue(CacheEnt entry->ExpectedSize / (1024*1024)); AbortEntry = OfferDownload = TRUE; } + if (entry->Flags & CA_AuthNeeded) { + if (!Client->Callback) { + Client->Callback = Cache_null_client; + } + } } else { /* For non root URLs, ignore redirections and 404 answers */ if (entry->Flags & CA_Redirect || entry->Flags & CA_NotFound) Index: src/cache.h =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/cache.h,v retrieving revision 1.5 diff -b -u -p -r1.5 cache.h --- src/cache.h 2 Jun 2008 02:27:43 -0000 1.5 +++ src/cache.h 2 Oct 2008 07:13:11 -0000 @@ -33,6 +33,9 @@ extern "C" { #define CA_InternalUrl 0x800 /* URL content is generated by dillo */ #define CA_HugeFile 0x1000 /* URL content is too big */ #define CA_IsEmpty 0x2000 /* True until a byte of content arrives */ +#define CA_AuthNeeded 0x4000 /* Set if server requests authentication */ +#define CA_AuthBasic 0x8000 /* Set if server requests basic authentication */ +#define CA_AuthDigest 0x10000 /* Set if server requests digest authentication */ /* * Callback type for cache clients The bit in Cache_process_queue should be the place where the handling is done, at least so I thought. Maybe that is not a good idea... Also I am a but uneasy with introducing new flags but it somehow fits the overall scheme. Any suggestions? Kind regards, Christian P.S.: This patch is a work in progress and more of an example than anything. -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Oct. 2, 2008