Re: [SyncEvolution] [PATCHES] hijack error 404 to 401 when appropriate (2nd take)

On Di, 2011-06-21 at 14:51 +0300, Salvatore Iovene wrote: > commit cdeddefc56797e46ec087a980a72f5670e6df882 > Author: Salvatore Iovene <salvatore.iovene(a)linux.intel.com&gt; > > 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.

> commit 8c55193d34400a2e94089d9fa2e750866c491515 > Author: Salvatore Iovene <salvatore.iovene(a)linux.intel.com&gt; > > 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".