[webkit-dev] Desperate for webkit help

[Mark Pauley]

The bug is in the php tool, not in webkit.  From the RFC (rfc1341 http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) 
:

boundary := 0*69<bchars> bcharsnospace

bchars := bcharsnospace / " "

bcharsnospace :=    DIGIT / ALPHA / "'" / "(" / ")" / "+"  /
"_"
                / "," / "-" / "." / "/" / ":" / "=" / "?"

'+' is absolutely allowable, I'm betting that your upload tool source  
has a faulty regular expression for grabbing multipart boundaries.   
Perhaps what we really want here is a method of specifying the  
multipart boundary to webkit... and so allow all manner of hackers to  
work around parsing issues like this one without encouraging people to  
write crappy parsers.

or, you could grab the webkit source, hack a work-around and ship your  
own webkit dylib embedded in your app.  Let's not go tooling with code  
that works on millions of people's machines because of a fault in code  
that works on thousands of people's machines.


_Mark


On Apr 15, 2008, at 4:28 PM, Mark wrote:

> I don't have access to the script, but I can get the source. The  
> problem is this form demo from jmbsoft is installed of thousands of  
> thousands of sites that my software needs to submit to, and thus  
> since this webkit bug was introduced my software has real problems  
> with all these sites. All these forms worked fine prior to safari  
> 3....
>
> Who do I gotta pay to fix the bug :)
>
> On Wed, Apr 16, 2008 at 12:21 AM, David Kilzer <ddkilzer at webkit.org>  
> wrote:
> The issue appears to be that when WebKit sent a multipart/form-data  
> boundary
> with a "+" character in it, the server-side software wouldn't decode  
> the
> request properly.  (When there was no "+" character in the form  
> boundary,
> everything worked fine.)
>
> Mark didn't say what software he was using on the server side to  
> decode the
> HTML form data, but it probably requires a simple update to fix the  
> issue.
>
> Dave
>
>
> Mark <hoicem at googlemail.com> wrote:
>
> > Hi guys, many thanks for your advice. I'll check out the wireshark  
> thing for
> > sure. In the meantime I have managed to cobble together a demo so  
> you can
> > see hopefully the bug:
> > Please go here: http://demo.jmbsoft.com/cgi-bin/ags/submit.cgi
> >
> > Enter the following information:
> >
> > Username, Password: Leave Blank
> > Name:, Nickname: Whatever
> > Email: something at validemailaddress.com
> > Description: Enter a 30-40 character string wwerewr ewr
> > Gallery URL: http://www.intotheflood.com/webkit-demo/index.html
> > Category: Leave as is
> > Number of Thumbs: 12
> > Preview Thumb: choose "Let the script select an image from your  
> gallery"
> >
> > Now hit submit, it will either throw up a success(submission  
> recorded) or
> > invalid message. If you get success, hit back on your browser,  
> webkit should
> > remember all the information you entered, submit again and again and
> > eventually you should land upon an "invalid URL" or "Invalid email"
> > message.
> >
> > I'd be really interested to know if this does indeed happen for  
> you! You may
> > need to submit a lot of times before you get the error, or you may  
> get it
> > straight away.
> >
> > many thanks
> >
> > mark
> >
> > On Sat, Apr 12, 2008 at 1:37 AM, David Kilzer  
> <ddkilzer at webkit.org> wrote:
> >
> > > Hi Mark,
> > >
> > > The best thing you could do is to file a bug on <
> > > https://bugreport.apple.com/>
> > > and attach source for a project that reproduces the issue, along  
> with
> > > details
> > > steps to reproduce the issue.  If you don't have an Apple  
> Developer
> > > Connection
> > > (ADC) membership, sign up for a free "online" membership using
> > > <https://connect.apple.com/>.
> > >
> > > The second thing you should do is to install Wireshark (a packet  
> sniffer)
> > > on OS
> > > X and use it to capture the traffic being sent back and forth to  
> the
> > > server
> > > when the bug occurs.  (Since this generally requires either GTK  
> built for
> > > Cocoa
> > > or X11 to be installed--and using MacPorts or Fink to build it  
> from
> > > source--it
> > > may be easier to capture the traffic using "tcpdump" and copying  
> that file
> > > to
> > > another platform where you may install a pre-built Wireshark  
> binary.
> > >  Hmm...I
> > > guess there is a Wireshark binary for Intel Macs linked off the  
> Downloads
> > > page
> > > now.)
> > >
> > > http://www.wireshark.org/
> > > http://www.macports.org/
> > > http://fink.sourceforge.net/
> > >
> > > I would recommend attaching the tcpdump output to the bug  
> created on
> > > bugreport.apple.com as well.  This is roughly the command you  
> want to run
> > > (from
> > > a Terminal) to capture the output on OS X if you don't use  
> Wireshark
> > > directly:
> > >
> > > sudo tcpdump -s 0 -w packets.tcpdump -i en0
> > >
> > > Finally, this kind of sounds like the issue described in this  
> bug on
> > > bugs.webkit.org:
> > >
> > > https://bugs.webkit.org/show_bug.cgi?id=5760#c38
> > >
> > > If you know enough about the TCP/IP protcol, you should be able  
> to see
> > > this
> > > issue happening with the tcpdump packet trace.
> > >
> > > Note that the behavior of this keep-alive timeout issue can vary  
> depending
> > > on
> > > how "far away" the server is from your client.  I think servers  
> on a local
> > > network (or subnet) display this behavior much easier than  
> hitting a
> > > "remote"
> > > server.
> > >
> > > Hope that helps!
> > >
> > > Dave
> > >
> > >
> > > Mark <hoicem at googlemail.com> wrote:
> > >
> > > > Hi. I've been developing a cocoa application based around  
> webkit for the
> > > > last 18 months. It's an auto form filling/submitting tool  
> primarily
> > > designed
> > > > for adult webmasters to submit their free pages to link lists.  
> (If this
> > > is
> > > > an problem I guess you can stop reading now)...
> > > > Currently development has grinded to a complete hault because  
> of a
> > > webkit
> > > > issue that we just can't work round. We first noticed the  
> issue with the
> > > > release of Safari 3 but it still exists in the last nightly  
> build of
> > > webkit.
> > > > The issue is this: imagine a simple html form. The form is  
> like so and
> > > the
> > > > user filled data is in brackets:
> > > >
> > > > Name: (mark)
> > > > Email: (whatever at qwerty123456.com)
> > > > Url: (http://www.google.com)
> > > >
> > > > Now if we submit this form in Safari/Webkit, 40-50% of the  
> time the web
> > > > script will throw up an 'invalid email' or 'invalid url'  
> message. At
> > > first
> > > > you think 'oh, I must have entered data incorrectly' but  
> clicking back,
> > > data
> > > > looks fine. Submit same data again, second time round it  
> submits fine!
> > > >
> > > > It seems to happen totally at random, it's like the data  
> visible in the
> > > form
> > > > fields (ie, the user entered data) is not being passed onto  
> the form
> > > when
> > > > submit is pressed. It worked fine prior to safari 3 and we  
> know it's a
> > > > webkit issue because it only occurs in our app/safari/webkit.  
> Other
> > > browsers
> > > > submit the same data perfectly each time to the exact same  
> html forms.
> > > >
> > > > It's very hard to nail down. Sometimes it will submit fine  
> first time,
> > > > sometimes if it fails first time, it can fail second time and  
> then
> > > succeed
> > > > third time. You just have to keep submitting the same data  
> until it
> > > works.
> > > >
> > > > Can anyone please help with this? It's kinda killed our  
> application and
> > > as
> > > > the title suggests I'm *desperate* for it to be fixed.
> > > >
> > > > kindest regards
> > > >
> > > > mark
> > >
> > >
> >
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080416/dbe1c7af/attachment.html