Удаленный сервер возвратил ошибку 417 expectation failed

This same situation and error can also arise with a default wizard generated SOAP Web Service proxy (not 100% if this is also the case on the WCF System.ServiceModel stack) when at runtime:

• the end user machine is configured (in the Internet Settings) to use a proxy that does not understand HTTP 1.1
• the client ends up sending something that a HTTP 1.0 proxy doesnt understand (commonly an Expect header as part of a HTTP POST or PUT request due to a standard protocol convention of sending the request in two parts as covered in the Remarks here)

… yielding a 417.

As covered in the other answers, if the specific issue you run into is that the Expect header is causing the problem, then that specific problem can be routed around by doing a relatively global switching off of the two-part PUT/POST transmission via System.Net.ServicePointManager.Expect100Continue.

However this does not fix the complete underlying problem — the stack may still be using HTTP 1.1 specific things such as KeepAlives etc. (though in many cases the other answers do cover the main cases.)

The actual problem is however that the autogenerated code assumes that it’s OK to go blindly using HTTP 1.1 facilities as everyone understands this. To stop this assumption for a specific Web Service proxy, one can change override the default underlying HttpWebRequest.ProtocolVersion from the default of 1.1 by creating a derived Proxy class which overrides protected override WebRequest GetWebRequest(Uri uri) as shown in this post:-

public class MyNotAssumingHttp11ProxiesAndServersProxy : MyWS
{
    protected override WebRequest GetWebRequest(Uri uri)
    {
      HttpWebRequest request = (HttpWebRequest)base.GetWebRequest(uri);
      request.ProtocolVersion = HttpVersion.Version10;
      return request;
    }
}

(where MyWS is the proxy the Add Web Reference wizard spat out at you.)

UPDATE: Here’s an impl I’m using in production:

class ProxyFriendlyXXXWs : BasicHttpBinding_IXXX
{
    public ProxyFriendlyXXXWs( Uri destination )
    {
        Url = destination.ToString();
        this.IfProxiedUrlAddProxyOverriddenWithDefaultCredentials();
    }

    // Make it squirm through proxies that don't understand (or are misconfigured) to only understand HTTP 1.0 without yielding HTTP 417s
    protected override WebRequest GetWebRequest( Uri uri )
    {
        var request = (HttpWebRequest)base.GetWebRequest( uri );
        request.ProtocolVersion = HttpVersion.Version10;
        return request;
    }
}

static class SoapHttpClientProtocolRealWorldProxyTraversalExtensions
{
    // OOTB, .NET 1-4 do not submit credentials to proxies.
    // This avoids having to document how to 'just override a setting on your default proxy in your app.config' (or machine.config!)
    public static void IfProxiedUrlAddProxyOverriddenWithDefaultCredentials( this SoapHttpClientProtocol that )
    {
        Uri destination = new Uri( that.Url );
        Uri proxiedAddress = WebRequest.DefaultWebProxy.GetProxy( destination );
        if ( !destination.Equals( proxiedAddress ) )
            that.Proxy = new WebProxy( proxiedAddress ) { UseDefaultCredentials = true };
    }
}

This same situation and error can also arise with a default wizard generated SOAP Web Service proxy (not 100% if this is also the case on the WCF System.ServiceModel stack) when at runtime:

• the end user machine is configured (in the Internet Settings) to use a proxy that does not understand HTTP 1.1
• the client ends up sending something that a HTTP 1.0 proxy doesnt understand (commonly an Expect header as part of a HTTP POST or PUT request due to a standard protocol convention of sending the request in two parts as covered in the Remarks here)

… yielding a 417.

As covered in the other answers, if the specific issue you run into is that the Expect header is causing the problem, then that specific problem can be routed around by doing a relatively global switching off of the two-part PUT/POST transmission via System.Net.ServicePointManager.Expect100Continue.

However this does not fix the complete underlying problem — the stack may still be using HTTP 1.1 specific things such as KeepAlives etc. (though in many cases the other answers do cover the main cases.)

The actual problem is however that the autogenerated code assumes that it’s OK to go blindly using HTTP 1.1 facilities as everyone understands this. To stop this assumption for a specific Web Service proxy, one can change override the default underlying HttpWebRequest.ProtocolVersion from the default of 1.1 by creating a derived Proxy class which overrides protected override WebRequest GetWebRequest(Uri uri) as shown in this post:-

