We were thinking about having a separate service discovery document, which will list all of the service endpoints from a particular server, e.g. feed url, push url, symbol url, etc. I prefer that to stuffing these information in
every response, which not only increases the response payload but are also redundant in most of the times.
I'd like to dig up this thread as the "URL duality" seems to still be causing inconveniences for everyone. What happened to the idea of the service discovery document? I must say we like it very much, and here's why.
There are actually not 2 but 3 different URLs here:
- feed URL
- push URL
- symbol push URL
Currently symbolsource.org is hardcoded for nuget.org in nuget.exe, but this is suboptimal:
- doesn't allow us to change the symbol URL
- doesn't handle MyGet or other package repositories at all
But there is another issue that affects MyGet or anyone who wishes to secure the publish URL with HTTP Basic:
- nuget.exe makes an additional GET request before a GET on the feed or a PUT (to resolve redirects I suppose)
- if we authenticate that first request then we cannot have open-read access
- if we do not authenticate it then nuget.exe will not prompt for a password for PUT but just fail (perhaps this is a bug on its own)
- this makes it impossible to implement a "open-read, closed-write" policy for a feed with only one URL, as the server cannot autodetect if the client is going to access the feed or push a package
MyGet solves this with 2 separate URLs, but this is really counter intuitive.
I may vote on anything, the service discovery document would be ideal: the client would try getting it, resolve any redirects that may occur, find out all the URLs it needs (this would also make implementing endpoints easier, with the added flexibility)
and issue a second request to the chosen URL.
The result would be one URL to rule them all :)