Related to http://nuget.codeplex.com/workitem/1712?FocusElement=CommentTextBox, I would like to propose a design for this. The idea would be simple: I'ld like to add some additional headers to a NuGet feed.

Base idea is that EVERY request made to a NuGet server receives a response containing some headers on which the client can base its logic. Some proposed headers:

X-NuGet-Api-V1=http://push.here.com/
X-NuGet-Api-V2=http://push.here.com/api/v2/package
X-NuGet-Api-V1-SymbolSource=http://symbolsource.org
X-NuGet-Api-V2-SymbolSource=http://symbolsource.org
X-NuGet-Description=Official NuGet Package Source (<-- could be used to "discover" feed description inside VS2010 so only a URL is required)

And let's go crazy :-) Why not force users of a specific feed to enable package restore?
X-NuGet-PackageRestoreEnabled=True

Or limit supported client versions:
X-NuGet-SupportedClients=[1.5)

Comments?

I like the general idea. It's true that currently there is too much of a gap between the feed and the API.

+1!

Maybe rename the symbols header to a more generic X-NuGet-SymbolServer ?

X-NuGet-SymbolServer=http://symbolsource.org

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.

That would even be beter :-)

Would it not be an option to place the links in the nuget configuration file. This would make changes only on the client side necessary.

dotnetjunky wrote:

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 :)

YES!