On Tue, 2009-12-22, Kannan wrote:
> Julian Foad wrote:
> [..]
> >> No, it should create a canonical URL. The fix we need is inside
> >> svn_ra_neon__request_get_location(), or at least we need to look inside
> >> that function to see where the non-canonical URL is coming from, and
> >> maybe trace further back to find the cause of the problem.
> >
> > Oops, typo. Meant to ask for canonical. I'll give a shot to try where
> > the non-canonicalized is possibly created in ..get_location().
>
> `svn_ra_neon__request_get_location()' returns the non-canonical URL
> which is obtained from the `ne_get_response_header()'(third party
> function).
Great.
Did you look to see if there are any other similar calls in Subversion
where we make the same mistake?
> Attaching the updated patch to canonicalize the URLs.
>
> [[[
> Log:
> Ensure the URLs are canonical before passing to the new
> `svn_path_url_add_component2()'.
>
> [ in subversion/libsvn_ra_neon ]
>
> * util.c
> (svn_ra_neon__request_get_location): Canonicalize the 'BASE URL' as
> `svn_path_url_add_component2()' won't handle it.
>
> * props.c
> (svn_ra_neon__get_baseline_info, svn_ra_neon__get_one_prop): Same.
Now let's move on to these places. Can you trace these back further?
> * options.c
> (svn_ra_neon__exchange_capabilities): Same.
And this?
By the way, in the log message, the reason for this change is no longer
specifically to do with svn_path_url_add_component2(), but rather to fix
violations of our "URLs are canonical" rule.
- Julian
Received on 2009-12-22 15:15:46 CET