- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Strange condition in cache.c old code

by Nikita V. Borodikhin

Hello, Andreas ! Andreas Kemnade wrote: >> <...> >> The presence of an entity body in a request is signaled by the >> inclusion of a Content-Length header field in the request message >> headers. HTTP/1.0 requests containing an entity body must include > ^^^^^^^^^ >> a valid Content-Length header field. >> > We speak about HTTP *responses* so that argument is invalid > >> IMHO if HTTP/1.0 response has an entity body then we know its type >> and length and should display it if we know how regardless of its size. >> So for this purpose "1024 test" has not sense. >> > see above > > Greetings > Andreas Kemnade OK, may be I'm wrong in my opinion but please give me _argumented_ answer why the current way of redirection confirms the standard. I'll accept any answer with reference to RFC, either HTTP/1.0 or HTTP/1.1. I dig them both and found those paragraphs to prove my point of view. May be I didn't found something that concern this question so if you can do it then do it ! Yours, Nikita

June 15, 2003

Re: [Dillo-dev] IFRAME element stub

by Stephen Lewis

On Sat, 14 Jun 2003 15:22:48 +0700 (NOVST) "Nikita V. Borodikhin" <eliterr(a)tkk.ru> wrote: > Hello, Stephen ! > > Stephen Lewis wrote: > > >> > There is a very small patch to support IFRAME HTML element. It > >does> > nothing except handling IFRAME via FRAME handler so special > >IFAME> > attributes(width and height) are not handled but this patch > >is> > suitable for current temporary solution (as we do not have real > >> > frame support for now). > > > > Just a comment about this - I'm using a recent CVS version some time > > after this was integrated, and it causes some display issues with a > > lot of sites. In particular, sites that use narrow IFRAMEs for ads <snip> > > This is a consequence of currently used way to handle frames, as Links > has. This IFRAME handler may be redesigned to use supplyed width and > height, I think it is not too hard but I expect it is a _temporary_ > solution intended just for having a link to IFRAME content until we do > not have normal frames. > OK, thanks for the response - I just wanted to make sure it hadn't slipped through unnoticed. Of course, if I'd actually read your original message thoroughly, I would have noticed that you'd said it was a temporary solution anyway... knee-jerk bug reporting reactions strike again! As an aside, it was quite an eye-opener viewing websites with this patch, I discovered many sites which I had thought to be free from advertising were in fact saturated with it - they were having about as much effect on me using Dillo as all of those pop up/under ads I hear about all the time ;) -- Stephen Lewis slewis(a)paradise.net.nz

June 15, 2003

Re: [Dillo-dev] IFRAME element stub

by Stephen Lewis

