Re: [webkit-dev] Desperate for webkit help

2008-06-25 Thread Mark
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.

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


Re: [webkit-dev] Desperate for webkit help

2008-06-25 Thread Steve Atkins

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

2008-04-16 Thread Mark Pauley
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

2008-04-16 Thread David Kilzer
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

2008-04-16 Thread Mark
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

2008-04-16 Thread David Kilzer
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

2008-04-16 Thread Maciej Stachowiak


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

2008-04-15 Thread David Kilzer
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

2008-04-15 Thread Mark
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

2008-04-15 Thread David Kilzer
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

2008-04-12 Thread David Kilzer
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

2008-04-12 Thread Mark
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

2008-04-11 Thread David Kilzer
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

2008-04-11 Thread Scott Thompson


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