Hi Patrick,

On Tue, 21 Jun 2011 16:39:40 +0200
Patrick Ohly <[email protected]> wrote:

> On Di, 2011-06-21 at 14:51 +0300, Salvatore Iovene wrote:
> > commit cdeddefc56797e46ec087a980a72f5670e6df882
> > Author: Salvatore Iovene <[email protected]>
> > 
> >     WebDavSource.cpp: hijack error 404 to 401 when appropriate.
> >     
> >     If we get a 404 error while contacting the server, it might mean
> >     that the username was wrong, so the server gave us a not found
> >     error. It's better to let the user know that, because we don't
> >     have a clear heuristic to determin whether this might have been
> >     a true 404 error.
> >     
> >     The convertion of 404 errors to 401 should happen only if the
> > URL we're trying to open is one in which it was us who injected the
> >     username into the URL. This was achieved by removing the
> > username injection from the context creation code, and moving it
> > into the loop that does the autodiscovery, adding it path by path
> > as it was necessary.
> >     Notice: this required NeonCXX to be aware of the "%u" semantic,
> >     something I'm not completely comfortable with.
> 
> I agree that this is awkward. I also noticed that %u now only works if
> used as one of the path components (http://foo/%u/bar) but not when
> inside a word (http://foo-%u-bar). The latter case is not needed at
> the moment, but it was part of the original idea.
> 
> Let's leave it as it is for now.

OK, I'll create a bug to remind us about this.

> > commit 8c55193d34400a2e94089d9fa2e750866c491515
> > Author: Salvatore Iovene <[email protected]>
> > 
> >     NeonCXX: don't trust libneon's escape and unescape functions.
> 
> Do you have reason to not trust libneon here? We rely on the "Neon
> does not return NULL" semantic in various places. However, I must
> admit that I don't know whether it applies here. NULL might indicate
> something other than out-of-memory here, like "bad input".

I have had unescape return NULL for "%u" more than once. I thought that
if the unescaping (or escaping) should fail, it's better to return the
original string, because, well, it couldn't indeed be (un)escaped.
 

-- 
Salvatore Iovene <[email protected]>
Linux Software Engineer
Intel Open Source Technology Center, Finland
Tel.: +358504804026
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to