From tobias-jamin at gmx.de Thu Sep 2 08:39:37 2010 From: tobias-jamin at gmx.de (Tobias Jamin) Date: Thu, 02 Sep 2010 14:39:37 +0200 Subject: Problems with TLS/SNI Message-ID: <20100902123937.76320@gmx.net> Hi folks, I cannot connect via Tortoise SVN (a subversion client) to my SVN repository via TLS/SNI. I have described the problem in the Tortoise SVN forum some month ago: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2616730 Stefan K?ng the main developer of Tortoise SVN told me that the problem seems to be up to the neon library. My SVN/webdav server is an apache installation with mod_ssl and SNI enabled: Server version: Apache/2.2.15 (Win32) Server built: Mar 4 2010 11:27:46 mod_ssl: 2.2.15.0 If I try to connect to my server with Tortoise SVN (so with neon) I got an ERROR 403 and the apache logs contains the following line: "No hostname was provided via SNI for a name based virtual host" If I use firefox to connect to my server everything works fine. Can somebody of the neon developer check this issue? I have just configured a test installation. You can use the following URL: https://neondemo.bytebrauerei.de/ (sorry for the invalid certificate). Thanks in advance. Greetings from rainy Germany, Tobias Jamin -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 f?r nur 19,99 €/mtl.!* http://portal.gmx.net/de/go/dsl From henrik at witsbits.com Mon Sep 6 04:02:28 2010 From: henrik at witsbits.com (Henrik Holst) Date: Mon, 06 Sep 2010 10:02:28 +0200 Subject: Problems with TLS/SNI In-Reply-To: <20100902123937.76320@gmx.net> References: <20100902123937.76320@gmx.net> Message-ID: <1283760148.1679.7.camel@henrik-desktop> Hi, looks like the problem is that neon prior to r1794 needed to be told to use SNI something that Tortoise probably didn't, on r1794 SNI was changed to be turned on by default. It looks like Tortoise links neon statically so you will have to download the latest neon from the svn repository and compile Tortoise by hand to test out if it works, or perhaps someone else on this list van try it out (I don't run WIN32 anymore). /Henrik Holst tor 2010-09-02 klockan 14:39 +0200 skrev Tobias Jamin: > Hi folks, > > I cannot connect via Tortoise SVN (a subversion client) to my SVN repository via TLS/SNI. I have described the problem in the Tortoise SVN forum some month ago: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2616730 > Stefan K?ng the main developer of Tortoise SVN told me that the problem seems to be up to the neon library. > > My SVN/webdav server is an apache installation with mod_ssl and SNI enabled: > > Server version: Apache/2.2.15 (Win32) > Server built: Mar 4 2010 11:27:46 > mod_ssl: 2.2.15.0 > > If I try to connect to my server with Tortoise SVN (so with neon) I got an ERROR 403 and the apache logs contains the following line: > > "No hostname was provided via SNI for a name based virtual host" > > If I use firefox to connect to my server everything works fine. > > Can somebody of the neon developer check this issue? I have just configured a test installation. You can use the following URL: https://neondemo.bytebrauerei.de/ (sorry for the invalid certificate). > > Thanks in advance. > > Greetings from rainy Germany, > > Tobias Jamin From ranjithvenkatesh at hotmail.com Wed Sep 15 11:46:16 2010 From: ranjithvenkatesh at hotmail.com (Ranjith Venkatesh) Date: Wed, 15 Sep 2010 17:46:16 +0200 Subject: Linking issues | session creation and destroying Message-ID: My development environment: Visual Studio 2008 Win XP SP3 My application type: Win 32 Console Application I have already included ne_session.h in stdafx.h I have linking errors. What am I missing here? Code: #include "stdafx.h" int _tmain(int argc, _TCHAR* argv[]) { ne_session *sess; sess = ne_session_create("http", "localhost/webdav", 80); /* ... use sess ... */ ne_session_destroy(sess); return 0; } Errors: Error 1 error LNK2019: unresolved external symbol _ne_session_destroy referenced in function _wmain neonTester.obj neonTester Error 2 error LNK2019: unresolved external symbol _ne_session_create referenced in function _wmain neonTester.obj neonTester Error 3 fatal error LNK1120: 2 unresolved externals ...\neonTester\Debug\neonTester.exe neonTester Ranjith Venkatesh Website: www.ranjithvenkatesh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.manyfish.co.uk/pipermail/neon/attachments/20100915/a2083f35/attachment.html From henrik at witsbits.com Thu Sep 16 07:34:46 2010 From: henrik at witsbits.com (Henrik Holst) Date: Thu, 16 Sep 2010 13:34:46 +0200 Subject: Linking issues | session creation and destroying In-Reply-To: References: Message-ID: <1284636886.1692.2.camel@henrik-desktop> did you tell Visual Studio to link with libneon.lib ? /Henrik Holst ons 2010-09-15 klockan 17:46 +0200 skrev Ranjith Venkatesh: > My development environment: > Visual Studio 2008 > Win XP SP3 > > My application type: > Win 32 Console Application > > I have already included ne_session.h in stdafx.h > I have linking errors. What am I missing here? > > Code: > #include "stdafx.h" > > int _tmain(int argc, _TCHAR* argv[]) > > { > > ne_session *sess; > > sess = ne_session_create("http", "localhost/webdav", 80); > > /* ... use sess ... */ > > ne_session_destroy(sess); > > return 0; > > } > > > Errors: > Error 1 error LNK2019: unresolved external symbol _ne_session_destroy > referenced in function _wmain neonTester.obj neonTester > Error 2 error LNK2019: unresolved external symbol _ne_session_create > referenced in function _wmain neonTester.obj neonTester > Error 3 fatal error LNK1120: 2 unresolved externals ...\neonTester > \Debug\neonTester.exe neonTester > > Ranjith Venkatesh > Website: www.ranjithvenkatesh.com From ranjithvenkatesh at hotmail.com Thu Sep 16 09:56:14 2010 From: ranjithvenkatesh at hotmail.com (Ranjith Venkatesh) Date: Thu, 16 Sep 2010 15:56:14 +0200 Subject: Linking issues | session creation and destroying In-Reply-To: <1284636886.1692.2.camel@henrik-desktop> References: <1284636886.1692.2.camel@henrik-desktop> Message-ID: The only lib file in the sources is \neon-0.29.3\src\COPYING.LIB Is there a newer release or another download where the libneon.lib is available? Ranjith Venkatesh Website: www.ranjithvenkatesh.com -------------------------------------------------- From: "Henrik Holst" Sent: Thursday, September 16, 2010 1:34 PM To: "Ranjith Venkatesh" Cc: Subject: Re: Linking issues | session creation and destroying > did you tell Visual Studio to link with libneon.lib ? > > /Henrik Holst > > ons 2010-09-15 klockan 17:46 +0200 skrev Ranjith Venkatesh: >> My development environment: >> Visual Studio 2008 >> Win XP SP3 >> >> My application type: >> Win 32 Console Application >> >> I have already included ne_session.h in stdafx.h >> I have linking errors. What am I missing here? >> >> Code: >> #include "stdafx.h" >> >> int _tmain(int argc, _TCHAR* argv[]) >> >> { >> >> ne_session *sess; >> >> sess = ne_session_create("http", "localhost/webdav", 80); >> >> /* ... use sess ... */ >> >> ne_session_destroy(sess); >> >> return 0; >> >> } >> >> >> Errors: >> Error 1 error LNK2019: unresolved external symbol _ne_session_destroy >> referenced in function _wmain neonTester.obj neonTester >> Error 2 error LNK2019: unresolved external symbol _ne_session_create >> referenced in function _wmain neonTester.obj neonTester >> Error 3 fatal error LNK1120: 2 unresolved externals ...\neonTester >> \Debug\neonTester.exe neonTester >> >> Ranjith Venkatesh >> Website: www.ranjithvenkatesh.com > > > From Tegdeep.Kondal at radialpoint.com Thu Sep 16 10:34:44 2010 From: Tegdeep.Kondal at radialpoint.com (Tegdeep Kondal) Date: Thu, 16 Sep 2010 10:34:44 -0400 Subject: Linking issues | session creation and destroying In-Reply-To: References: <1284636886.1692.2.camel@henrik-desktop> Message-ID: You need to compile the neon project as a static library in order to generate the libneon.lib file. Have a look at the makefile: \trunk\neon.mak Once you have this, you can add the dependency to your project. - Tegdeep Kondal -----Original Message----- From: neon-bounces at lists.manyfish.co.uk [mailto:neon-bounces at lists.manyfish.co.uk] On Behalf Of Ranjith Venkatesh Sent: Thursday, September 16, 2010 9:56 AM To: Henrik Holst Cc: neon at lists.manyfish.co.uk Subject: Re: Linking issues | session creation and destroying The only lib file in the sources is \neon-0.29.3\src\COPYING.LIB Is there a newer release or another download where the libneon.lib is available? Ranjith Venkatesh Website: www.ranjithvenkatesh.com -------------------------------------------------- From: "Henrik Holst" Sent: Thursday, September 16, 2010 1:34 PM To: "Ranjith Venkatesh" Cc: Subject: Re: Linking issues | session creation and destroying > did you tell Visual Studio to link with libneon.lib ? > > /Henrik Holst > > ons 2010-09-15 klockan 17:46 +0200 skrev Ranjith Venkatesh: >> My development environment: >> Visual Studio 2008 >> Win XP SP3 >> >> My application type: >> Win 32 Console Application >> >> I have already included ne_session.h in stdafx.h >> I have linking errors. What am I missing here? >> >> Code: >> #include "stdafx.h" >> >> int _tmain(int argc, _TCHAR* argv[]) >> >> { >> >> ne_session *sess; >> >> sess = ne_session_create("http", "localhost/webdav", 80); >> >> /* ... use sess ... */ >> >> ne_session_destroy(sess); >> >> return 0; >> >> } >> >> >> Errors: >> Error 1 error LNK2019: unresolved external symbol _ne_session_destroy >> referenced in function _wmain neonTester.obj neonTester >> Error 2 error LNK2019: unresolved external symbol _ne_session_create >> referenced in function _wmain neonTester.obj neonTester >> Error 3 fatal error LNK1120: 2 unresolved externals ...\neonTester >> \Debug\neonTester.exe neonTester >> >> Ranjith Venkatesh >> Website: www.ranjithvenkatesh.com > > > *********************************************************************** This e-mail and attachments are confidential, legally privileged, may be subject to copyright and sent solely for the attention of the addressee(s). Any unauthorized use or disclosure is prohibited. Statements and opinions expressed in this e-mail may not represent those of Radialpoint. Le contenu du prsent courriel est confidentiel, privilgi et peut tre soumis des droits d'auteur. Il est envoy l'intention exclusive de son ou de ses destinataires. Il est interdit de l'utiliser ou de le divulguer sans autorisation. Les opinions exprimes dans le prsent courriel peuvent diverger de celles de Radialpoint. *********************************************************************** This e-mail and attachments are confidential, legally privileged, may be subject to copyright and sent solely for the attention of the addressee(s). Any unauthorized use or disclosure is prohibited. Statements and opinions expressed in this e-mail may not represent those of Radialpoint. Le contenu du pr?sent courriel est confidentiel, privil?gi? et peut ?tre soumis ? des droits d'auteur. Il est envoy? ? l'intention exclusive de son ou de ses destinataires. Il est interdit de l'utiliser ou de le divulguer sans autorisation. Les opinions exprim?es dans le pr?sent courriel peuvent diverger de celles de Radialpoint. From bert at qqmail.nl Tue Sep 21 09:46:24 2010 From: bert at qqmail.nl (Bert Huijben) Date: Tue, 21 Sep 2010 15:46:24 +0200 Subject: Cancelling network operations In-Reply-To: <022801cae2db$f4c1d7a0$de4586e0$@qqmail.nl> References: <20100422133754.GC26035@manyfish.co.uk> <016f01cae227$5f0697f0$1d13c7d0$@qqmail.nl> <4BD07269.7020402@gmail.com> <20100422161702.GA23380@manyfish.co.uk> <018b01cae239$868cd430$93a67c90$@qqmail.nl> <20100422173356.GA25451@manyfish.co.uk> <4BD09A06.5060502@gmail.com> <019301cae2b6$0d0e0bb0$272a2310$@qqmail.nl> <20100423084310.GA2539@manyfish.co.uk> <022001cae2d2$fab89210$f029b630$@qqmail.nl> <20100423114019.GA7164@manyfish.co.uk> <022801cae2db$f4c1d7a0$de4586e0$@qqmail.nl> Message-ID: <004101cb5993$61cb2940$25617bc0$@nl> > -----Original Message----- > From: Bert Huijben [mailto:bert at qqmail.nl] > Sent: vrijdag 23 april 2010 13:56 > To: 'Joe Orton'; neon at lists.manyfish.co.uk > Subject: RE: Cancelling network operations > > > > > -----Original Message----- > > From: neon-bounces at lists.manyfish.co.uk [mailto:neon- > > bounces at lists.manyfish.co.uk] On Behalf Of Joe Orton > > Sent: vrijdag 23 april 2010 13:40 > > To: neon at lists.manyfish.co.uk > > Subject: Re: Cancelling network operations > > > > On Fri, Apr 23, 2010 at 12:51:50PM +0200, Bert Huijben wrote: > > > Yes, it would certainly be nicer if the code does it more often, > but I > > > don't want this '*really* nice to have' feature to have a > measurable > > > impact on future neon versions. And as subversion handles cancel > > > checks when processing the data, it has most to gain by allowing > > > canceling in the cases where it doesn't have control of. > > > > Having thought about this more, I think a reasonable compromise is: > > > > a) invoke the cancellation callback each time before blocking in > poll/select > > And then of course also limiting the block time on poll/select and > retrying, or we (the Gui users) don't get in the cancel function for > about an hour. (Default timeout as set by Subversion) > > > b) also invoke the cancellation callback any time recv/send fail with > > EINTR > > > > I don't think there'll be a performance impact from this and Unix > > command-line users will still be able to rely on the immediate > > cancellation effect. > > Thanks!! > > Bert Pinging this old thread from last April. If we can get this fixed before branching Subversion 1.7, that would be really nice. Bert From joe at manyfish.co.uk Wed Sep 22 16:08:09 2010 From: joe at manyfish.co.uk (Joe Orton) Date: Wed, 22 Sep 2010 21:08:09 +0100 Subject: Problems with TLS/SNI In-Reply-To: <20100902123937.76320@gmx.net> References: <20100902123937.76320@gmx.net> Message-ID: <20100922200809.GA2192@manyfish.co.uk> On Thu, Sep 02, 2010 at 02:39:37PM +0200, Tobias Jamin wrote: > I cannot connect via Tortoise SVN (a subversion client) to my SVN > repository via TLS/SNI. I have described the problem in the Tortoise > SVN forum some month ago: > http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2616730 > Stefan K?ng the main developer of Tortoise SVN told me that the > problem seems to be up to the neon library. Hi, this is caused by a bug in neon's SNI support in 0.29.x which will be fixed in 0.29.4. Regards, Joe From joe at manyfish.co.uk Wed Sep 22 16:18:22 2010 From: joe at manyfish.co.uk (Joe Orton) Date: Wed, 22 Sep 2010 21:18:22 +0100 Subject: kerberos authentication with neon 0.29.3 In-Reply-To: References: Message-ID: <20100922201822.GB2192@manyfish.co.uk> Hi folks - I'm sorry that I've been so slow to deal with this :( I have committed the patch neon-clear-sspi-context-2.patch to the trunk and 0.29.x branch, given Danil's recommendation to go this route. 1) Can someone verify that the 0.29.x branch is OK w.r.t. the outstanding SSPI/Kerberos fixes? 2) Should I credit the patch to Danil alone? I will follow up separately to the specific outstanding question posed. Thanks to all who have put effort into this fixing these issues and testing those fixes; apologies again for not keeping up my end. Regards, Joe From joe at manyfish.co.uk Wed Sep 22 16:37:51 2010 From: joe at manyfish.co.uk (Joe Orton) Date: Wed, 22 Sep 2010 21:37:51 +0100 Subject: Procucts equipped with the current release neon In-Reply-To: <3FCC9346B49C5341A2F440B4C3B2E92AE885ED7E3E@EXMAIL02.jp.ykgw.net> References: <3FCC9346B49C5341A2F440B4C3B2E92AE885ED7E3E@EXMAIL02.jp.ykgw.net> Message-ID: <20100922203751.GC2192@manyfish.co.uk> Hi, sorry for the slow response. On Thu, Jul 08, 2010 at 04:09:26PM +0900, Takeshi.Oono at jp.yokogawa.com wrote: > We're planning to develop our products, embedded Linux machines, equipped with the neon. > So could you give us your advice if there is anything we should consider in dealing with the neon? > Concretely speaking, which neon should we use, the current release, or the 1.0.0 release in the near future? The current release, or 0.29.4 which should be out shortly. > We assume that the 1.0.0 release means the completed versions achieved the first goal. > If possible, we'll start to produce our products with the current release right now. > > * API specifications; > The downloaded README file says that "The neon API is subject to > backwards-incompatible change over minor releases (0.23.x -> 0.24.x) > until the 1.0.0 release" It's important for our products to maintain > backward compatibility. But I expect that it's highly unlikely that > the API of the current release is changed actually. Is that right? I don't anticipate any backwards-incompatible changes to the neon API. The 0.28.x and 0.29.x series have been backwards-compatible with the 0.27.x API despite the warning above. I expect to call neon 1.x without breaking the current API. > * Software quality; > The downloaded BUG file says several known problems/bugs in the neon. > But I recognize that they're not fatal bugs actually and the current release has high quality. > Is that right? Yes, none of these are particularly serious. Whether or not you consider the current release high quality is up to you :) > * Practical applications; > It's widely known that the Subversion makes use of the neon. Do you > know that the neon is used for other purposes, particularly for the > commercial use. I don't keep a list of such things, sorry. There are various free software projects which use neon as an HTTP (& WebDAV) client in some way; OpenOffice probably is the most widely known of these (AFAIK it still uses neon). > * Neon roadmap; > We want to know neon roadmap till the 1.0.0 release. > Will you launch the 1.0.0 release in the near future? No specific roadmap; as time permits. Regards, Joe From joe at manyfish.co.uk Wed Sep 22 21:05:15 2010 From: joe at manyfish.co.uk (Joe Orton) Date: Thu, 23 Sep 2010 02:05:15 +0100 Subject: profind method bug In-Reply-To: References: Message-ID: <20100923010515.GA30381@manyfish.co.uk> On Mon, Aug 02, 2010 at 05:48:08PM +0900, Jong Gyu Lee wrote: > Hi. > I'm Jong-Gyu Lee. > I think there is a bug in neon. > I cound not access http://box.net/dav with neon. > I found that after requesting a profind method the response according to it > is wrong. > So I modified neon library like the attached patch file. > Before making sure the attached patch file, you need to check HTTP > request/response message with WireShark. > I wish that this mail gives you a helping hand. Can you give an example of a PROPFIND request body which is malformed? The ne_propfind_* code uses a root element of: which means it is not necessary to declare and use the "D" namespace as your patch does (unless I'm missing a case where the default DAV: namespace is not declared with ne_propfind_*). Regards, Joe > --- src/ne_props.c (revision 1801) > +++ src/ne_props.c (working copy) > @@ -158,13 +158,12 @@ > int n; > > if (!hdl->has_props) { > - ne_buffer_czappend(body, "\n"); > + ne_buffer_czappend(body, "\n"); > hdl->has_props = 1; From j.veenvan at gmail.com Thu Sep 23 02:54:19 2010 From: j.veenvan at gmail.com (Jeroen van Veen) Date: Thu, 23 Sep 2010 08:54:19 +0200 Subject: LOCK request method bug In-Reply-To: References: Message-ID: <201009230854.19676.info@os-networks.net> Hi, I got some weird results with LOCK requests, using twisted as http server and wsgidav as webdav server. It turns out that the header sent by davfs2 doesnt include a proper empty-line. I think neon takes care of this(?), but was not able to find the code responsible for it. I filed a wsgidav bugreport at http://code.google.com/p/wsgidav/issues/detail?id=41 which is probably(?) more related to neon. I fixed it temporarily by monkey patching twisted's http channel, but they don't like to change this in core since 'it's not according to the http spec'. Any idea what may be wrong? kind regards, Jeroen On Monday 02 August 2010 10:48:08 Jong Gyu Lee wrote: > Hi. > I'm Jong-Gyu Lee. > I think there is a bug in neon. > I cound not access http://box.net/dav with neon. > I found that after requesting a profind method the response according to it > is wrong. > So I modified neon library like the attached patch file. > Before making sure the attached patch file, you need to check HTTP > request/response message with WireShark. > I wish that this mail gives you a helping hand. From walter.klust at elego.de Thu Sep 23 02:51:17 2010 From: walter.klust at elego.de (Walter Klust) Date: Thu, 23 Sep 2010 08:51:17 +0200 Subject: 0.29.4 release date ? Message-ID: <4C9AF8E5.6020603@elego.de> Hello, I would like to know when version 0.29.4 will be released. The reason I ask: There is currently a bug in 0.29.3 which is assumed to be fixed with 0.29.4 and which has repercussions to a problem in subversion with the SNI being broken. Since a new version of subversion will be released soon it would be nice if we could have a neon 0.29.4 at that time. kind regards Walter -- Walter Klust, Director Support/Senior Consultant elego Software Solutions GmbH, http://www.elego.de Gustav-Meyer-Allee 25, Building 12 - BIG, 13355 Berlin, Germany fon +49 30 2345 8696, fax +49 30 2345 8695 support +49 30 322 971 300 CEO Olaf Wagner; Office Berlin; District Court Berlin-Charlottenburg HRB 77719 From joe at manyfish.co.uk Thu Sep 23 04:03:35 2010 From: joe at manyfish.co.uk (Joe Orton) Date: Thu, 23 Sep 2010 09:03:35 +0100 Subject: LOCK request method bug In-Reply-To: <201009230854.19676.info@os-networks.net> References: <201009230854.19676.info@os-networks.net> Message-ID: <20100923080335.GA31582@manyfish.co.uk> On Thu, Sep 23, 2010 at 08:54:19AM +0200, Jeroen van Veen wrote: > Hi, > > I got some weird results with LOCK requests, using twisted as http server and > wsgidav as webdav server. It turns out that the header sent by davfs2 doesnt > include a proper empty-line. I think neon takes care of this(?), but was not > able to find the code responsible for it. I filed a wsgidav bugreport at > http://code.google.com/p/wsgidav/issues/detail?id=41 which is probably(?) more > related to neon. I fixed it temporarily by monkey patching twisted's http > channel, but they don't like to change this in core since 'it's not according > to the http spec'. Any idea what may be wrong? Which header is being sent without being properly terminated? It's not clear from the details in that bug report. Regards, Joe From werner.baumann at onlinehome.de Thu Sep 23 15:26:42 2010 From: werner.baumann at onlinehome.de (Werner Baumann) Date: Thu, 23 Sep 2010 21:26:42 +0200 Subject: LOCK request method bug In-Reply-To: <201009230854.19676.info@os-networks.net> References: <201009230854.19676.info@os-networks.net> Message-ID: <20100923212642.427bd076@ginster.brambauer> Am Thu, 23 Sep 2010 08:54:19 +0200 schrieb Jeroen van Veen : > Hi, > > I got some weird results with LOCK requests, using twisted as http > server and wsgidav as webdav server. It turns out that the header > sent by davfs2 doesnt include a proper empty-line. I think neon takes > care of this(?), but was not able to find the code responsible for > it. I filed a wsgidav bugreport at > http://code.google.com/p/wsgidav/issues/detail?id=41 which is > probably(?) more related to neon. I fixed it temporarily by monkey > patching twisted's http channel, but they don't like to change this > in core since 'it's not according to the http spec'. Any idea what > may be wrong? > > kind regards, > > Jeroen Please have alook at http://lists.manyfish.co.uk/pipermail/neon/2010-August/001256.html It is prbably the same bug and it is a bug in davfs2. The bug is easy to patch but you might as well get the sources from CVS (http://cvs.savannah.gnu.org/viewvc/davfs2/?root=davfs2). Cheers Werner From Takeshi.Oono at jp.yokogawa.com Thu Sep 23 21:18:02 2010 From: Takeshi.Oono at jp.yokogawa.com (Takeshi.Oono at jp.yokogawa.com) Date: Fri, 24 Sep 2010 10:18:02 +0900 Subject: Procucts equipped with the current release neon In-Reply-To: <20100922203751.GC2192@manyfish.co.uk> References: <3FCC9346B49C5341A2F440B4C3B2E92AE885ED7E3E@EXMAIL02.jp.ykgw.net> <20100922203751.GC2192@manyfish.co.uk> Message-ID: <3FCC9346B49C5341A2F440B4C3B2E92AE88A704DFA@EXMAIL02.jp.ykgw.net> Hi Joe, We're going to accelerate our development project with neon, thank to your respectful reply during your busy schedule. I'll keep you informed of our progress. Regards, Takeshi --- -----Original Message----- From: Joe Orton [mailto:joe at manyfish.co.uk] Sent: Thursday, September 23, 2010 5:38 AM To: Oono, Takeshi (Takeshi.Oono at jp.yokogawa.com) Cc: neon at lists.manyfish.co.uk Subject: Re: Procucts equipped with the current release neon Hi, sorry for the slow response. On Thu, Jul 08, 2010 at 04:09:26PM +0900, Takeshi.Oono at jp.yokogawa.com wrote: > We're planning to develop our products, embedded Linux machines, equipped with the neon. > So could you give us your advice if there is anything we should consider in dealing with the neon? > Concretely speaking, which neon should we use, the current release, or the 1.0.0 release in the near future? The current release, or 0.29.4 which should be out shortly. > We assume that the 1.0.0 release means the completed versions achieved the first goal. > If possible, we'll start to produce our products with the current release right now. > > * API specifications; > The downloaded README file says that "The neon API is subject to > backwards-incompatible change over minor releases (0.23.x -> 0.24.x) > until the 1.0.0 release" It's important for our products to maintain > backward compatibility. But I expect that it's highly unlikely that > the API of the current release is changed actually. Is that right? I don't anticipate any backwards-incompatible changes to the neon API. The 0.28.x and 0.29.x series have been backwards-compatible with the 0.27.x API despite the warning above. I expect to call neon 1.x without breaking the current API. > * Software quality; > The downloaded BUG file says several known problems/bugs in the neon. > But I recognize that they're not fatal bugs actually and the current release has high quality. > Is that right? Yes, none of these are particularly serious. Whether or not you consider the current release high quality is up to you :) > * Practical applications; > It's widely known that the Subversion makes use of the neon. Do you > know that the neon is used for other purposes, particularly for the > commercial use. I don't keep a list of such things, sorry. There are various free software projects which use neon as an HTTP (& WebDAV) client in some way; OpenOffice probably is the most widely known of these (AFAIK it still uses neon). > * Neon roadmap; > We want to know neon roadmap till the 1.0.0 release. > Will you launch the 1.0.0 release in the near future? No specific roadmap; as time permits. Regards, Joe From henrik at witsbits.com Fri Sep 24 05:11:46 2010 From: henrik at witsbits.com (Henrik Holst) Date: Fri, 24 Sep 2010 11:11:46 +0200 Subject: profind method bug In-Reply-To: <20100923010515.GA30381@manyfish.co.uk> References: <20100923010515.GA30381@manyfish.co.uk> Message-ID: <1285319506.1716.7.camel@henrik-desktop> tor 2010-09-23 klockan 02:05 +0100 skrev Joe Orton: > On Mon, Aug 02, 2010 at 05:48:08PM +0900, Jong Gyu Lee wrote: > > Hi. > > I'm Jong-Gyu Lee. > > I think there is a bug in neon. > > I cound not access http://box.net/dav with neon. > > I found that after requesting a profind method the response according to it > > is wrong. > > So I modified neon library like the attached patch file. > > Before making sure the attached patch file, you need to check HTTP > > request/response message with WireShark. > > I wish that this mail gives you a helping hand. > > Can you give an example of a PROPFIND request body which is malformed? > The ne_propfind_* code uses a root element of: > > > > which means it is not necessary to declare and use the "D" namespace as > your patch does (unless I'm missing a case where the default DAV: > namespace is not declared with ne_propfind_*). I agree with Joe here, this seams like an error on the server side, i.e who ever wrote the server software at box.net didn't implement proper namespace handling in their XML codes and instead probably thought that the entities should be named "". This is a common misconception with custom webdav servers. D: does not stand for WebDAV, it's simple the most used form, one could as easily send data as: ... Which would be a proper request, but I assume that box.net would fail with that request as well. We use propfinds extensively with neon and have yet to see a malformed request. /Henrik Holst