- Dillo-dev - lists.mailman3.com

What shall we do with the buggy RFC?

by onepoint＠starurchin.org

On Sat, Mar 01, 2008 at 05:15:52PM +0000, I wrote: > "?y" as an example URI. That example also parses according to the > regular expression they provide: > > $ perl -wnle 'print if m(^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?$)' <<< '?foo=bar' > ?foo=bar > $ Heh, that turns out to be a vacuous remark. The regular expression matches *any* string! Jeremy Henty

March 1, 2008

What shall we do with the buggy RFC?

by onepoint＠starurchin.org

On Sat, Mar 01, 2008 at 05:16:13PM +0100, Joerg Sonnenberger wrote: > On Sat, Mar 01, 2008 at 03:56:35PM +0000, Jeremy Henty wrote: > > The problem appears when resolving a relative URI reference such > > as "?foo=bar" relative to a URI such as "http://a.b.c/e/f".i > > I don't think that's a valid relative URI, RFC 2396 disagrees. Section "C.1. Normal Examples" explicitly cites "?y" as an example URI. That example also parses according to the regular expression they provide: $ perl -wnle 'print if m(^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?$)' <<< '?foo=bar' ?foo=bar $ > ... but I would threat the empty path component as ".". I think that would be consistent with RFC 2396 but not the earlier RFC 1808. As I said elsewhere I think RFC 1808 is clearly right on this point and I'm puzzled that RFC 2396 does not explain or even mention the change. Regards, Jeremy Henty

March 1, 2008

What shall we do with the buggy RFC?

by onepoint＠starurchin.org

On Sat, Mar 01, 2008 at 03:56:35PM +0000, Jeremy Henty (ie. *me*) wrote: > The problem appears when resolving a relative URI reference such as > "?foo=bar" relative to a URI such as "http://a.b.c/e/f". Dillo > resolves this to "http://a.b.c/e?foo=bar" ie. it loses the last > path component. I was slightly wrong. Dillo actually resolves the relative URI reference to "http://a.b.c/e/?foo=bar" (notice the trailing '/' in the path). However the example page I gave returns a redirect that strips the '/'. > Clearly Dillo should only lose the last path component of the base > URI when the path of the relative is non-empty. I've just noticed that RFC 2396 explicitly disagrees with me. From section C: C. Examples of Resolving Relative URI References Within an object with a well-defined base URI of http://a/b/c/d;p?q the relative URI would be resolved as follows: C.1. Normal Examples [snip] ?y = http://a/b/c/?y Interestingly, RFC 1808 explicitly agrees with me. 5. Examples and Recommended Practice Within an object with a well-defined base URL of Base: <URL:http://a/b/c/d;p?q#f> the relative URLs would be resolved as follows: 5.1. Normal Examples [snip] ?y = <URL:http://a/b/c/d;p?y> Even odder, in RFC 2396 "G.4. Modifications from RFC 1808" there is no mention of this change. It seems that they made the change but forgot to explain why. Weirderer and weirderer! Jeremy Henty

March 1, 2008

What shall we do with the buggy RFC?

by joerg.sonnenberger＠web.de

On Sat, Mar 01, 2008 at 03:56:35PM +0000, Jeremy Henty wrote: > The problem appears when resolving a relative URI reference such as > "?foo=bar" relative to a URI such as "http://a.b.c/e/f".i I don't think that's a valid relative URI, but I would threat the empty path component as ".". Joerg

March 1, 2008

What shall we do with the buggy RFC?

by onepoint＠starurchin.org

Dillo is buggy because RFC2396 is buggy! An outrageous claim, I know, but hear me out! The problem appears when resolving a relative URI reference such as "?foo=bar" relative to a URI such as "http://a.b.c/e/f". Dillo resolves this to "http://a.b.c/e?foo=bar" ie. it loses the last path component. This is clearly wrong, and it breaks pages such as http://www.guardian.co.uk/business/gallery/2008/jan/18/1?picture=332092597 (trying clicking on the big picture - you won't get the next one in the gallery). Clearly Dillo should only lose the last path component of the base URI when the path of the relative is non-empty. Nevertheless, this broken behaviour *is* RFC compliant! If we study the 7 steps in "5.2. Resolving Relative References to Absolute Form" of RFC2396 we see a problem in step 6, which begins: a) All but the last segment of the base URI's path component is copied to the buffer. In other words, any characters after the last (right-most) slash character, if any, are excluded. So we are instructed to lose the last path component in all cases. Unfortunately we get to step 6 if the URI reference is "?foo=bar". Hence the breakage. Patch attached. Jeremy Henty

March 1, 2008

patch: multipart/form-data encoding for form submission

by jcid＠dillo.org

