When I run a "nuget push" command from the command line, the upload fails and nuget dies with the following error:
System.Net.Http.HttpRequestException: Response status code does not indicate success: 417 (Expectation Failed).
Nuget's documentation doesn't give any indication what this could mean.
What's the issue here?
This blog post suggests it's an issue with an intermediate proxy server interfering with the PUT request that nuget.exe is attempting.
Http status 417 is caused when your proxy server does not support 100-continue. As a result, the client request does not get a response from the server indicating the client should POST data.
Check your system proxy settings and verify that either the proxy being used supports 100-continue, or that the proxy is bypassed for the servers Nuget is connecting to.
Nuget itself can be configured with proxy settings that will override the system settings. See the Nuget configuration documentation, specifically regarding proxies.
Related
I've spent quite a few hours fighting with these issues so I though a quick recap might be helpful for somebody else too.
First, when trying to import an RP from a metadata URL:
I was getting this error:
An error occured during an attempt to read the federation metadata. Verify that the specified URL or hostname is a valid federation metadata endpoint.
...
Error message: The underlying connection was closed: An unexpected error occured on a send.
The problem turned out to be caused by the fact that Windows Server at least up to 2016 is using TLS 1.0 for .NET framework (in which the ADFS configuration wizard is implemented) while my service hosting the metadata document only allowed TLS 1.2 as the minimum version:
Dropping the minimum version to TLS 1.0 is a no-go from security point of view, so the proper fix would be to enable TLS 1.2 as the default version on the ADFS server.
That would solve the issue (which I confirmed with a test) but then some of the other RPs only supporting TLS 1.0 would stop working, so I had to give up on importing metadata directly from a URL and use the file import option:
In this case another error popped up, which happened to be:
An error occured during an attempt to read the federation metadata. Verify that the specified URL or hostname is a valid federation metadata endpoint.
...
Error message: Entity descriptor '...'. ID6018: Digest verification failed for reference '...'.
This one turned out to be caused by me when I formatted the XML in the metadata file with line breaks and tabs to improve readability - it's all on a single line originally. ADFS won't allow that so the document must be exactly the same it came out of the metadata endpoint.
The same issue might result in different error messages and codes, depending on Windows and ADFS versions. For example this one is possible caused by a failed metadata integrity check as well:
An error occured during an attempt to read the federation metadata. Verify that the specified URL or hostname is a valid federation metadata endpoint.
...
Error message: Entity descriptor '...'. ID6013: The signature verification failed.
After having successfully imported a raw metadata file and having added a suitable Claim Issuance Policy I've got it finally working:
We have an api deployed on Azure that uses Google authentication. Over the weekend, the API started to throw 500 errors that were resolved after restarting the API. Is there a way to identify what the underlying cause for these errors might be?
Check if you have custom error mode in web.config file to “on” or “Remoteonly”. If
yes then turn it off. Add the following line to System.web element in web.config
Enable custom logging/instrumentation in the code which can help you in more
information.
ASP.NET applications can use the System.Diagnostics.Trace class to log information to
the application diagnostics log. For example
System.Diagnostics.Trace.TraceError("If you're seeing this, something bad happened");
Enable Detailed Error Messages - Detailed version of the html files produced when
your website responds with an error message. This is good to enable for debugging
some error responses in your website. It is stored in the website's file system.
Web Server Logging - Also known as HTTP logs or IIS logs, this will log all requests
to your website in W3C Extended Log File Format.
Failed Request Tracing - Also known as FREB, here you can get lots of information
from IIS through its different stacks for each failing request.
I've been using subversive pluguin quite a while and I didn't have a problem, but today I changed to a cellular network on windows 10 and I started getting this error while trying to commit :
Can't create session
svn: Commit failed (details follow):
svn: Unable to connect to a repository at URL 'http://XXXXXX'
RA layer request failed
svn: Unexpected HTTP status 400 'Bad Request' on 'http://XXXXX'
I found that I need to add a proxy details in the file servers of subversive but I don't know what to add since it's a cellular network.
Maybe your ISP manipulates HTTP requests.
If possible, switch the SVN protocol/URL from http://... to https://... or svn://...?
The Subversion client can go through a proxy, if you configure it to do so. First, edit your "servers" configuration file to indicate which proxy to use. The files location depends on your operating system. On Linux or Unix it is located in the directory "~/.subversion". On Windows it is in "%APPDATA%\Subversion". (Try "echo %APPDATA%", note this is a hidden directory.)
uncomment the following line:
#http-proxy-host=proxy.ip
#http-proxy-port=portnumber
#http-proxy-username=[username]
#http-proxy-password=[password]
Server: Windows Server 2012
Cold Fusion: 9,0,1,274733
Update-Level: hf901-00011.jar
Running on java version: 1.7.0_79
Java home points to the right path.
All certificates (for live and sandbox) are imported into the keystore of this JDK 1.7.0_79. I've tested it and renaming the cacerts file results in an error when connecting to the live API.
Testing the cacerts file using the keytool shows that the apropriate certificates are properly imported.
A little order app provides payment using PayPal.
First step is a connection to PayPal using the method "setExpressCheckout".
The connection to the live API using NVP at URL https://api-3t.paypal.com/nvp works and delivers the token URL-string.
The connection to the sandbox API using NVP at URL https://api-3t.sandbox.paypal.com/nvp fails with the error response:
I/O Exception: peer not authenticated
Connection Failure
Unable to determine MIME type of file.
Connection Failure. Status code unavailable.
Calling the URL https://api-3t.sandbox.paypal.com/nvp from the server works.
Test 1
imported the sandbox certificate for api-3t.sandbox.paypal.com
restart CF service
connection test failed with the same error
Test 2
renamed the cacerts file to cacerts.bak
copied the cacerts file from jre1.8.0_31\lib\security to the 1.7.0_79\lib\security
there is no specific PayPal cert in the cacerts file
restart the CF service
connection to live API works
connection to sandbox api fails with the same error
The weird thing is that the connection to the live api works without importing the specific certificate into the keystore when using the 1.8xx cacerts file.
I can't figure out why the connection to the sandbox fails. Maybe I can get new hints here?
If there are more informations needed please let me know. Thank you in advance.
Problem solved!
Scott Jibben (see his comment above) mentioned that the PayPal sandbox may already decline TLS1 connections in order to the upcoming change to do so in the PayPal live API.
This is absolutely right. But while in CF11 this isn't a problem because CF11 and its JRE are already using TLSv1.2, CF8-10 are using the default protocol of their JRE.
If not, one can force CF to use TLSv1.2 with the JVM argument
-Dhttps.protocols=TLSv1.2
Short:
CF8-10 are using TLSv1 while running with JDK1.70_79 and below no matter what the JVM startup argument -Dhttps.protocols was set to.
This is because the default protocol of these Java versions is TLSv1 and CF8-10 are simply ignoring the JVM startup argument -Dhttps.protocols and always use the JDK's default protocol.
This has changed with CF11 therefore it works fine with it.
Read detailed informations in a post from Wil Genovese at:
https://www.trunkful.com/index.cfm/2014/12/8/Preventing-SSLv3-Fallback-in-ColdFusion
What I did
I've installed the JDK1.8.0_144 and set up Cold Fusion 9 to use this one. Since then the connection to the PayPal sandbox API at api-3t.sandbox.paypal.com works pretty well.
Hope this may help others with this old and by now a little odd CF9.
Recently I was forced to switch from SVN to TFS.
I'm trying to get this working with TEE on our RedHat box.
Any action seems to end with something like this:
user#rh: tf -map $/XX/XX . -workspace:app-job -server:http://tfs.domain.com:8080/tfs/TFS2008/ -profile:TFS1_PRF_C
Password:
An error occurred: Proxy URL 'incache.domain.com:8080' does not contain a valid hostname.
Could someone help with that?
Your question is a little vague about what you expect to happen here (are you supposed to be using an HTTP proxy to access your TFS server? Or is the problem that it's assuming your HTTP proxy?)
I'm going to assume that you do not need to use an HTTP proxy to access your internal TFS server, since in most corporate environments your proxy is used to get outside the network, not inside. By default, the Team Explorer Everywhere CLC does try to use your system HTTP proxy, however this is configurable in your connection profile.
In order to override your default system HTTP proxy for that profile, you can set the profile property httpProxyIgnoreGlobal to true:
tf profile -edit -boolean:httpProxyIgnoreGlobal=true TFS1_PRF_C