On Sat, 14 Jun 2003 16:49:45 -0700 Chris Palmer <chris(a)nodewarrior.org> wrote: > Madis Janson writes: > > > + gchar *src, *buf, *name; > > + gint dummy, len; > > - if ( !(attrbuf = Html_get_attr(html, tag, tagsize, "name")) ) { > > + if ( !!(attrbuf = Html_get_attr(html, tag, tagsize, "name")) ) { > > + a_Dw_page_add_text(page, g_strdup(attrbuf), link_style); > > + } else if (tolower(tag[1]) != 'i' || (len = strlen(name = src)) > > < 16 ||+ (name += 7, len -= 7) < 16) { > > - a_Dw_page_add_text(page, g_strdup(attrbuf), link_style); > > + buf = g_malloc(16); > > + memcpy(buf, name, 6); > > + strcpy(buf + 6, "..."); > > + memcpy(buf + 9, name + (len - 6), 6); > > + buf[15] = 0; > > + a_Dw_page_add_text(page, buf, link_style); > > Two questions: > > 1. Where does buf get free()'d? I had a quick look around for this and found the following comment for a_Dw_page_add_text (from src/dw_page.c): /* * Add a word to the page structure. Stashes the argument pointer in * the page data structure so that it will be deallocated on destroy. */ Which I guess answers the second question too. It's always such a pleasant surprise to have actual, useful comments in code! But then, I've come to expect pleasant surprises with Dillo ;) -- Stephen Lewis slewis(a)paradise.net.nz

June 15, 2003

Re: [Dillo-dev] IFRAME element stub

by Stephen Lewis

On Sat, 14 Jun 2003 11:51:35 +0300 (EEST) Madis Janson <madis(a)ats.cyber.ee> wrote: > On Sat, 14 Jun 2003, Stephen Lewis wrote: > <snip> > > It's great having this patch apart from the display issues it > > causes. Would it be possible to make the displayed URL wrap? > > > > > > I made it to replace the middle of long urls with ... for iframes: <snip> That patch works very nicely, thank you! -- Stephen Lewis slewis(a)paradise.net.nz

June 15, 2003

Re: [Dillo-dev] IFRAME element stub

by Chris Palmer

Madis Janson writes: > + gchar *src, *buf, *name; > + gint dummy, len; > - if ( !(attrbuf = Html_get_attr(html, tag, tagsize, "name")) ) { > + if ( !!(attrbuf = Html_get_attr(html, tag, tagsize, "name")) ) { > + a_Dw_page_add_text(page, g_strdup(attrbuf), link_style); > + } else if (tolower(tag[1]) != 'i' || (len = strlen(name = src)) < 16 || > + (name += 7, len -= 7) < 16) { > - a_Dw_page_add_text(page, g_strdup(attrbuf), link_style); > + buf = g_malloc(16); > + memcpy(buf, name, 6); > + strcpy(buf + 6, "..."); > + memcpy(buf + 9, name + (len - 6), 6); > + buf[15] = 0; > + a_Dw_page_add_text(page, buf, link_style); Two questions: 1. Where does buf get free()'d? 2. If you know the exact size you need for buf, why not just use an array of that size? char buf[16]; bzero(buf, 16);

June 14, 2003

Re: [Dillo-dev] Strange condition in cache.c old code

by Andreas Kemnade

On Sat, 14 Jun 2003 17:02:00 +0700 (NOVST) "Nikita V. Borodikhin" <eliterr(a)tkk.ru> wrote: > <...> > The presence of an entity body in a request is signaled by the > inclusion of a Content-Length header field in the request message > headers. HTTP/1.0 requests containing an entity body must include ^^^^^^^^^ > a valid Content-Length header field. > We speak about HTTP *responses* so that argument is invalid Greetings Andreas Kemnade > > IMHO if HTTP/1.0 response has an entity body then we know its type > and length and should display it if we know how regardless of its size. > So for this purpose "1024 test" has not sense. > see above Greetings Andreas Kemnade

June 14, 2003

Re: [Dillo-dev] Strange condition in cache.c old code

by Nikita V. Borodikhin

Hello, Jorge ! Jorge Arellano Cid wrote: >> Explain me please what is 1024 in the following code for. I read HTML >> and >> HTTP/1.1 (rfc2616) specifications but didn't find an answer. > > FYI: Dillo uses HTTP/1.0. OK, I'll give citations from HTTP/1.0 (RFC1945) >> I think this >> condition must be wiped out because some servers (linux.org.ru for >> example) >> give too long responses. >> >> [...] >> >> /* >> * Process redirections (HTTP 30x answers) >> * (This is a work in progress --not finished yet) >> */ >> int Cache_redirect(CacheData_t *entry, int Flags, BrowserWindow *bw) >> { >> if ( ((entry->Flags & CA_Redirect) && entry->Location) && >> ((entry->Flags & CA_ForceRedirect) || !entry->ValidSize || >> entry->ValidSize < 1024 ) ) { > > IIRC this is an heuristical boundary. > > Some servers don't send entity content within an http > redirection (Correct behaviour IMHO). Some send a short default > message as entity content (something so redundant as "This page > is being redirected"), and some others send a full page that can > be anything! I don't really encountered any server that gives a _garbage_ in 3xx response. Usually it is a HTML page with short decription and in rare case it is just a redirection without entity-body. RFC says that servers _may_ send a content (entity) but may do not: 4.1 Message Types HTTP messages consist of requests from client to server and responses from server to client. HTTP-message = Simple-Request ; HTTP/0.9 messages | Simple-Response | Full-Request ; HTTP/1.0 messages | Full-Response Full-Response = Status-Line ; Section 6.1 *( General-Header ; Section 4.3 | Response-Header ; Section 6.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2 7.2 Entity Body The entity body (if any) sent with an HTTP request or response is in a format and encoding defined by the Entity-Header fields. Entity-Body = *OCTET <...> The presence of an entity body in a request is signaled by the inclusion of a Content-Length header field in the request message headers. HTTP/1.0 requests containing an entity body must include a valid Content-Length header field. > The "1024" somehow decides this: > > < 1024: > Short redirection message. > > > 1024: > Don't know what is this large page! IMHO if HTTP/1.0 response has an entity body then we know its type and length and should display it if we know how regardless of its size. So for this purpose "1024 test" has not sense. > I also have a vague memory in my mind about how the http > redirection data stream is (or isn't) cut in order to make the > redirection. The "1024" threshold may "solve" this somehow. ??? I don't undestand this problem... > This is where you need to start investigating. > > HTH > Jorge.- Yours, Nikita

June 14, 2003

Re: [Dillo-dev] IFRAME element stub

by Madis Janson

On Sat, 14 Jun 2003, Stephen Lewis wrote: > Just a comment about this - I'm using a recent CVS version some time > after this was integrated, and it causes some display issues with a lot > of sites. In particular, sites that use narrow IFRAMEs for ads in a > table(e.g. http://www.osnews.com, http://arstechnica.com/ ). The > displayed URL seems to force the column width to be much, much wider > than it normally would, making these websites look very bad (very wide > column with ads, very narrow column with actual text :/ ) > > It's great having this patch apart from the display issues it causes. > Would it be possible to make the displayed URL wrap? > > I made it to replace the middle of long urls with ... for iframes: diff -pru -x CVS -x configure -x 'aclocal*' -x 'Makefile*' -x config.h.in cvs/dillo/src/html.c dillo/src/html.c --- cvs/dillo/src/html.c 2003-06-11 23:43:07.000000000 +0300 +++ dillo/src/html.c 2003-06-12 21:18:36.000000000 +0300 @@ -1603,12 +1612,12 @@ static void Html_tag_open_tr(DilloHtml * static void Html_tag_open_frame (DilloHtml *html, gchar *tag, gint tagsize) { const char *attrbuf; - gchar *src; + gchar *src, *buf, *name; DilloUrl *url; DwPage *page; DwStyle style_attrs, *link_style; DwWidget *bullet; - gint dummy; + gint dummy, len; page = DW_PAGE(html->dw); @@ -1641,10 +1650,18 @@ static void Html_tag_open_frame (DilloHt a_Dw_page_add_space(page, html->stack[html->stack_top].style); /* If 'name' tag is present use it, if not use 'src' value */ - if ( !(attrbuf = Html_get_attr(html, tag, tagsize, "name")) ) { + if ( !!(attrbuf = Html_get_attr(html, tag, tagsize, "name")) ) { + a_Dw_page_add_text(page, g_strdup(attrbuf), link_style); + } else if (tolower(tag[1]) != 'i' || (len = strlen(name = src)) < 16 || + (name += 7, len -= 7) < 16) { a_Dw_page_add_text(page, g_strdup(src), link_style); } else { - a_Dw_page_add_text(page, g_strdup(attrbuf), link_style); + buf = g_malloc(16); + memcpy(buf, name, 6); + strcpy(buf + 6, "..."); + memcpy(buf + 9, name + (len - 6), 6); + buf[15] = 0; + a_Dw_page_add_text(page, buf, link_style); } a_Dw_page_add_parbreak(page, 5, html->stack[(html)->stack_top].style);

June 14, 2003

Re: [Dillo-dev] IFRAME element stub

by Nikita V. Borodikhin

Hello, Stephen ! Stephen Lewis wrote: >> > There is a very small patch to support IFRAME HTML element. It does >> > nothing except handling IFRAME via FRAME handler so special IFAME >> > attributes(width and height) are not handled but this patch is >> > suitable for current temporary solution (as we do not have real >> > frame support for now). > > Just a comment about this - I'm using a recent CVS version some time > after this was integrated, and it causes some display issues with a lot > of sites. In particular, sites that use narrow IFRAMEs for ads in a > table(e.g. http://www.osnews.com, http://arstechnica.com/ ). The > displayed URL seems to force the column width to be much, much wider > than it normally would, making these websites look very bad (very wide > column with ads, very narrow column with actual text :/ ) > > It's great having this patch apart from the display issues it causes. > Would it be possible to make the displayed URL wrap? This is a consequence of currently used way to handle frames, as Links has. This IFRAME handler may be redesigned to use supplyed width and height, I think it is not too hard but I expect it is a _temporary_ solution intended just for having a link to IFRAME content until we do not have normal frames. > Stephen Lewis > slewis(a)paradise.net.nz Yours, Nikita

June 14, 2003

Re: [Dillo-dev] IFRAME element stub

by Stephen Lewis

On Wed, 11 Jun 2003 11:32:22 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > Nikita, > > > Hi all Dillo developers ! > > > > There is a very small patch to support IFRAME HTML element. It does > > nothing except handling IFRAME via FRAME handler so special IFAME > > attributes(width and height) are not handled but this patch is > > suitable for current temporary solution (as we do not have real > > frame support for now). > > Done! Just a comment about this - I'm using a recent CVS version some time after this was integrated, and it causes some display issues with a lot of sites. In particular, sites that use narrow IFRAMEs for ads in a table(e.g. http://www.osnews.com, http://arstechnica.com/ ). The displayed URL seems to force the column width to be much, much wider than it normally would, making these websites look very bad (very wide column with ads, very narrow column with actual text :/ ) It's great having this patch apart from the display issues it causes. Would it be possible to make the displayed URL wrap? -- Stephen Lewis slewis(a)paradise.net.nz

June 14, 2003