On Di, 2011-06-21 at 14:51 +0300, Salvatore Iovene wrote:
commit cdeddefc56797e46ec087a980a72f5670e6df882
Author: Salvatore Iovene <salvatore.iovene(a)linux.intel.com>
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.
This should go into the summary line, like this
WebDAV: hijack error 404 to 401 when appropriate (BMC #17862).
This documents that the commit fixes that problem.
commit 8c55193d34400a2e94089d9fa2e750866c491515
Author: Salvatore Iovene <salvatore.iovene(a)linux.intel.com>
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".
commit b700c67b0c8500d673a2e3fa08445a4bc60f7996
Author: Salvatore Iovene <salvatore.iovene(a)linux.intel.com>
NeonCXX: rename check to checkError.
Using a name that gives better context.
Ack. I would merge except that gitorious seems to be down.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.