none
webhttp service returning html error page "Operation timed out" RRS feed

  • Question

  • Hi

    I host a WCF REST service and recently, clients have reported that instead of getting a valid response, they get an HTML error page containing the following 

    <title>Network Error</title> <big></big>

    <big>Network Error (tcp_error)</big>

    A communication error occurred: "Operation timed out"
    The Web Server may be down, too busy, or experiencing other problems preventing it from responding to requests. You may wish to try again at a later time.

    For assistance, contact your network support team.

    Here's my service configuration

    	  <behaviors>
            <serviceBehaviors>
              <behavior name="IncludeExceptionDetails">
                <serviceDebug includeExceptionDetailInFaults="true"/>
                <dataContractSerializer maxItemsInObjectGraph="2147483647"/>
                <serviceThrottling maxConcurrentCalls="2147483647" maxConcurrentInstances="2147483647" maxConcurrentSessions="2147483647"/>
              </behavior>
            </serviceBehaviors>
            <endpointBehaviors>
              <behavior name="webHttpWithHelpAndAutoFormatSelection">
                <webHttp automaticFormatSelectionEnabled="false" helpEnabled="true" defaultOutgoingResponseFormat="Json"/>
              </behavior>
            </endpointBehaviors>
          </behaviors>
    	  
    	  
    	  <services>
              <service behaviorConfiguration="IncludeExceptionDetails" name="SmartAppServer.SmartAppServer">
                  <endpoint address="http://localhost:8090" binding="webHttpBinding"
                            contract="SmartAppMobileClientInterface.ISmartAppMobile" behaviorConfiguration="webHttpWithHelpAndAutoFormatSelection" >
                      <identity>
                        <servicePrincipalName value="SmartAppServer" />
                      </identity>
                  </endpoint>
              </service>
          </services>
          </services>

    The client is written so that requests time out after 60 seconds - but the response is returned to the client pretty much instantaneously.

    Does anybody have an idea why my clients are experiencing this behavior and now it can be avoided? Plenty of other clients experience no such issue at the time where the one client I'm monitoring gets this response.

    Please note that the service is self hosted so there's no IIS configuration to adjust.

    Regards

    Stephan


    Thursday, December 12, 2013 8:32 PM

Answers

  • Hi,

    This is a very common problem which occurs when you try to download a big file or if you are connected to lan and others are using net heavily ..no need to be worried this problem normally vanishes after some time. If you are connected via lan, you'd better ask your administrator.

    And also please try to set the timeout value:

    <bindings>
           <webHttpBinding>
             <binding closeTimeout="00:20:00" openTimeout="00:20:00" sendTimeout="00:20:00" receiveTimeout="00:20:00" 
     maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647" maxBufferSize="2147483647" >                  
               <readerQuotas maxDepth="32" maxStringContentLength="2147483647" maxArrayLength="2147483647" 
                            maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
               <security mode="Transport"/>
             </binding>
           </webHttpBinding>
    </bindings>

    Best Regards,
    Amy Peng




    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, December 13, 2013 7:06 AM
    Moderator
  • Hi,

    >>could it be that this is not applied since I'm not specifying the bindingConfiguration in the service endpoint?

    Yes, by default the data can be transfer is 64kb, and of course you have to apply it to the bindConfiguration. Or it will not work. So please have a try.

    Best Regards,
    Amy Peng


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, December 19, 2013 10:32 AM
    Moderator
  • By the way, I figured this out - turns out the issue was somewhere else entirely - the machine has an incorrect proxy set and in one specific network, the proxy wouldn't forward the requests but instead reply with the error I gave in the first message.
    Sunday, January 12, 2014 7:50 PM

All replies

  • Hi,

    This is a very common problem which occurs when you try to download a big file or if you are connected to lan and others are using net heavily ..no need to be worried this problem normally vanishes after some time. If you are connected via lan, you'd better ask your administrator.

    And also please try to set the timeout value:

    <bindings>
           <webHttpBinding>
             <binding closeTimeout="00:20:00" openTimeout="00:20:00" sendTimeout="00:20:00" receiveTimeout="00:20:00" 
     maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647" maxBufferSize="2147483647" >                  
               <readerQuotas maxDepth="32" maxStringContentLength="2147483647" maxArrayLength="2147483647" 
                            maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
               <security mode="Transport"/>
             </binding>
           </webHttpBinding>
    </bindings>

    Best Regards,
    Amy Peng




    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, December 13, 2013 7:06 AM
    Moderator
  • Clients are all on WLAN, there are no big downloads, but clients are performing comet style long polling so there's a couple hundred active long running connections. 

    I already have a binding configuration, but it it is named. could it be that this is not applied since I'm not specifying the bindingConfiguration in the service endpoint? Here's the binding config

    	     <webHttpBinding>
                <binding name="SmartAppMobileClientBinding" bypassProxyOnLocal="true" useDefaultWebProxy="false" hostNameComparisonMode="WeakWildcard"
                    sendTimeout="00:20:00" openTimeout="00:20:00" receiveTimeout="00:20:00"
                    maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" maxBufferPoolSize="2147483647"
                    transferMode="Streamed">
                  <readerQuotas maxArrayLength="2147483647" maxStringContentLength="2147483647" />
                  <!--<security mode="Transport">
                    <transport clientCredentialType="Certificate" proxyCredentialType="None"></transport>
                  </security>-->
                </binding>
              </webHttpBinding>

    Friday, December 13, 2013 7:59 AM
  • Hi,

    >>could it be that this is not applied since I'm not specifying the bindingConfiguration in the service endpoint?

    Yes, by default the data can be transfer is 64kb, and of course you have to apply it to the bindConfiguration. Or it will not work. So please have a try.

    Best Regards,
    Amy Peng


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, December 19, 2013 10:32 AM
    Moderator
  • By the way, I figured this out - turns out the issue was somewhere else entirely - the machine has an incorrect proxy set and in one specific network, the proxy wouldn't forward the requests but instead reply with the error I gave in the first message.
    Sunday, January 12, 2014 7:50 PM