Re: [webkit-dev] Desperate for webkit help
On Jun 25, 2008, at 7:37 AM, Mark wrote: Well, it's been a few months since a posted this message and filed this bug: https://bugs.webkit.org/show_bug.cgi?id=18539 We haven't been able to find a work around at all, every single thing we do doesn't work. So I'm making a plea again, can anyone please address this issue?? I'm so desperate for help now that we're close to shutting down a project that's been in the works for almost 2 years because of this one single + boundary problem. I'll happily pay anyone who agrees to fix the problem. Have you done any debugging to diagnose the problem? The speculation last time around seemed to be that the web application you were posting to was broken and didn't understand mime format. Have you captured the traffic from successful and unsuccessful posts to confirm that the issue is broken mime parsing in the webapp? Wireshark is the go-to tool for that. Do you have test case code that will post fixed messages to the webapp with different mime boundaries? Does that confirm the problem? If it does, have you presented that data to the webapp developers? Cheers, Steve regards On Sat, Apr 12, 2008 at 1:06 AM, 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.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Desperate for webkit help
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*69bchars 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!
Re: [webkit-dev] Desperate for webkit help
It used to be worse! At one time we originally allowed all the legal values for base64 encoding in the boundary string: http://trac.webkit.org/projects/webkit/changeset/20074 But then it was changed: https://bugs.webkit.org/show_bug.cgi?id=13352 http://trac.webkit.org/projects/webkit/changeset/22013 And a related change: http://trac.webkit.org/projects/webkit/changeset/20136 Dave 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*69bchars 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
Re: [webkit-dev] Desperate for webkit help
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*69bchars 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
Re: [webkit-dev] Desperate for webkit help
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*69bchars 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
Re: [webkit-dev] Desperate for webkit help
Hi Mark, On Apr 16, 2008, at 10:32 AM, Mark Pauley 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*69bchars 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. You are correct by the letter of the spec that + is allowed in the boundary separator. However, this is not the first time we've had a site break in WebKit-based browsers when it worked fine in other browsers, due to our choice of boundary characters. Even though the spec allows a wide character set, I think it would be wise to limit the characters we use to those sent by other browsers, since some web developers develop against IE/Firefox and test against Safari as an afterthought, if at all. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Desperate for webkit help
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
Re: [webkit-dev] Desperate for webkit help
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
Re: [webkit-dev] Desperate for webkit help
Mark, You should test my theory (it's only a theory at this point) to make sure it's correct before you assume that you'll have to update the script thousands of web sites. If it is a bug in the script, perhaps you should take the opportunity to devise a way to push out future updates in case you have to upgrade the script again in the future. :) Dave Mark [EMAIL PROTECTED] 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
Re: [webkit-dev] Desperate for webkit help
Scott Thompson [EMAIL PROTECTED] wrote: On Apr 11, 2008, at 7:37 PM, David Kilzer wrote: 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 third thing you COUDLD do is purchase a DTS incident from ADC and see if you can engage someone at Apple to help you track down and fix your bug. It will cost you money, but if it helps you fix the bug quickly, it can pay for itself. Good point, Scott! The ADC Select Membership includes 2 technical support incidents while the ADC Premiere Membership includes 8 technical incidents. More details here (click on the first FAQ item to disclose the text): http://developer.apple.com/faq/membership.html WebKit (as part of Mac OS X) or any lower-level frameworks would definitely be covered. It would be a good idea to still file a bug report as well as being able to provide (reduced) source that reproduces the issue. That will definitely help get the issue resolved quicker. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Desperate for webkit help
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
Re: [webkit-dev] Desperate for webkit help
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
Re: [webkit-dev] Desperate for webkit help
On Apr 11, 2008, at 7:37 PM, David Kilzer wrote: 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 third thing you COUDLD do is purchase a DTS incident from ADC and see if you can engage someone at Apple to help you track down and fix your bug. It will cost you money, but if it helps you fix the bug quickly, it can pay for itself. I don't know about the relationship between DTS and WebKit, but you could call ADC and ask. Scott ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