public class MyNotAssumingHttp11ProxiesAndServersProxy : MyWS
{
    protected override WebRequest GetWebRequest(Uri uri)
    {
      HttpWebRequest request = (HttpWebRequest)base.GetWebRequest(uri);
      request.ProtocolVersion = HttpVersion.Version10;
      return request;
    }
}

(where MyWS is the proxy the Add Web Reference wizard spat out at you.)

UPDATE: Here’s an impl I’m using in production:

class ProxyFriendlyXXXWs : BasicHttpBinding_IXXX
{
    public ProxyFriendlyXXXWs( Uri destination )
    {
        Url = destination.ToString();
        this.IfProxiedUrlAddProxyOverriddenWithDefaultCredentials();
    }

    // Make it squirm through proxies that don't understand (or are misconfigured) to only understand HTTP 1.0 without yielding HTTP 417s
    protected override WebRequest GetWebRequest( Uri uri )
    {
        var request = (HttpWebRequest)base.GetWebRequest( uri );
        request.ProtocolVersion = HttpVersion.Version10;
        return request;
    }
}

static class SoapHttpClientProtocolRealWorldProxyTraversalExtensions
{
    // OOTB, .NET 1-4 do not submit credentials to proxies.
    // This avoids having to document how to 'just override a setting on your default proxy in your app.config' (or machine.config!)
    public static void IfProxiedUrlAddProxyOverriddenWithDefaultCredentials( this SoapHttpClientProtocol that )
    {
        Uri destination = new Uri( that.Url );
        Uri proxiedAddress = WebRequest.DefaultWebProxy.GetProxy( destination );
        if ( !destination.Equals( proxiedAddress ) )
            that.Proxy = new WebProxy( proxiedAddress ) { UseDefaultCredentials = true };
    }
}

Вопрос:

Ответ:

Ошибка «(417) Expectation failed» может возникнуть из-за неправильной обработки поля «Expect: 100-Continue» вашим прокси-сервером.

Попробуйте в файл <папка_c_Business_Studio>PingServicePing.Service.config, в секцию <configuration>, добавить следующие строки:

<system.net> 
  <settings>
    <servicePointManager expect100Continue="false"> 
  </settings>
</system.net>

и перезапустить службу BS_PingHost.

Примечание: данное исправление включено в Business Studio версии 4.0.4888 и выше (версия файла службы BS_PingHost – 2.0.4888 и выше)

Если это не поможет, то, данная несовместимость не может быть устранена на клиентской стороне. Варианты решения:

• В остальных случаях – разрешить службе BS_PingHost доступ в Интернет в обход прокси-сервера.

Возможно также, что прокси-сервер имеет фильтр, блокирующий протокол «SOAP over HTTP».

We’re trying to connect from a Backendservice made with NET Core 3.1 to a legacy WCF Service. For this we use the two NuGet packages «System.ServiceModel.Http» and «System.ServiceModel.Primitives» (latest version 4.8.1).

For the connection to the endpoint we create the binding/serviceclient manual as follows

var binding = new BasicHttpsBinding();

binding.Security.Mode = BasicHttpsSecurityMode.Transport;
binding.Security.Transport = new HttpTransportSecurity() { ClientCredentialType = HttpClientCredentialType.Certificate, ProxyCredentialType = HttpProxyCredentialType.Basic };
binding.CloseTimeout = new TimeSpan(0, 12, 0, 0, 0);
binding.OpenTimeout = new TimeSpan(0, 12, 0, 0, 0);
binding.SendTimeout = new TimeSpan(0, 12, 0, 0, 0);
binding.MaxReceivedMessageSize = 2147483646;
binding.MaxBufferSize = 2147483646;

var channelfactory = new SearchServiceClient(binding, endpoint);
channelfactory.ClientCredentials.ClientCertificate.SetCertificate(System.Security.Cryptography.X509Certificates.StoreLocation.CurrentUser, System.Security.Cryptography.X509Certificates.StoreName.My, System.Security.Cryptography.X509Certificates.X509FindType.FindBySubjectName, "CERTIFICATENAME");

var response = await channelfactory.existsAsync(...);

In order to establish the connection we need to use an SSL client certificate, not a username/password.

With each request we receive the following error message: «The remote server returned an error: (417) Expectation Failed».

I did some research and found out that all you need to do is set the «ExpectContinue» flag to false.

Unfortunately this does not work via the ServicePointManager (not even in web.config).

ServicePointManager.Expect100Continue = false;

if I downgrade the nuget package version of «System.ServiceModel.Http» and «System.ServiceModel.Primitives» to 4.4.4, it works.

Does anyone know how I can do this with the latest version ?