You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The nuget.org web site uses HSTS, which presumes that only HTTPS should be used for visiting it, but it does not force HTTPS on the first visit. So if some browser was never used to access nuget.org, then first visit to http://nuget.org will not redirect to https://nuget.org. User would be able to download packages over plain HTTP which is not safe. Only authentication page currently forces HTTPS (and once you get there, you'd be unable to use HTTP again due to HSTS header, so no reason not to redirect to HTTPS for any HTTP request)
The text was updated successfully, but these errors were encountered:
Some statistics:
We are getting 2-2.5 million requests over HTTP per day (not HTTPS). Almost all of them are GET requests and will be properly redirected. Also, there are ~5K HEAD requests that also would be properly redirected.
We are getting about 10K POST requests per day, most of the are $batch OData requests from a single IP address that result in HTTP 301, because they are made to nuget.org (and get redirected to www.nuget.org), seems to be not properly processed by whoever sends them. We also get about 20-25 legit POST requests (that result in 2xx response). These would start to produce errors, so clients would have to switch to HTTPS.
We also get the DELETE, OPTIONS, PROPFIND, PUT and TRACE requests, usually less than 10 per day. Most of them either result in 404, or produce the same response as GET, so we can ignore them.
The nuget.org web site uses HSTS, which presumes that only HTTPS should be used for visiting it, but it does not force HTTPS on the first visit. So if some browser was never used to access nuget.org, then first visit to http://nuget.org will not redirect to https://nuget.org. User would be able to download packages over plain HTTP which is not safe. Only authentication page currently forces HTTPS (and once you get there, you'd be unable to use HTTP again due to HSTS header, so no reason not to redirect to HTTPS for any HTTP request)
The text was updated successfully, but these errors were encountered: