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

patch: multipart/form-data encoding for form submission

by jcid＠dillo.org

Hi, On Sun, Mar 02, 2008 at 01:25:28AM +0000, place wrote: > Jorge wrote: > > 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> > > I gave it a try and ended up with the attached compiles-but-hardly-tested > code. I had somehow forgotten earlier that I was going to have to use > Dlists of values due to SELECT elements. > > This runs through the inputs once for boundary creation, and > a second time for url->data creation. > > I was tempted to try > - go through once, making a Dlist of name/value pairs > - if (MULTIPART) determine a boundary, strstr()ing names and values > - give each pair in the Dlist to Html_append_input > but that's no good because I wouldn't know whether I had data from > a file input when making url->data (Content-Disposition is different). > > > Thoughts? Yes. As form-submitting is not a frequent operartion, much less with multipart, there's no compelling need to optimize it further. This version of the patch is easier to read and understand. Please comment the Html_get_input_values() function. For: > + // BUG: strstr stops at NULL. Cannot use for file inputs. > + success = !strstr(DataStr->str, boundary->str); please use memcmp(). Some basic testing would be welcomed, but the main probe will be done by usage when committed. -- Cheers Jorge.-

March 2, 2008

a drawing segfault

by jcid＠dillo.org

On Sun, Mar 02, 2008 at 06:30:03AM +0000, place wrote: > I was just opening file:///tmp/, which is not normally a problem... Yesterday I committed a patch just for this! Please check the CVS and send some feedback. -- Cheers Jorge.-

March 2, 2008

a drawing segfault

by place＠gobigwest.com

I was just opening file:///tmp/, which is not normally a problem... *** [unknown] Assertion failed! *** Array index out of bounds: 28 >= 28 Program received signal SIGABRT, Aborted. [Switching to Thread 16384 (LWP 31812)] 0x40344c81 in kill () from /lib/libc.so.6 (gdb) bt #0 0x40344c81 in kill () from /lib/libc.so.6 #1 0x401b04a1 in pthread_kill () from /lib/libpthread.so.0 #2 0x401b087b in raise () from /lib/libpthread.so.0 #3 0x403448f8 in raise () from /lib/libc.so.6 #4 0x40345f00 in abort () from /lib/libc.so.6 #5 0x0806e0ac in misc::assert (cond=false, format=0x8109030 "Array index out of bounds: %d >= %d") at ../lout/misc.hh:46 #6 0x0807ca1e in misc::SimpleVector<int>::get (this=0x81f1ff0, i=28) at ../lout/misc.hh:183 #7 0x0807b3d7 in dw::Table::draw (this=0x81b1128, view=0x8152d68, area=0xbffff414) at table.cc:242 #8 0x0807f708 in dw::Textblock::drawLine (this=0x8238228, line=0x8221594, view=0x8152d68, area=0xbffff4c8) at textblock.cc:1364 #9 0x0807f827 in dw::Textblock::draw (this=0x8238228, view=0x8152d68, area=0xbffff4c8) at textblock.cc:1500 #10 0x0809c2aa in dw::core::Layout::draw (this=0x8152808, view=0x8152d68, area=0xbffff568) at layout.cc:402 #11 0x08096b55 in dw::core::Layout::expose (this=0x8152808, view=0x8152d68, area=0xbffff568) at layout.hh:163 #12 0x08095fc0 in dw::fltk::FltkViewBase::draw (this=0x8152d68) at fltkviewbase.cc:113 #13 0x08090c4f in dw::fltk::FltkViewport::draw_area (data=0x8152d68, ---Type <return> to continue, or q <return> to quit--- cr=@0xbffff728) at fltkviewport.cc:168 #14 0x080d7167 in fltk::scrollrect (r=@0xbffff728, dx=0, dy=2526, draw_area=0x8090c28 <dw::fltk::FltkViewport::draw_area(void*, fltk::Rectangl e const&)>, data=0x8152d68) at scrollrect.cxx:115 #15 0x08090dfe in dw::fltk::FltkViewport::draw (this=0x8152d68) at fltkviewport.cc:189 #16 0x080bbc4b in fltk::Group::update_child (this=0x8140b40, w=@0x8152d6c) at Group.cxx:769 #17 0x080bc85a in fltk::Group::draw (this=0x8140b40) at Group.cxx:697 #18 0x080bbc4b in fltk::Group::update_child (this=0x81416d0, w=@0x8140b40) at Group.cxx:769 #19 0x080bc85a in fltk::Group::draw (this=0x81416d0) at Group.cxx:697 #20 0x080d3ed0 in fltk::Window::flush (this=0x81416d0) at x11/run.cxx:2559 #21 0x080d13ac in fl_window_flush (window=0x81416d0) at run.cxx:651 #22 0x080d146c in fltk::flush () at run.cxx:685 #23 0x080d6297 in fltk::wait (time_to_wait=0) at run.cxx:480 #24 0x080d62fd in fltk::run () at run.cxx:393 #25 0x0804ef03 in main (argc=1, argv=0xbffffb44) at dillo.cc:110

March 2, 2008

patch: multipart/form-data encoding for form submission

by place＠gobigwest.com

Jorge wrote: > 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> I gave it a try and ended up with the attached compiles-but-hardly-tested code. I had somehow forgotten earlier that I was going to have to use Dlists of values due to SELECT elements. This runs through the inputs once for boundary creation, and a second time for url->data creation. I was tempted to try - go through once, making a Dlist of name/value pairs - if (MULTIPART) determine a boundary, strstr()ing names and values - give each pair in the Dlist to Html_append_input but that's no good because I wouldn't know whether I had data from a file input when making url->data (Content-Disposition is different). Thoughts?

March 2, 2008