Browsing in VS2015 doesn't work

[Sniper-SnX]

Hey everyone,

browsing the package repository via Visual Studio 2015 Update 1 and all currently available updates doesn't work. Don't know if vanilla VS2015 does work. Updating and installing packages works without problems.

I captured a request via Fiddler and the result looks like:

GET http://wnsvn01/api/odata/Search%28%29?=&$orderby=DownloadCount%20desc%2CId&searchTerm=%27%27&targetFramework=%27net461%27&includePrerelease=false&$skip=30 HTTP/1.1
MaxDataServiceVersion: 2.0;NetFx
User-Agent: NuGet Client V3/3.3.0.0 (Microsoft Windows NT 10.0.10586.0, VS Enterprise/14.0)
Accept: application/atom+xml,application/xml
Accept-Charset: UTF-8
Host: wnsvn01
Accept-Encoding: gzip, deflate

We host our Klondike with the SelfHost.exe

I think it may has something to do with the url encoded request which the self host exe couldn't handle properly.

Hope this helps for interrogation / fixing.

[lukeskinner]

I'm seeing the same problem using v2.0.0 of Klondike.

From what I can tell the issue lies in the $skip=30 that Klondike produces for the next link in the response.

Example Klondike next link:

  <link rel="next" href="http://localhost:8080/api/odata/Search%28%29?
=&amp;$orderby=DownloadCount%20desc%2CId&amp;searchTerm=
%27%27&amp;targetFramework=%27net461%27&amp;includePrerelease=false&amp;$skip=30" />

Example Nuget.org next link:

    <link rel="next" href="https://www.nuget.org/api/v2/Search()?
searchTerm=%27%27&amp;targetFramework=%27net461%27&amp;includePrerelease
=false&amp;$filter=IsLatestVersion&amp;$orderby=DownloadCount%20desc,Id&amp;$skip=100" />

$skip value differences in the next link:

	Klondike	NuGet.org
First response	$skip=30	$skip=100
Second response	$skip=30	$skip=200
Third response	$skip=30	$skip=300

I haven't looked into the code with enough detail yet to be able to provide a solution but it appears the '30' value comes from the NuGet.Lucene.Web.Controllers.PackagesODataController class.

private const int DefaultSearchPageSize = 30;

[chriseldredge]

Using Visual Studio 2015 Update 2, the Updates screen does seem to work for me, at least for the first page of results.

However, there does seem to be a bug in Klondike where the formatting of the next link is encoded incorrectly (as Search%28%29 instead of Search()).

As far as I can tell, this incorrect encoding happens in support libraries like System.Web.Http.OData or elsewhere. I'm working on tracking down where the property is serialized to the client.

[suddenelfilio]

same issue here.

[jstachowiak]

@chriseldredge, any update on this issue? I managed to reproduce the problem when Klondike successfully looked up a package in a remote package repository.

[jstachowiak]

I believe I tracked down where the property is serialized to the client: Formatter.Serialization.ODataFeedSerializer.cs in System.Web.Http.OData.

There is an interesting comment in the source code:

Subtle and suprising behavior: If the NextPageLink property is set before calling WriteStart(feed), the next page link will be written early in a manner not compatible with odata.streaming=true. Instead, if the next page link is not set when calling WriteStart(feed) but is instead set later on that feed object before calling WriteEnd(), the next page link will be written at the end, as required for odata.streaming=true support.

I also found that if you do not use OWIN to self-host vs. hosting in IIS, NextPageLink is serialized correctly. There is a bunch of formatters available to format the content which derive from Formatter.ODataMediaTypeFormatter and only one is selected for a given media type.

Hope this helps.

[jstachowiak]

There is an issue in Katana which Klondike uses as a host. The resource path delimiters "(" and ")" are encoded which violates RFC 3986. Please see section 3.3. This is the root cause for OData URL conventions not being handled correctly.

The problem is in the PathString:RequiresEscaping(string value). The list of characters that do not need to be escaped in the path does not include "(" and ")". The source code can be found here.

The specific formatter which supports 'application/json' media type uses ODataJsonLightSerializer to find the string representation of a URI. When WriteFeedNextLink is called the URI is taken from OwinRequest:Uri which, at this point, is incorrect.

[jstachowiak]

@chriseldredge, I submitted an issue 462 in Katana project.

[jstachowiak]

Seems like this will not be fixed by Microsoft. They expect users to migrate eventually to ASP.NET Core which in their opinion is the next version of Katana. Any thoughts?

[chriseldredge]

I think I have an ugly work-around for this from last time I was debugging it. I'll take a look.

[chriseldredge]

Work-around committed to NuGet.Lucene.Web and included in Klondike build 148.

Can someone give the build in https://ci.appveyor.com/project/chriseldredge/klondike/build/148/artifacts a whirl and let me know if it fixes the problem?

[jstachowiak]

odata.nextLink is now encoded correctly. Nice work-around with undoing the encoding in the action filter!

[chriseldredge]

Released in v2.2.1

https://github.com/themotleyfool/Klondike/releases/tag/v2.1.1