Hi, On Fri, Feb 29, 2008 at 10:37:04PM +0000, place wrote: > > Have you tried something like?: > > > > </pseudocode> > > > > Html_submit_form2() > > ... > > if (ENC_MULTIPART) { > > append every single "name" "value" pair into a Dstr > > do { > > make boundary > > } while (strstr(Dstr, boundary) || maxtries); > > } > > ... > > encode as usual. > > > > </pseudocode> > > > > If yes, why does it fail? > > I hadn't looked at that specifically. Let's see... > > To avoid duplicating the big case statement, I'd want to make a > char *Html_get_input_value(input) > { > switch (input->type) { > ... > } > return value; > } > > if (ENC_MULTIPART) { > for (each input in the form) { > value = Html_get_input_value(input); > dStr_append(data, name); > dStr_append(data, value); > } > ...boundary... etc. ... > } OK. > > But for a file input, it could have embedded nulls, so make > Html_get_input_value() return a Dstr* instead. Okay. > > But for an image input, thanks to clickpos, I'd have to make > it return a list of name/value pairs. Maybe that's not too > bad, but it does put me in a bit of a "stupid HTML and its > stupid special cases!" mood. Don't worry about clickpos. Provided the current boundary skeleton it doesn't need to be checked. A comment stating this should be added. > Random thought: I wonder whether url->data gets eradicated after sending > somehow, or if copies of it stick around in copies of the url on, I don't > know, the nav stack or whatever. If there are copies floating around, > that'll be no fun if they were each to contain a big file input in their data. Yes, it should be checked when file input is implemented. > > PS: I usually manually delete the CC of my replies to you, thinking > > that you'll get it from dillo-dev. Do you want the extra copy? > > I know someone who, when cc:ed, tends to say "I read the list" :) Wise guy! ;-) -- Cheers Jorge.-

March 1, 2008

patch: multipart/form-data encoding for form submission

by place＠gobigwest.com

Jorge wrote: > On Fri, Feb 29, 2008 at 06:19:31PM +0000, place wrote: > > Jorge wrote: > > > > > > > - This patch always uses the same boundary, but a different > > > > one REALLY should be used for every form submission. At > > > > the least, the string should be scrambled up somehow. > > > > > > Yes, please finish that part. > > > > > > Probably checking the boundary string against URL_DATA, > > > with strstr is a good idea too. > > > > Attached. > > > > I'm not proud of this code, but special cases > > were getting in the way of attempts at cleanup. > > Have you tried something like?: > > </pseudocode> > > Html_submit_form2() > ... > if (ENC_MULTIPART) { > append every single "name" "value" pair into a Dstr > do { > make boundary > } while (strstr(Dstr, boundary) || maxtries); > } > ... > encode as usual. > > </pseudocode> > > If yes, why does it fail? I hadn't looked at that specifically. Let's see... To avoid duplicating the big case statement, I'd want to make a char *Html_get_input_value(input) { switch (input->type) { ... } return value; } if (ENC_MULTIPART) { for (each input in the form) { value = Html_get_input_value(input); dStr_append(data, name); dStr_append(data, value); } ...boundary... etc. ... } But for a file input, it could have embedded nulls, so make Html_get_input_value() return a Dstr* instead. Okay. But for an image input, thanks to clickpos, I'd have to make it return a list of name/value pairs. Maybe that's not too bad, but it does put me in a bit of a "stupid HTML and its stupid special cases!" mood. Random thought: I wonder whether url->data gets eradicated after sending somehow, or if copies of it stick around in copies of the url on, I don't know, the nav stack or whatever. If there are copies floating around, that'll be no fun if they were each to contain a big file input in their data. > PS: I usually manually delete the CC of my replies to you, thinking > that you'll get it from dillo-dev. Do you want the extra copy? I know someone who, when cc:ed, tends to say "I read the list" :)

Feb. 29, 2008

patch: multipart/form-data encoding for form submission

by jcid＠dillo.org

On Fri, Feb 29, 2008 at 06:19:31PM +0000, place wrote: > Jorge wrote: > > > > > - This patch always uses the same boundary, but a different > > > one REALLY should be used for every form submission. At > > > the least, the string should be scrambled up somehow. > > > > Yes, please finish that part. > > > > Probably checking the boundary string against URL_DATA, > > with strstr is a good idea too. > > Attached. > > I'm not proud of this code, but special cases > were getting in the way of attempts at cleanup. Have you tried something like?: </pseudocode> Html_submit_form2() ... if (ENC_MULTIPART) { append every single "name" "value" pair into a Dstr do { make boundary } while (strstr(Dstr, boundary) || maxtries); } ... encode as usual. </pseudocode> If yes, why does it fail? -- Cheers Jorge.- PS: I usually manually delete the CC of my replies to you, thinking that you'll get it from dillo-dev. Do you want the extra copy?

Feb. 29, 2008

patch: multipart/form-data encoding for form submission

by place＠gobigwest.com

Jorge wrote: > > > - This patch always uses the same boundary, but a different > > one REALLY should be used for every form submission. At > > the least, the string should be scrambled up somehow. > > Yes, please finish that part. > > Probably checking the boundary string against URL_DATA, > with strstr is a good idea too. Attached. I'm not proud of this code, but special cases were getting in the way of attempts at cleanup.

Feb. 29, 2008

[patch] redraw optimization now including tables

by jcid＠dillo.org

Hi, > > [...] > > From a distance it looks like a conditionalRedraw() may be the needed call > > (I don't know well what expose means). I mean if this conditional redraw > > sees that nothing has changed in the specified area, it can simply return, > > otherwise redraw. > > Yes, that's the idea of the new virtual method resizeDrawImpl(). > Each widget can remember what has already been drawn and what might > have changed because of resizes and then draw only the necessary > parts. It depends on each widget how careful it is. > Tables have the unfortunate property of changing their layout all over > when new cells are added thereby requiring complete redraws. We may track the colWidths vector. If it doesn't change, layout is kept. > > > The redrawing is left > > > to the Table-code, which then can be optimized. > > > Please test carefully and report any anomalies you find. > > > > I haven't found any anomalies. :-) > > Excellent. Then please commit this one. I will try to improve upon > this. Patch committed. Thanks for the explanations. I'll give it some testing when having some time. -- Cheers Jorge.-

Feb. 29, 2008