[webkit-dev] Desperate for webkit help

[David Kilzer]

Before Safari 3, the boundary string was always:

----------0xKhTmLbOuNdArY

This apparently doesn't violate any assumptions made by the scripts you use.

As for other browsers, you'd have to test them yourself, but apparently they
never use "+" characters in their multipart/form-data boundaries.

Dave


Mark <hoicem at googlemail.com> wrote:

> I should have probably said I don't actually code myself. I merely design
> the software so I'll have to pass on all this information to my coder as
> some of it is a bit above my head..
> What I don't understand is, is the fault is with the script somehow. Why did
> the exact same scripts work perfectly prior to safari 3? Also, every other
> browser on window/mac doesn't have this issue. The developer who created the
> script (jmbsoft) is no longer updating it but it still has a large installed
> base like I said.
> 
> thanks for you help guys
> 
> On Wed, Apr 16, 2008 at 6:32 PM, Mark Pauley <mpauley at apple.com> wrote:
> 
> > 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
> >
> >
> >
> > _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>