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