[webkit-dev] Desperate for webkit help

[Mark]

Ok, I submitted a bug: 18539
Hope it's ok!

regards

mark

On Wed, Apr 16, 2008 at 7:38 PM, Mark Pauley <mpauley at apple.com> wrote:

> Ah, the internets.  The simple "fix" to this would be:
> << 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x2B, 0x41
> >> 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x42, 0x41
>
> Mark: do you have a bugzilla account?  Could you file a bug on this and
> post the reference id?
>
>
> thanks
>
> _Mark
>
> On Apr 16, 2008, at 11:19 AM, David Kilzer wrote:
>
> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080416/37c1862d/attachment-0001.html