18539 2008-04-16 12:54:53 -0700 multipart/form-data not being parsed correctly on server due to '+' in boundary string 2009-11-02 11:01:03 -0800 1 1 1 Unclassified WebKit Forms 528+ (Nightly build) All All RESOLVED FIXED http://lists.webkit.org/pipermail/webkit-dev/2008-April/003770.html P2 Normal --- 1 hoicem ap ddkilzer jonasmunk oldest_to_newest 77851 0 hoicem 2008-04-16 12:54:53 -0700 Often user entered data submitted via an HTML form is received incorrectly by the web script. Here is an example: 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@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. The same demo URL works fine in all other browsers tested on both Mac and Windows platforms. Also, the same exact form worked fine prior to Safari 3, it's only since then that this problem has started happening. After discussing the problem with the experts on the webkit dev list the general opinion seems to be: "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.)" - David Kilzer "I'm betting that your upload tool source has a faulty regular expression for grabbing multipart boundaries" - Mark Pauley 77858 1 ddkilzer 2008-04-16 13:35:22 -0700 Mark, it would be nice to know what software is being used to parse the boundary string, e.g., if it's custom in-house code or if it's a third-party framework (e.g. in PHP, Perl, Ruby or some other scripting language). 77864 2 hoicem 2008-04-16 15:12:35 -0700 (In reply to comment #1) > Mark, it would be nice to know what software is being used to parse the > boundary string, e.g., if it's custom in-house code or if it's a third-party > framework (e.g. in PHP, Perl, Ruby or some other scripting language). > I'm informed by JMBSoft that's it's "pure Perl using all custom in-house code". Would it help if I tried to get the code that handles the form when submitted? 77874 3 ddkilzer 2008-04-16 17:02:07 -0700 (In reply to comment #2) > I'm informed by JMBSoft that's it's "pure Perl using all custom in-house code". > Would it help if I tried to get the code that handles the form when submitted? Are they using CGI.pm to do the form parsing, or something else? You should point them at this bug to see if they can reproduce the issue on their own and fix it. Note that Safari for Windows should behave the same as Safari for Mac OS X. 77876 4 hoicem 2008-04-16 17:22:35 -0700 (In reply to comment #3) > (In reply to comment #2) > > I'm informed by JMBSoft that's it's "pure Perl using all custom in-house code". > > Would it help if I tried to get the code that handles the form when submitted? > > Are they using CGI.pm to do the form parsing, or something else? You should > point them at this bug to see if they can reproduce the issue on their own and > fix it. > > Note that Safari for Windows should behave the same as Safari for Mac OS X. > I've asked for the source. Having them try and fix anything isn't going to happen because this script is an old version and I get the impression. It just happens to be used by lots of sites which my webkit app needs to submit to. Also, I would assume that they'll be other forms that may use a similar method/script. All worked fine prior to Safari 3 so what changed in Safari 3? I just tested on windows platform Safari 3. At first I thought the bug wasn't present as I submitted about 50 times and got success every time. However, I eventually did get the error message but this only seemed to happen when I click back and submitted really quickly. 126771 5 jonasmunk 2009-06-18 14:19:52 -0700 I have the same problem with PHP (Server header: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8j DAV/2 PHP/5.2.9) on Mac OS X i believe it is MacPorts. I have the same problem on work with a Jetty (Java) Server. So it may not be related to the server. Seemingly random the upload stalls and the request never completes. The PHP script never gets executed. This goes well: multipart/form-data; boundary=----WebKitFormBoundaryVtOqm3BbxLwP0yja multipart/form-data; boundary=----WebKitFormBoundaryu5as9Aihe0bbIcgv multipart/form-data; boundary=----WebKitFormBoundaryLlrh0UVE2KYWV5g3 multipart/form-data; boundary=----WebKitFormBoundary1W9R55FRA2GneO7e This goes wrong: multipart/form-data; boundary=----WebKitFormBoundaryWISbcqWfZg4l+qej multipart/form-data; boundary=----WebKitFormBoundaryGAz1V0M1nRZkKq4w multipart/form-data; boundary=----WebKitFormBoundaryOAQK+G7Ylci9Ca9X multipart/form-data; boundary=----WebKitFormBoundaryWaUfqbq5fRdQ5LlL You should really consider looking into this. Also see: http://discussions.apple.com/thread.jspa?messageID=9591586 http://code.google.com/p/support/issues/detail?id=2581 (In reply to comment #3) > (In reply to comment #2) > > I'm informed by JMBSoft that's it's "pure Perl using all custom in-house code". > > Would it help if I tried to get the code that handles the form when submitted? > > Are they using CGI.pm to do the form parsing, or something else? You should > point them at this bug to see if they can reproduce the issue on their own and > fix it. > > Note that Safari for Windows should behave the same as Safari for Mac OS X. > 159848 6 42326 ap 2009-11-02 10:50:49 -0800 Created attachment 42326 proposed fix I don't see a reason not to limit the set of characters further. 159852 7 ap 2009-11-02 11:01:03 -0800 Committed <http://trac.webkit.org/changeset/50421>. 42326 2009-11-02 10:50:49 -0800 2009-11-02 10:57:25 -0800 proposed fix PlusInBoundary.txt text/plain 3228 ap SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA1MDQxOSkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTcgQEAKKzIwMDktMTEtMDIgIEFsZXhleSBQcm9za3VyeWFrb3YgIDxhcEBhcHBs ZS5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAg aHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE4NTM5CisgICAgICAgIG11 bHRpcGFydC9mb3JtLWRhdGEgbm90IGJlaW5nIHBhcnNlZCBjb3JyZWN0bHkgb24gc2VydmVyIGR1 ZSB0byAnKycgaW4gYm91bmRhcnkgc3RyaW5nCisKKyAgICAgICAgTm8gdGVzdCAtIHRoZSBjaGFy YWN0ZXJzIHRoYXQgdGhlIGJvdW5kYXJ5IGlzIG1hZGUgb2YgYXJlIG5vdCBkZXRlcm1pbmlzdGlj LgorCisgICAgICAgICogcGxhdGZvcm0vbmV0d29yay9Gb3JtRGF0YUJ1aWxkZXIuY3BwOiAoV2Vi Q29yZTo6Rm9ybURhdGFCdWlsZGVyOjpnZW5lcmF0ZVVuaXF1ZUJvdW5kYXJ5U3RyaW5nKToKKyAg ICAgICAgRG9uJ3QgZXZlciBwdXQgYSAnKycgaW4gYm91bmRhcnkgc3RyaW5nLCBlaXRoZXIuIFJl bW92ZWQgYSBGSVhNRSB0byBicmluZyAnLycgYmFjayBvbmNlCisgICAgICAgIEdNYWlsIGlzIGZp eGVkIC0gSSBkb24ndCB0aGluayB3ZSdsbCBldmVyIHdhbnQgdG8gYWxsb3cgbm9uLWFscGhhbnVt ZXJpYyBjaGFyYWN0ZXJzLCBhcworICAgICAgICB0aGV5IGNhdXNlIHByb2JsZW1zIG9uIG1hbnkg d2ViIHNpdGVzLgorCiAyMDA5LTEwLTMwICBBbGV4ZXkgUHJvc2t1cnlha292ICA8YXBAYXBwbGUu Y29tPgogCiAgICAgICAgIFJldmlld2VkIGJ5IERhcmluIEFkbGVyLgpJbmRleDogV2ViQ29yZS9w bGF0Zm9ybS9uZXR3b3JrL0Zvcm1EYXRhQnVpbGRlci5jcHAKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29y ZS9wbGF0Zm9ybS9uZXR3b3JrL0Zvcm1EYXRhQnVpbGRlci5jcHAJKHJldmlzaW9uIDUwNDE4KQor KysgV2ViQ29yZS9wbGF0Zm9ybS9uZXR3b3JrL0Zvcm1EYXRhQnVpbGRlci5jcHAJKHdvcmtpbmcg Y29weSkKQEAgLTE0Myw3ICsxNDMsMTAgQEAgVmVjdG9yPGNoYXI+IEZvcm1EYXRhQnVpbGRlcjo6 Z2VuZXJhdGVVbgogICAgIC8vIFRoZSBSRkMgMjA0NiBzcGVjIHNheXMgdGhlIGFscGhhbnVtZXJp YyBjaGFyYWN0ZXJzIHBsdXMgdGhlCiAgICAgLy8gZm9sbG93aW5nIGNoYXJhY3RlcnMgYXJlIGxl Z2FsIGZvciBib3VuZGFyaWVzOiAgJygpK18sLS4vOj0/CiAgICAgLy8gSG93ZXZlciB0aGUgZm9s bG93aW5nIGNoYXJhY3RlcnMsIHRob3VnaCBsZWdhbCwgY2F1c2Ugc29tZSBzaXRlcwotICAgIC8v IHRvIGZhaWw6ICgpLC4vOj0gKGh0dHA6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lk PTEzMzUyKQorICAgIC8vIHRvIGZhaWw6ICgpLC4vOj0rCisgICAgLy8gTm90ZSB0aGF0IG91ciBh bGdvcml0aG0gbWFrZXMgaXQgdHdpY2UgYXMgbXVjaCBsaWtlbHkgZm9yICdBJyBvciAnQicKKyAg ICAvLyB0byBhcHBlYXIgaW4gdGhlIGJvdW5kYXJ5IHN0cmluZywgYmVjYXVzZSAweDQxIGFuZCAw eDQyIGFyZSBwcmVzZW50IGluCisgICAgLy8gdGhlIGJlbG93IGFycmF5IHR3aWNlLgogICAgIHN0 YXRpYyBjb25zdCBjaGFyIGFscGhhTnVtZXJpY0VuY29kaW5nTWFwWzY0XSA9IHsKICAgICAgICAg MHg0MSwgMHg0MiwgMHg0MywgMHg0NCwgMHg0NSwgMHg0NiwgMHg0NywgMHg0OCwKICAgICAgICAg MHg0OSwgMHg0QSwgMHg0QiwgMHg0QywgMHg0RCwgMHg0RSwgMHg0RiwgMHg1MCwKQEAgLTE1Miwx OCArMTU1LDcgQEAgVmVjdG9yPGNoYXI+IEZvcm1EYXRhQnVpbGRlcjo6Z2VuZXJhdGVVbgogICAg ICAgICAweDY3LCAweDY4LCAweDY5LCAweDZBLCAweDZCLCAweDZDLCAweDZELCAweDZFLAogICAg ICAgICAweDZGLCAweDcwLCAweDcxLCAweDcyLCAweDczLCAweDc0LCAweDc1LCAweDc2LAogICAg ICAgICAweDc3LCAweDc4LCAweDc5LCAweDdBLCAweDMwLCAweDMxLCAweDMyLCAweDMzLAotICAg ICAgICAweDM0LCAweDM1LCAweDM2LCAweDM3LCAweDM4LCAweDM5LCAweDJCLCAweDQxCi0gICAg ICAgIC8vIEZJWE1FIDxyZGFyOi8vcHJvYmxlbS81MjUyNTc3PiBnbWFpbCBkb2VzIG5vdCBhY2Nl cHQgbGVnYWwgY2hhcmFjdGVycyBpbiB0aGUgZm9ybSBib3VuZGFyeQotICAgICAgICAvLyBBcyBz dGF0ZWQgYWJvdmUsIHNvbWUgbGVnYWwgY2hhcmFjdGVycyBjYXVzZSwgc2l0ZXMgdG8gZmFpbC4g U3BlY2lmaWNhbGx5Ci0gICAgICAgIC8vIHRoZSAvIGNoYXJhY3RlciB3aGljaCB3YXMgdGhlIGxh c3QgY2hhcmFjdGVyIGluIHRoZSBhYm92ZSBhcnJheS4gSSBoYXZlCi0gICAgICAgIC8vIHJlcGxh Y2VkIHRoZSBsYXN0IGNoYXJhY3RlciB3aXRoIGFub3RoZXIgY2hhcmFjdGVyIGFscmVhZHkgaW4g dGhlIGFycmF5Ci0gICAgICAgIC8vIChub3RpY2UgdGhlIGZpcnN0IGFuZCBsYXN0IHZhbHVlcyBh cmUgYm90aCAweDQxLCBBKS4gSW5zdGVhZCBvZiBwaWNraW5nCi0gICAgICAgIC8vIGFub3RoZXIg dW5pcXVlIGxlZ2FsIGNoYXJhY3RlciBmb3IgYm91bmRhcnkgc3RyaW5ncyB0aGF0LCBiZWNhdXNl IGl0IGhhcwotICAgICAgICAvLyBuZXZlciBiZWVuIHRlc3RlZCwgbWF5IG9yIG1heSBub3QgYnJl YWsgb3RoZXIgc2l0ZXMsIEkgc2ltcGx5Ci0gICAgICAgIC8vIHJlcGxhY2VkIC8gd2l0aCBBLiAg VGhpcyBtZWFucyBBIGlzIHR3aWNlIGFzIGxpa2VseSB0byBvY2N1ciBpbiBvdXIgYm91bmRhcnkK LSAgICAgICAgLy8gc3RyaW5ncyB0aGFuIGFueSBvdGhlciBjaGFyYWN0ZXIgYnV0IEkgdGhpbmsg dGhpcyBpcyBmaW5lIGZvciB0aGUgdGltZSBiZWluZy4KLSAgICAgICAgLy8gVGhlIEZJWE1FIGhl cmUgaXMgYWJvdXQgcmVzdG9yaW5nIHRoZSAvIGNoYXJhY3RlciBvbmNlIHRoZSBhZm9yZW1lbnRp b25lZAotICAgICAgICAvLyByYWRhciBoYXMgYmVlbiByZXNvbHZlZC4KKyAgICAgICAgMHgzNCwg MHgzNSwgMHgzNiwgMHgzNywgMHgzOCwgMHgzOSwgMHg0MSwgMHg0MgogICAgIH07CiAKICAgICAv LyBTdGFydCB3aXRoIGFuIGluZm9ybWF0aXZlIHByZWZpeC4K