Large WCF web service request failing with (400) HTTP Bad Request

后端 未结 9 1588
隐瞒了意图╮
隐瞒了意图╮ 2020-11-28 03:30

I\'ve encountered this apparently common problem and have been unable to resolve it.

If I call my WCF web service with a relatively small number of items in

相关标签:
9条回答
  • 2020-11-28 03:49

    I was also getting this issue also however none of the above worked for me as I was using a custom binding (for BinaryXML) after an long time digging I found the answer here :-

    Sending large XML from Silverlight to WCF

    As am using a customBinding, the maxReceivedMessageSize has to be set on the httpTransport element under the binding element in the web.config:

    <httpsTransport maxReceivedMessageSize="4194304" /> 
    
    0 讨论(0)
  • 2020-11-28 03:50

    I found the answer to the Bad Request 400 problem.

    It was the default server binding setting. You would need to add to server and client default setting.

    binding name="" openTimeout="00:10:00" closeTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647" maxBufferSize="2147483647">

    0 讨论(0)
  • 2020-11-28 03:51

    You can also turn on WCF logging for more information about the original error. This helped me solve this problem.

    Add the following to your web.config, it saves the log to C:\log\Traces.svclog

    <system.diagnostics>
        <sources>
            <source name="System.ServiceModel"
                      switchValue="Information, ActivityTracing"
                      propagateActivity="true">
                <listeners>
                    <add name="traceListener"
                         type="System.Diagnostics.XmlWriterTraceListener"
                         initializeData= "c:\log\Traces.svclog" />
                </listeners>
            </source>
        </sources>
    </system.diagnostics>
    
    0 讨论(0)
  • 2020-11-28 03:59

    It might be useful to debug the client, turn off Tools\Options\Debugging\General\'Enable Just My Code', click Debug\Exceptions\'catch all first-chance exceptions' for managed CLR exceptions, and see if there is an exception under-the-hood on the client before the protocol exception and before the message hits the wire. (My guess would be some kind of serialization failure.)

    0 讨论(0)
  • 2020-11-28 04:01

    For what it is worth, an additional consideration when using .NET 4.0 is that if a valid endpoint is not found in your configuration, a default endpoint will be automatically created and used.

    The default endpoint will use all default values so if you think you have a valid service configuration with a large value for maxReceivedMessageSize etc., but there is something wrong with the configuration, you would still get the 400 Bad Request since a default endpoint would be created and used.

    This is done silently so it is hard to detect. You will see messages to this effect (e.g. 'No Endpoint found for Service, creating Default Endpoint' or similar) if you turn on tracing on the server but there is no other indication (to my knowledge).

    0 讨论(0)
  • 2020-11-28 04:04

    Try setting maxReceivedMessageSize on the server too, e.g. to 4MB:

        <binding name="MyService.MyServiceBinding" 
               maxReceivedMessageSize="4194304">
    

    The main reason the default (65535 I believe) is so low is to reduce the risk of Denial of Service (DoS) attacks. You need to set it bigger than the maximum request size on the server, and the maximum response size on the client. If you're in an Intranet environment, the risk of DoS attacks is probably low, so it's probably safe to use a value much higher than you expect to need.

    By the way a couple of tips for troubleshooting problems connecting to WCF services:

    • Enable tracing on the server as described in this MSDN article.

    • Use an HTTP debugging tool such as Fiddler on the client to inspect the HTTP traffic.

    0 讨论(0)
提交回复
热议问题