Uploading packages as multiform content type

[Vidarls]

Tested against our ProGet feed, and it seems to fix #646

Implementation is rather crude, let me know if you see anything that needs to be polished.

[forki]

thanks

[Vidarls]

Removing the explicit /api/v2/package seems to be important in order to make it work for the proget feed.
I don't know how to test against nuget.

[forki]

we test nuget by dogfooding in paket. seems to work

[mavnn]

A pity, that should really be standard. Still, specifying it for nuget.org is a small price to pay for it working everywhere else...

[forki]

ok it doesn't work for nuget.org. - the build doesn't complain, but the package is not listed https://www.nuget.org/packages/Paket/

[mavnn]

@Vidarls did you list the proget server with a trailing '/'? @forki I wouldn't expect nuget.org to take it without the full url, I'm afraide

[forki]

@mavnn what hack do I have to commit to make it work? we already have special cases for the "download" part. I have no issues with special casing nuget.org

[mavnn]

If push url is nuget.org, add "/api/v2/package" to the end. Thing which makes me reluctant is that this should be the right endpoint for any server implementing the nuget rest interface.

[mavnn]

Also, we'll need to check why the push didn't fail when it didn't work.

[forki]

afd8e52 actually works.

summoning our special nuget hero @maartenba

[maartenba]

MyGet needs the api/v2/package if it's not there too :) It should be standard ideally.

[forki]

so only proget doesn't want it? sounds strange

[maartenba]

Convention rather than standard...

[Vidarls]

The reason for ProGet to be picky is that they have a weird way of creating their URLs:

The short form is http://host.domain/nuget/feedname
Which I believe will be redirected to: http://host.domain/api/v2/package/feedname

Force appending /api/v2/package to any of these valid url will fail, usually by a 400 invalid request

Now we could try to get ProGet to adhere to the conventions, but fact is that the nuget client have no problems with this. And as such, neither should Paket (following the principle of least surprise).

As far as I can see, Nuget will add /api/v2/package to a url if only the hostname is given:

(from http://nuget.codeplex.com/SourceControl/latest#src/Core/Server/PackageServer.cs)

private const string ServiceEndpoint = "/api/v2/package";

internal static Uri GetServiceEndpointUrl(Uri baseUrl, string path)
        {
            Uri requestUri;
            if (String.IsNullOrEmpty(baseUrl.AbsolutePath.TrimStart('/')))
            {
                // If there's no host portion specified, append the url to the client.
                requestUri = new Uri(baseUrl, ServiceEndpoint + '/' + path);
            }
            else
            {
                requestUri = new Uri(baseUrl, path);
            }
            return requestUri;
        }

And also the baseurl is redirect-expanded (is that even a word?):

private Uri ResolveBaseUrl()
        {
            Uri uri;

            try
            {
                var client = new RedirectedHttpClient(new Uri(Source));
                uri = client.Uri;
            }
            catch (WebException ex)
            {
                var response = (HttpWebResponse)ex.Response;
                if (response == null)
                {
                    throw;
                }

                uri = response.ResponseUri;
            }

            return EnsureTrailingSlash(uri);
        }

I don't have time to keep shaving this particular yak, but this should be a good starting point should someone feel the urge..

[mavnn]

I'll add api end point as an optional parameter later today (defaulting to the nuget convention). I'd rather not have too much "magic", but nuget.org should also just work™. I think the optional override makes the best compromise between the two.

[mavnn]

At some point we should also look at following redirects, but that's a bigger yak than I have time to shave today!

[Vidarls]

My research yesterday indicated that WebClient will use webrequests where AllowAutoRedirect is set to true, so in general, redirects should not be an issue, except if we need the redirected URL to do something with it.
Note: I did not find any official msdn sources on this, but at least it seems to be the general consensus understanding that WebClient will follow redirects automatically by default

[mavnn]

@Vidarls that's good news.