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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> 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
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: ([EMAIL PROTECTED])
> > > 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
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
