Bug 18539 – multipart/form-data not being parsed correctly on server due to '+' in boundary string

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[mark]

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: [e-mail]
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

[David Kilzer (:ddkilzer)]

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).

[mark]

(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?

[David Kilzer (:ddkilzer)]

(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.

[mark]

(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.

[Jonas Munk]

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.
> 

[Alexey Proskuryakov]

Created attachment 42326 [details]
proposed fix

I don't see a reason not to limit the set of characters further.

[Alexey Proskuryakov]

Committed <http://trac.webkit.org/changeset/50421>.