Per https://gitlab.com/gitlab-org/gitlab-workhorse/issues/197#note_130790885 Currently, there is an ambiguity with a request that looks like: ``` PUT https://gitlab.com/group/subgroup/tree/master/project.git/gitlab-lfs/objects/aaaaaaa/10 ``` This is because the request may come from *either* an LFS client trying to create a new file, *or* (with a bit of trickery) the web UI, asking to update the file `project.git/gitlab-lfs/objects/aaaaaaa/10` in a project called "tree". To resolve this ambiguity, we select on content-type, but it would be better to move one of the two functions to an URL with no possibility of ambiguity. One option is to move the LFS API to `/api/lfs/<project-spec>/objects/:sha/:id`. I like this one a lot :D. It could go to `/<group>/<project>/-/gitlab-lfs/objects/:sha/:id` instead, if we prefer that, but it's a lot harder to validate in workhorse, haproxy, etc, since we have to ensure that the `/-/` component is the *first* in the URL, while the rest must be the URL termination. Another option is to move the web edit UI, and all its functionality, to be behind a `/-/` prefix in the same way. I like this much less, since it seems like a bigger breaking change - those URLs are scattered throughout our own issues as references, for instance. cc @DouweM