[webkit-dev] Desperate for webkit help
Mark Pauley
mpauley at apple.com
Wed Apr 16 11:38:35 PDT 2008
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/7d20fb48/attachment-0001.html
More information about the webkit-dev
mailing list