Discovery from */api/ doesn't find */api/odata/

[rrelyea]

Working with a Klondike v2 server worked in v3.3 with http://servername/api/. It would use discovery and find http://servername/api/odata/.

v3.4 doesn't seem discovery properly as of now.

(this was a spin off issue from: https://github.com/NuGet/Home/issues/2054)

[rrelyea]

3.3 behavior:

Result Protocol Host URL Body Caching Content-Type Process Comments Custom

12469 307 HTTP localhost.:8080 /api 0 n33:18272
12476 200 HTTP localhost.:8080 /api/odata 368 application/atomsvc+xml; charset=utf-8 n33:18272
12515 200 HTTP localhost.:8080 /api/odata/$metadata 4,386 application/xml; charset=utf-8 n33:18272
12582 200 HTTP localhost.:8080 /api/odata/FindPackagesById()?id='mvvmlight' 77,161 application/atom+xml; charset=utf-8 n33:18272

3.4 current bits:

Result Protocol Host URL Body Caching Content-Type Process Comments Custom

7070 404 HTTP localhost.:8080 /api/FindPackagesById()?Id='mvvmlight' 0 nuget:18392

3.4 w/ DTD fix:

Result Protocol Host URL Body Caching Content-Type Process Comments Custom

8982 404 HTTP localhost.:8080 /api/FindPackagesById()?Id='mvvmlight' 0 fixed:19196

[johnataylor]

There are three distinct issues with the new client protocol implementation:

1) We were not putting an Accept header on the HTTP requests. nuget.org was forgiving and just worked, other servers won't necessarily, for example Klondike return json when our client was expecting XML. This is a very simple and localized fix.

2) The client search requests were sending the long form of the target-framework name to the server as part of the search request. nuget.org does little in the way of filtering on target-framework and in some case does none. However historically it did and other servers copied that. In this case it must be the short form of the target framework name. This is a very simple and localized fix.

3) The odata protocol workflow starts with referencing a Service Document that specifies a base address for subsequent calls. Often this base address is the same as the physical address. However, when it isn't our client fails. It is very reasonable that this might be different, for example, the Klondike server redirects this initial start document, and inside that result the base address is specified as the redirected address. Subsequent calls from the Klondike server are not redirected (why should they be?) but our client fails because it didn't read the base address from the Service Document. In fact it didn't read the Service Document at all.

Incidentally the new client code actually succeeds with nuget.org because all calls specified with http://nuget.org/api/v2 rather than http://www.nuget.org/api/v2 but only does so because it redirects every call made.

Current pull request #378 and this works and is tested with nuget.org V2 and the Klondike server however we are doing a little more factoring on part (3) if this bug this morning. This refactoring is to define a separate resource to hold the base address, this saves the Service Document XML from being re-parsed every call.

[rrelyea]

Need to confirm that this is fixed completely in 3.4.3. Parts were fixed in 3.4.2 and rest in 3.4.3, we believe.